**** BEGIN LOGGING AT Sat May 14 23:59:56 2005
May 15 11:40:46 <beewoolie-afk> [g2]: Yo dog.
May 15 12:02:56 <[g2]> beewoolie, HEY!
May 15 12:03:21 <beewoolie> Hey man.  I'm doing some slug tweaks to see if I can get PCI running.
May 15 12:03:31 <ByronT> [g2], Ping! and PM
May 15 12:03:31 <beewoolie> I've got a couple of good leads.
May 15 12:03:50 <[g2]> on the GPIO front ?
May 15 12:05:45 <[g2]> beewoolie, so lets nail this PCI issue.
May 15 12:06:02 <beewoolie> DOOD!  I think I've got USB.
May 15 12:06:21 * [g2] thinks beewoolie is such an ass-kicker :)
May 15 12:06:29 <beewoolie> # cat /proc/interrupts
May 15 12:06:29 <beewoolie>   0:          0   csr
May 15 12:06:29 <beewoolie>   1:         12   csr
May 15 12:06:33 <beewoolie>   2:          8   csr
May 15 12:06:35 <beewoolie>   3:          0   ixp425_eth
May 15 12:06:37 <beewoolie>   5:       3306   IXP425 Timer 1
May 15 12:06:39 <beewoolie>  15:        172   serial
May 15 12:06:41 <beewoolie>  18:      92060   ixp425_eth
May 15 12:06:43 <beewoolie>  22:          1   pbuttons
May 15 12:06:47 <beewoolie>  26:          0   ehci_hcd
May 15 12:06:49 <beewoolie>  27:          0   usb-ohci
May 15 12:06:51 <beewoolie>  28:          0   usb-ohci
May 15 12:06:53 <beewoolie>  29:          1   rbuttons
May 15 12:06:55 <beewoolie> Err:          0
May 15 12:07:08 <beewoolie> It looks like it.  I can see the PCI devices on the bus in /proc/pci
May 15 12:07:12 <[g2]> that looks good.  Did you get the extra message on boot ?
May 15 12:07:20 <beewoolie> ...checking...
May 15 12:07:34 <beewoolie> PCI Autoconfig: Found Bus 0, Device 1, Function 0
May 15 12:07:35 <beewoolie> PCI Autoconfig: BAR 0, Mem, size=0x1000, address=0x4bfff000
May 15 12:07:35 <beewoolie> PCI Autoconfig: Found Bus 0, Device 1, Function 1
May 15 12:07:35 <beewoolie> PCI Autoconfig: BAR 0, Mem, size=0x1000, address=0x4bffe000
May 15 12:07:35 <beewoolie> PCI Autoconfig: Found Bus 0, Device 1, Function 2
May 15 12:07:35 <beewoolie> PCI Autoconfig: BAR 0, Mem, size=0x100, address=0x4bffdf00
May 15 12:07:37 <beewoolie> PCI: bus0: Fast back to back transfers disabled
May 15 12:08:01 <[g2]> it's the one right after that disabled which looks good
May 15 12:08:38 <beewoolie> the last in the list, right?  That's the one you were interested in.
May 15 12:08:57 <[g2]> yes that one and the line that follows
May 15 12:09:04 <beewoolie> So, now that I've got something working, I'm going to do some tests with a hard drive to make sure that it works.
May 15 12:09:14 <beewoolie> The one after that is a network message.
May 15 12:09:18 <beewoolie> PCI: bus0: Fast back to back transfers disabled
May 15 12:09:19 <beewoolie> Linux NET4.0 for Linux 2.4
May 15 12:09:25 <beewoolie> what are you expecting?
May 15 12:09:46 * [g2] pulling up notes
May 15 12:10:54 <[g2]> PCI: bus0: Fast back to back transfers disabled
May 15 12:10:54 <[g2]> dmabounce: registered device 0000:00:01.0 on pci bus
May 15 12:10:54 <[g2]> SCSI subsystem initialized
May 15 12:11:07 <[g2]> We're still missing the dmabounce setup
May 15 12:11:28 <beewoolie> Hmm.
May 15 12:11:39 <beewoolie> I wonder if that's because you've got a 64MiB system???
May 15 12:12:25 <beewoolie> I attached a USB drive and it seems to recognize it.
May 15 12:13:20 <[g2]> I think I get it on the slug too
May 15 12:13:28 * [g2] checks
May 15 12:14:09 <[g2]> PCI: bus0: Fast back to back transfers disabled
May 15 12:14:10 <[g2]> dmabounce: registered device 0000:00:01.0 on pci bus
May 15 12:14:10 <[g2]> dmabounce: registered device 0000:00:01.1 on pci bus
May 15 12:14:10 <[g2]> dmabounce: registered device 0000:00:01.2 on pci bus
May 15 12:14:10 <[g2]> SCSI subsystem initialized
May 15 12:14:28 <beewoolie> Hmm.  OK.  Need to do more looking. 
May 15 12:14:44 <[g2]> I think that's because there are three devices on the part. EHCI and 2 OHCI
May 15 12:14:44 <beewoolie> Does fdisk work on the slug?
May 15 12:14:56 <[g2]> sure
May 15 12:15:23 <beewoolie> Well, it looks like I can read the disk.
May 15 12:16:03 <beewoolie> Yeah, I've got IO.
May 15 12:16:26 <beewoolie> What kernel are you using on these systems?
May 15 12:17:11 <[g2]> All 2.6.11.2
May 15 12:17:15 <[g2]> you running 2.4 ?
May 15 12:17:23 <beewoolie> Perhaps it's a kernel version thing.
May 15 12:17:30 <beewoolie> I've got a stock system.
May 15 12:17:38 <[g2]> I known...
May 15 12:17:47 <[g2]> that's funny to me
May 15 12:18:13 <[g2]> Is code checked in to your repo ?
May 15 12:18:20 <beewoolie> Not yet.
May 15 12:18:44 <beewoolie> I need to do some other small things before I can call it good.  For example, I need to make sure it boots from flash.  Little stuff, ya know.
May 15 12:18:56 <[g2]> please please pretty please with sugar on top ? :)
May 15 12:19:15 <beewoolie> I don't want to break your systems.  Give me about 30 minutes to make sure it all good.
May 15 12:19:44 <[g2]> Ok... On the Avila board I can reflash Redboot via their JTAG connector and sw
May 15 12:20:15 <[g2]> So that board has been brick-proof for a couple months now
May 15 12:20:15 <beewoolie> I'm getting some interesting messages...
May 15 12:20:28 <[g2]> maybe a month
May 15 12:20:49 <beewoolie> PCI: 00:01.2 PCI cache line size set incorrectly (0 bytes) by BIOS/FW.
May 15 12:20:49 <beewoolie> PCI: 00:01.2 PCI cache line size corrected to 32.
May 15 12:20:53 <beewoolie> Do you see this?
May 15 12:21:07 <[g2]> I think in the old firmware yes
May 15 12:21:23 <beewoolie> OK.  I can set it.
May 15 12:21:34 <beewoolie> But it probably isn't a bonafide problem.
May 15 12:21:38 <[g2]> is the disk working ?
May 15 12:21:47 <beewoolie> I just booted from flash.  let me check.
May 15 12:22:06 <beewoolie> If I plug-in a drive, should it automount?
May 15 12:22:31 <beewoolie> Stuff is still on the drive.
May 15 12:22:34 <beewoolie> :-)
May 15 12:23:06 <[g2]> EXCELLENT!
May 15 12:23:10 * [g2] hugs beewoolie 
May 15 12:23:40 <[g2]> So what was the issue, the endianness ? or PCI setup ?
May 15 12:23:47 <beewoolie> check this out...
May 15 12:23:53 <beewoolie> # ifconfig ixp0 192.168.8.205
May 15 12:23:53 <beewoolie> # ping 192.168.8.1
May 15 12:23:53 <beewoolie> PING 192.168.8.1 (192.168.8.1): 56 data bytes
May 15 12:23:53 <beewoolie> 64 bytes from 192.168.8.1: icmp_seq=0 ttl=64 time=0.8 ms
May 15 12:23:53 <beewoolie> 64 bytes from 192.168.8.1: icmp_seq=1 ttl=64 time=0.5 ms
May 15 12:23:59 <beewoolie> Woot!
May 15 12:24:21 <[g2]> most excellent!  One rock two-birds eh ?
May 15 12:26:01 <beewoolie> The trouble seems to be that I wasn't performing a reset on the PCI bus.  I had to do a little bit-banging on the PCI reset line to get the USB to come up.  I'm not sure how this affected the ethernet controller except that, perhaps, it requires PCI.
May 15 12:26:42 <[g2]> Or it simply hung some part of the interrupt handler
May 15 12:26:51 <beewoolie> I don't think so.
May 15 12:27:26 <beewoolie> the only interrupt stuff I'm initializing is the PCI INTA which is attached to the USB controller.
May 15 12:27:50 <beewoolie> without that, the USB controller would simply be unavailable.
May 15 12:28:01 <[g2]> Well I'm very happy to see both working.
May 15 12:28:03 <beewoolie> Anyway, I'll get something to you in a few minutes.
May 15 12:28:17 * [g2] looks forward to testing :)
May 15 12:33:32 <beewoolie> I don't see an answer to the automount question.  does the slug automount drives when they're attached?
May 15 12:34:19 <[g2]> On OpenSlug they do :)
May 15 12:34:31 <beewoolie> and on the original FW?
May 15 12:34:37 <[g2]> On stock if you plug it in Port 1 I think it will
May 15 12:34:46 <beewoolie> Oh.
May 15 12:34:50 <beewoolie> Let me try that.
May 15 12:34:51 <[g2]> DISK 2 that is
May 15 12:34:59 <bob_tm> It will. External program.
May 15 12:35:00 <[g2]> and it must be fat/vfat
May 15 12:35:19 <[g2]> iirc
May 15 12:35:53 <[g2]> ext2 might work also
May 15 12:48:06 <beewoolie> Oops.  broke it.
May 15 12:48:37 <[g2]> doesn't boot from flash ?
May 15 12:48:42 <beewoolie> Good thing I have jtag.  
May 15 12:48:56 <beewoolie> I've been removing cruft.
May 15 13:15:48 <beewoolie> [g2]: You there?
May 15 13:15:55 <[g2]> hello
May 15 13:16:09 <beewoolie> How do I program flash with openwince?  do you know?
May 15 13:16:11 <[g2]> I'm here your there
May 15 13:16:55 <[g2]> not of the top of my head
May 15 13:16:59 <beewoolie> I think the command is flashmem.
May 15 13:17:07 <beewoolie> Have you used openwince to write to flash?
May 15 13:17:13 <[g2]> I think you also need to set the endian ness
May 15 13:17:20 <[g2]> not yet
May 15 13:17:32 <[g2]> I've been reflashing with dd
May 15 13:17:42 <beewoolie> Ah.  But I cannot boot.
May 15 13:17:43 <[g2]> and the avila tool which is a stand-alone program
May 15 13:17:59 <[g2]> I know you toasted the bootloader
May 15 13:18:24 <beewoolie> OK.  I need to look on the web a bit.
May 15 13:18:46 <[g2]> jacques, ping
May 15 13:18:56 <[g2]> dyoung-zzzz, ping
May 15 13:19:13 <[g2]> beewoolie, have you read out from flash ?
May 15 13:19:48 <beewoolie> Yeah, I do.
May 15 13:20:12 <[g2]> is there no writemem ?
May 15 13:20:18 <beewoolie> flashmem
May 15 13:20:21 <beewoolie> It complains
May 15 13:20:21 <[g2]> I'd think you want to write to memory and then just boot
May 15 13:20:42 <[g2]> did you set our endianness ?
May 15 13:20:45 <beewoolie> Ooops. I was wrong about the command format.
May 15 13:21:30 <beewoolie> it's programming now.
May 15 13:21:52 <[g2]> so you set you endianness and which command did you use ?
May 15 13:21:58 <beewoolie> endian big
May 15 13:22:33 <[g2]> flashmem 0x5000000 apex.bin 
May 15 13:22:37 <[g2]> ?
May 15 13:22:41 <beewoolie> Yeah.  It's going no.
May 15 13:23:09 <[g2]> was that a It's going now ?
May 15 13:23:23 <beewoolie> ...yeah.  typo.
May 15 13:23:37 <[g2]> so were you worried for a minute ?
May 15 13:23:39 <[g2]> ;)
May 15 13:24:08 <beewoolie> Uh huh.  but I knew that it woruld work.
May 15 13:24:18 <[g2]> cool
May 15 13:24:31 <[g2]> It's ok to have a little excitement
May 15 13:24:51 <beewoolie> This thing is really really REALLY slow.
May 15 13:25:02 <[g2]> I think it'll take about 40 minutes
May 15 13:25:06 <[g2]> maybe 50
May 15 13:25:15 <beewoolie> Not with apex.
May 15 13:25:21 <[g2]> AH....
May 15 13:25:26 <[g2]> excellent :)
May 15 13:25:40 <[g2]> and Old working version or a new untested version ?
May 15 13:25:45 <[g2]> an
May 15 13:26:10 <beewoolie> On older working version.
May 15 13:26:14 <beewoolie> s/on/an/
May 15 13:27:07 <[g2]> I can't tell you how happy I am that you adapted APEX for the IXP4xx line
May 15 13:27:47 <[g2]> simply masterful
May 15 13:32:47 <beewoolie> i, too.
May 15 13:33:49 <[g2]> What I'd like to see for openslug 2.0 is APEX, and a full native compile environement allowing the kernel to be rebuilt
May 15 13:34:05 <[g2]> which is all there, but needs a little polishing
May 15 13:35:41 <beewoolie> This means that we can get to making APEX really comfortable.
May 15 13:36:02 <[g2]> APEX already is really comfortable :)
May 15 13:36:19 <[g2]> but we can make it more comfortable for Joe User
May 15 13:36:21 <beewoolie> How about booting to a rootfs in flash. 
May 15 13:36:26 <beewoolie>  ?
May 15 13:36:35 <[g2]> That'd be excellent too
May 15 13:37:13 <[g2]> I'll probably be pimping out my RV082 board to 128MB
May 15 13:37:47 <[g2]> It'll be getting serial and JTAG too, so I"m seeing APEX running on there pretty soon
May 15 13:37:59 <beewoolie> Excellent.
May 15 13:38:31 <[g2]> With some luck, I'll have and RV042 with 64MB and and 082 with 128MB both with serial and JTAG headers.
May 15 13:38:31 <beewoolie> BTW, there was another apex bug that I had to deal with.  it wasn't building properly, so when I made code changes they weren't really being tested.
May 15 13:38:43 <beewoolie> Are you using your reman pals?
May 15 13:38:55 <[g2]> reman ?
May 15 13:39:09 <[g2]> rework ?
May 15 13:39:19 <beewoolie> uh, yeah, that's what I mean.
May 15 13:39:26 <[g2]> yeah...
May 15 13:39:38 <beewoolie> Any samples yet?
May 15 13:39:46 <[g2]> these will be the samples
May 15 13:39:51 <beewoolie> cool.
May 15 13:40:26 <beewoolie> reflashing again because I keep forgetting something.
May 15 13:40:46 <beewoolie> BTW, when ka6sox-away gets back, we should be able to talk about jtag wishes.
May 15 13:41:16 <beewoolie> One thing I really want is something that can perform flashing faster.  an obvious wish, but there may be some ways to make it more efficient.
May 15 13:47:48 <beewoolie> Hmm.  It's back, but I'm not sure why.  It looks like the jtag interface is doing some wierd stuff.
May 15 13:51:57 <[g2]> I'm thinking about contracting some FPGA work to be done for OpenJTAG
May 15 13:56:06 <beewoolie> For the design we already have, or something else?
May 15 13:56:14 <beewoolie> BTW, I've successfully reflashed.
May 15 13:56:18 <beewoolie> Still tweaking.
May 15 14:04:07 <jacques> [g2], hi
May 15 14:04:32 <[g2]> jacques, hey
May 15 14:04:50 <jacques> what's up?
May 15 14:05:06 <[g2]> FYI beewoolie had usb working with APEX
May 15 14:05:23 <beewoolie> Working to remove crufty debug stuff.
May 15 14:05:36 <jacques> fantastic!
May 15 14:05:43 <[g2]> and the IXP ethernet was working too right ?
May 15 14:05:51 <beewoolie> Yep.
May 15 14:06:08 <beewoolie> It's all running as far as I can tell.  You'll have to check on the dmabounce stuff.
May 15 14:06:28 <[g2]> that's probably a kernel thing 2.6 versus 2.4
May 15 14:07:09 <[g2]> so can we discuss the APEX roadmap ?
May 15 14:07:32 <beewoolie> Sure can.
May 15 14:07:43 <[g2]> jacques, you still there ?
May 15 14:08:09 <jacques> yep
May 15 14:08:30 <[g2]> So in the immediate future... beewoolie cleans up the cruft and release the version that has the usb/ixp fixes in for the slug
May 15 14:08:51 <[g2]> I'll want to build that for the Avila and verifiy the E1000 works
May 15 14:09:19 <jacques> there a specific toolchain recommended for apex ?
May 15 14:09:25 <[g2]> Then, there are no major outstanding issues that I'm aware of
May 15 14:09:38 <[g2]> I'm using a crosstool built noe
May 15 14:09:40 <[g2]> one
May 15 14:09:45 <beewoolie> It works with 2.95.3 as well as 3.4.1.  I haven't tried 4.0.0.  I know that that version doesn't work with the kernel, yet.
May 15 14:09:56 <[g2]> I"m running 3.4.3 iirc
May 15 14:10:03 <jacques> beewoolie, fine enough, I wouldn't try 4.0 at this point :-)
May 15 14:10:18 <jacques> 3.4.3 is my current favorite
May 15 14:10:27 <[g2]> Mine too :)
May 15 14:10:45 <beewoolie> I just switched to crosstool-0.32 and haven't bothered to upgrade the toolchain version.  3.4.1 has been solid.
May 15 14:10:50 <beewoolie> You can test 3.4.3 for us.
May 15 14:10:59 <[g2]> I'm running 3.4.3
May 15 14:11:05 <beewoolie> Cool.
May 15 14:11:49 <[g2]> Ok... it's 3.4.2
May 15 14:12:16 <[g2]> armv5b-softfloat-linux/gcc-3.4.2-glibc-2.3.3/bin/armv5b-softfloat-linux-
May 15 14:12:47 <[g2]> so beewoolie are you aware of any outstand bugs after the test of the avila and the test on the slug ?
May 15 14:13:05 <beewoolie> None that I can think of.
May 15 14:13:25 <beewoolie> I enabled the serial FIFO this time around, too.
May 15 14:13:25 <[g2]> ok.. so for the roadmap what features are you interested in next ?
May 15 14:13:55 <beewoolie> There are the driver chaining features so that we can handle putting rootfs's in flash.  Thats 1).
May 15 14:14:06 <beewoolie> 2) the UI for alternative boot methods
May 15 14:14:21 <beewoolie> 3) some console improvements, e.g. command history and editing.
May 15 14:14:57 <beewoolie> 4) network support.  This isn't so important for the slug and family because of the onerous driver problems.
May 15 14:15:13 <jacques> by 1) do you mean being able to find the kernel inside a flash fs ?
May 15 14:15:14 <beewoolie> 5) USB support for USB console and other coolness.
May 15 14:15:25 <beewoolie> jacques: yeah.  Among other things.
May 15 14:15:29 <jacques> cool
May 15 14:15:46 <beewoolie> The driver stuff has all of the hooks to be very flexible with how data moves in the loader.
May 15 14:16:09 <[g2]> Is jffs2 in 1) or is that 6)
May 15 14:16:21 <beewoolie> There are a few barriers having to do with the fact that there is a FAT and EXT2 (and jffs later) driver, but no way to describe the relationships.
May 15 14:16:44 <beewoolie> I suppose jffs2 would be in 6), but 1) has to come first for it.
May 15 14:17:04 <beewoolie> 1) isn't really hard.  It's bookeeping.
May 15 14:18:00 <[g2]> Ok so here's a question
May 15 14:18:33 <[g2]> do we skip 1 until there's jffs2 support and just bump the partition size for kernel to 1.5 MB ?
May 15 14:19:27 <[g2]> or leave it at 1MB for compatibility 
May 15 14:19:31 <beewoolie> What is the partition size for the kernel now?
May 15 14:19:34 <beewoolie> OK.
May 15 14:19:34 <[g2]> 1MB
May 15 14:19:56 <beewoolie> And the kernel doesn't fit in 1MiB for 2.6?
May 15 14:20:11 <[g2]> we are right on the edge
May 15 14:20:29 <[g2]> it's got to have lots of stuff loaded in
May 15 14:20:39 <[g2]> ext2/3, scsi, usb ....
May 15 14:21:11 <[g2]> unless we want to go to modified module loading via initrd or linuxrc
May 15 14:21:21 <beewoolie> Well, that's generally a better way. 
May 15 14:21:32 <beewoolie> Is there a reason to keep everything in the kernel?
May 15 14:22:07 <beewoolie> Keep in mind that I don't think it has to be this way.  it's just that until we can read the kernel from a flash-based filesystem, we need to come up with a good way to go.
May 15 14:22:31 <[g2]> that's the point.
May 15 14:22:47 <[g2]> we could rebuild the rootfs as ext2 and then is a driver issue
May 15 14:23:29 <beewoolie> Right now, it's a ramdisk, right?
May 15 14:23:31 <[g2]> and then is a driver issue until jffs2 is there
May 15 14:23:37 <[g2]> not on OpenSlug
May 15 14:23:51 <beewoolie> What is openslug?  ext2?  jffs2?
May 15 14:24:03 <[g2]> we boot to jffs2 as the rootfs or we pivot on to the flash/hdd
May 15 14:24:17 <[g2]> I think provisions for NFS are also in there
May 15 14:24:21 <beewoolie> OK.  So as long as the kernel as a jffs2 driver, we can load modules when it boots.
May 15 14:24:27 <beewoolie> From jffs2.
May 15 14:24:45 <beewoolie> we don't have to use linuxrc to do that.
May 15 14:25:15 <[g2]> well I think currently that's how it's handled
May 15 14:25:19 <[g2]> init=/linuxrc
May 15 14:25:24 <[g2]> on the jffs2
May 15 14:25:30 <beewoolie> I just saying that that isn't necessary on openslug.
May 15 14:25:43 <[g2]> Kernel command line: root=/dev/mtdblock4 rw rootfstype=jffs2 mem=32M@0x00000000 init=/linuxrc console=ttyS0,115200n8
May 15 14:26:11 <beewoolie> the only reason to use initrd is that you are loading from an initrd ramdisk and that kernel instance needs to load drivers.
May 15 14:26:32 <beewoolie> We can boot to jffs2 using a kernel with th ejffs2 driver which then loads modules for everything else.
May 15 14:26:36 <beewoolie> No initrd at all.
May 15 14:27:06 <[g2]> You are missing the point of the linuxrc
May 15 14:27:08 <beewoolie> I suppose you can continue to use linuxrc.  
May 15 14:27:15 <beewoolie> Which is?
May 15 14:27:47 <[g2]> It allows one to boot to jffs2, sda1, sda2, sdb1, sdb2 and nfs all but touching a couple files on the / partition
May 15 14:28:13 <beewoolie> So where's the problem with putting the other FS drivers in the jffs2 partition?
May 15 14:29:03 <[g2]> are you saying pull ext2/3/usb/scsi from the kernel and load them via the linuxrc ?
May 15 14:29:19 <beewoolie> Yeah.
May 15 14:29:24 <[g2]> Bad idea
May 15 14:29:28 <beewoolie> Because?
May 15 14:29:59 <[g2]> because when your drivers are updated on .sdx1 or sdx2 your kernel is loading the drivers from jffs2
May 15 14:30:29 <[g2]> currently if something goes wrong on the update on sdx then just pulling it out and rebooting fixes the problem
May 15 14:30:34 <beewoolie> Why put drivers on the hard drives?
May 15 14:30:54 <beewoolie> You can make the linuxrc handle loading drivers from either place.
May 15 14:31:02 <[g2]> I you case, botching the drivers/kernel build causes one to go back to the bootloader
May 15 14:31:07 <[g2]> In your case
May 15 14:31:20 <beewoolie> linuxrc can handle that.
May 15 14:31:35 <[g2]> no it can't when it does have the new drivers
May 15 14:32:16 <beewoolie> I don't know what you mean.  You cannot put drivers on the hard drive that don't match the built kernel.
May 15 14:32:30 <beewoolie> So, versions of the FS drivers in flash have to match the kernel.
May 15 14:32:56 <[g2]> there's a command in openslug to allow you to updated the kernel in the kernel partition
May 15 14:33:18 <beewoolie> And if that is botched?
May 15 14:34:03 <[g2]> currently, ppl load the kernel from Redboot and test first
May 15 14:34:14 <[g2]> so it's a known good kernel before flashing
May 15 14:34:24 <[g2]> but Redboot is the fall back
May 15 14:34:32 <[g2]> and APEX would be the fall back also
May 15 14:34:57 <beewoolie> What drivers do you want to add to the kernel that are going to make it larger than 1MiB?
May 15 14:35:36 <[g2]> The real problem is that on AMD64 the binutils generates larger size that pushed it over the edge for AMD64 builders
May 15 14:36:00 <[g2]> it's a toolchain issue and we are near the edge
May 15 14:36:10 <ByronT> I thought that problem was sorted out...
May 15 14:36:36 <[g2]> perlguru and voodooz would know
May 15 14:36:41 <beewoolie> I just not compelled but this problem.  it's way to complex.  If you need more space, then make the partition larger. 
May 15 14:36:52 * [g2] does have a shiny new AMD64 but that's a different issue
May 15 14:37:00 <beewoolie> IMHO, this isn't a good use of our resources.
May 15 14:37:13 <ByronT> I asked rwhitby the other night because I was in the process of ordering an AMD64
May 15 14:38:10 <[g2]> beewoolie, you mean having a 1MB kernel (1/8 of the flash) isn't good use of the resources ?
May 15 14:38:33 <beewoolie> No, I mean that fussing about optimizing flash at this level isn't worth the effort.
May 15 14:38:50 <beewoolie> I think that the design parameters are far to constrictive and not worth the effort.
May 15 14:39:34 <beewoolie> Moreover, expecting end users to test kernels with REDBOOT is a bit extreme.
May 15 14:40:13 <[g2]> well 99% of the users just flash a new load
May 15 14:40:24 <beewoolie> I think it's better to put a whole boot-image into flash and provide a reasonable migration path for upgrading it.
May 15 14:40:34 <[g2]> but the 1% that are really chaning things have to load via tftp or something like that
May 15 14:41:07 <beewoolie> And I think that putting drivers on the HD and the kernel in flash is very unwise.
May 15 14:41:23 <[g2]> I mean just changing the .config and adding stuff is only a problem when exceeding the 1MB barrier which *has* been a real issue for the development
May 15 14:41:41 <beewoolie> Developers can repartition flash as they please.
May 15 14:42:54 <[g2]> beewoolie, you, me, tiersten, jacques and dyoung (and possibly kas) are the only ppl I know that have played with either Redboot or APEX bootloaders
May 15 14:43:52 <[g2]> I don't think tiersten did much other than test if stuff loades
May 15 14:43:56 <[g2]> loads
May 15 14:44:31 <[g2]> jacques, have you reflashed Redboot other than the de-bricking ?
May 15 14:44:46 <beewoolie> it sounds like pulling the kernel from jffs2 is a high priority to you.
May 15 14:45:13 <[g2]> I think it's important
May 15 14:45:30 <[g2]> Actually I think USB console is the most important
May 15 14:45:34 <beewoolie> Based on the list of features we've got, the six or so, how would you rank them.
May 15 14:45:42 <beewoolie> Is USB console before jffs2?
May 15 14:45:52 <[g2]> yes to me
May 15 14:46:32 <beewoolie> Because it means we can develop on these systems without soldering serial consoles.  Right?
May 15 14:46:38 <[g2]> point being, that with USB console, the end-user just plug in a usb-serial adapter and brickless short of the first 128K flash section
May 15 14:46:50 <[g2]> excatly on the solderless development
May 15 14:47:08 <[g2]> it's really more solderless deployment
May 15 14:47:44 <beewoolie> can we deploy without it now?  We can produce images that the FW can flash right now? In fact I can break into redboot reliably without serial.
May 15 14:47:56 <[g2]> We can change the target rootfs type in OE and build an ext2 fs in a couple of hours
May 15 14:48:01 <[g2]> I've done it before
May 15 14:48:25 <[g2]> or just tarball up the hdd/flashstick and dd it to a partition
May 15 14:48:34 <[g2]> or copy it to an ext2 partitionnnnn
May 15 14:48:49 <beewoolie> I'll look at the USB serial stuff.  I don't expect it is too difficult, but it may require some code to handle PCI as well as the HCI.
May 15 14:48:59 <beewoolie> right.
May 15 14:49:05 <beewoolie> about the deployment.
May 15 14:49:36 <beewoolie> The USB console does make things a little safer for those without serial headers.
May 15 14:53:46 <beewoolie> On the other hand, jffs2 is all SW and should be simpler to implement than the USB.
May 15 14:54:16 <[g2]> I think they are both wonderful things to work on
May 15 14:54:19 <beewoolie> USB may also require some restructuring since I'll need to do polling for multiple interfaces, serial as well as USB.
May 15 14:55:09 <[g2]> the other idea is ext2 off the usb bulk storage device
May 15 14:55:23 <[g2]> then we'd be able to literally boot directly from the usb device
May 15 14:55:37 <beewoolie> I'd like that, too.
May 15 14:55:46 <[g2]> that would be totally cool
May 15 14:56:05 <beewoolie> In the ideal setup, APEX would boot from USB unless there is  no USB in which case it boots to the fail-safe flash rootfs.
May 15 14:56:42 <[g2]> actually I do it the other way around
May 15 14:57:06 <[g2]> look in the flash first and have 1 or 2 places to boot from and then boot off USB
May 15 14:57:06 <beewoolie> Why?  How can it boot to USB if there is a flash FS in place?
May 15 14:57:21 <[g2]> Security is 1 reason
May 15 14:57:24 <beewoolie> That doesn't make sense to me.
May 15 14:57:36 <[g2]> anyone pluging a usb stick and rebooting ownz you device
May 15 14:57:39 <beewoolie> that's ridiculous.
May 15 14:57:56 <beewoolie> Physical access is not a reasonable thing to protect against.
May 15 14:58:03 <beewoolie> There are lots of ways to own a device.
May 15 14:58:31 <[g2]> We'll I've talked to clients that want to deploy something like this
May 15 14:58:36 <beewoolie> Are you paranoid of people developing viruses?
May 15 14:59:00 <[g2]> no. but I am security minded
May 15 14:59:15 <beewoolie> Well, if you do it that way it makes it difficult to upgrade.
May 15 14:59:39 <beewoolie> Moreover, that wouldn't be an APEX task.
May 15 14:59:42 <[g2]> I'd love to discuss this more, but I've got to run for dinner
May 15 14:59:54 <beewoolie> You'd always boot to flash unless there is no flash at all.
May 15 15:00:09 <[g2]> Right
May 15 15:00:34 <[g2]> the question is about where the kernels and rootfs are pulled form
May 15 15:00:36 <[g2]> from
May 15 15:00:52 <[g2]> I'll be back later or my wife will kill me
May 15 15:01:04 <[g2]> sorry to run in the middle
May 15 15:01:05 <beewoolie> ttfn
May 15 16:17:03 <beewoolie> [g2]-dinner: There's a version 1.2.11 of APEX on my ftp server.  This one has a build for nslu2 that boots the slug.  give it a whirl.
May 15 16:17:51 <[g2]-dinner> beewoolie, just got back.
May 15 16:17:55 <[g2]-dinner> will do.
May 15 16:18:07 <[g2]-dinner> That boots on the slug ?
May 15 16:18:17 <beewoolie> K.  It takes about 45 seconds to boot.  Part of that is the error dump I'm seeing.
May 15 16:18:50 <beewoolie> I'm considering a hack to stop it, but it isn't really a big deal since we're moving to a newer kernel.
May 15 16:19:15 <[g2]> nod. I'm running 2.6 and may not seeit
May 15 16:19:45 <[g2]> beewoolie, did you change any of the GPIO stuff or just the pci reset ?
May 15 16:19:48 <beewoolie> Right.  The default config boots with a command line that starts the default firmware.
May 15 16:20:09 <beewoolie> I changed a few other things.  I realized that I wasn't running all of the code I thought I was running.
May 15 16:20:23 <beewoolie> Now, the code only explicitly initializes GPIO for the PCI.
May 15 16:20:58 <[g2]> So it can do reset
May 15 16:21:12 <beewoolie> It turns out that the reset wasn't the problem.
May 15 16:21:35 * [g2] is open the the world of possibilities :)
May 15 16:21:37 <[g2]> what was it
May 15 16:21:37 <beewoolie> I was already doing enough.  I believe that the real problem was the fast back-to-back setting.  I had to make sure to clear that bit.
May 15 16:21:55 <beewoolie> I cannot be sure, but it looks like that was all that was stopping it from running.
May 15 16:22:12 <beewoolie> It's also performing the PCI reset, just for good measure.
May 15 16:22:17 <[g2]> Ok so you just cleared that bit in the pci SETUP config area correct ?
May 15 16:23:02 <beewoolie> That's kinda how it works.  The PCI config registers are available only indirectly.
May 15 16:23:10 <[g2]> I'm curious about the changes, but I'm really curious whether I can run it on the avila board
May 15 16:23:21 <beewoolie> You can browse the code in the src/mach-ixp42x/pci.c.
May 15 16:23:28 <beewoolie> yeah, me too.
May 15 16:23:58 <beewoolie> The PCI reset only activates when you set the NSLU2 machine type...which you shouldn't be using.
May 15 16:24:00 <[g2]> I'd prefer to try it there first as I've got bootloader reflashing avialable there, but not on the slug
May 15 16:24:19 <beewoolie> the reset bits are GPIO pins specific to that design.  It is not the same as the design for the Intel dev board.
May 15 16:24:28 <beewoolie> Let er rip.
May 15 16:24:38 <[g2]> Ok will do.
May 15 16:31:01 <[g2]> rebooting 
May 15 16:32:48 <[g2]> Ok the copy of the .config and build didn't pick up the old command line
May 15 16:32:56 <[g2]> I'll type it in at boot
May 15 16:34:33 <[g2]> beewoolie, on the avila
May 15 16:34:36 <[g2]> PCI: bus0: Fast back to back transfers disabled
May 15 16:34:36 <[g2]> dmabounce: registered device 0000:00:01.0 on pci bus
May 15 16:34:36 <[g2]> SCSI subsystem initialized
May 15 16:34:44 <beewoolie> Nice.
May 15 16:35:04 <[g2]> Ok IXP eth still up.
May 15 16:35:10 <beewoolie> Good.
May 15 16:35:21 <[g2]> going for the GigE PCI
May 15 16:35:33 <beewoolie> Do you see it in the /proc/pci?
May 15 16:35:53 <[g2]> root@avila:~# cat /proc/pci
May 15 16:35:54 <[g2]> PCI devices found:
May 15 16:35:54 <[g2]>   Bus  0, device   1, function  0:
May 15 16:35:54 <[g2]>     Class 0200: PCI device 8086:100e (rev 2).
May 15 16:35:54 <[g2]>       IRQ 28.
May 15 16:35:54 <[g2]>       Master Capable.  No bursts.  Min Gnt=255.
May 15 16:35:56 <[g2]>       Non-prefetchable 32 bit memory at 0x48000000 [0x4801ffff].
May 15 16:36:00 <[g2]>       I/O at 0x1000 [0x103f].
May 15 16:37:16 <beewoolie> Nice.
May 15 16:38:18 <[g2]> Ok... I've got a depmod issue but.....
May 15 16:38:36 <[g2]> insmod e1000.ko
May 15 16:38:36 <[g2]> Intel(R) PRO/1000 Network Driver - version 5.6.10.1-k2
May 15 16:38:36 <[g2]> Copyright (c) 1999-2004 Intel Corporation.
May 15 16:38:36 <[g2]> PCI: enabling device 0000:00:01.0 (0140 -> 0143)
May 15 16:38:36 <[g2]> e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
May 15 16:38:37 <[g2]> root@avila:/lib/modules/2.6.11.2/drivers/net/e1000# ifconfig eth2 192.168.1.79
May 15 16:38:41 <[g2]> root@avila:/lib/modules/2.6.11.2/drivers/ne1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
May 15 16:38:44 <[g2]> et/e1000#
May 15 16:39:00 <beewoolie> Well well well.
May 15 16:39:21 <[g2]>  ping 192.168.1.79
May 15 16:39:21 <[g2]> PING 192.168.1.79 (192.168.1.79) 56(84) bytes of data.
May 15 16:39:21 <[g2]> 64 bytes from 192.168.1.79: icmp_seq=1 ttl=64 time=2.33 ms
May 15 16:39:21 <[g2]> 64 bytes from 192.168.1.79: icmp_seq=2 ttl=64 time=0.200 ms
May 15 16:39:21 <[g2]> 64 bytes from 192.168.1.79: icmp_seq=3 ttl=64 time=0.254 ms
May 15 16:39:23 <[g2]> 64 bytes from 192.168.1.79: icmp_seq=4 ttl=64 time=0.167 ms
May 15 16:39:25 <[g2]> 64 bytes from 192.168.1.79: icmp_seq=5 ttl=64 time=0.230 ms
May 15 16:39:26 <[g2]> --- 192.168.1.79 ping statistics ---
May 15 16:39:28 <[g2]> 5 packets transmitted, 5 received, 0% packet loss, time 4003ms
May 15 16:39:47 <[g2]> EXCELLENT WORK my friend !
May 15 16:40:17 <[g2]> cat /proc/interrupts
May 15 16:40:17 <[g2]>            CPU0
May 15 16:40:17 <[g2]>   0:          0   csr
May 15 16:40:17 <[g2]>   1:         18   csr
May 15 16:40:17 <[g2]>   2:         14   csr
May 15 16:40:17 <[g2]>   3:         13   ixp425_eth
May 15 16:40:19 <[g2]>   5:      37982   IXP4xx Timer Tick
May 15 16:40:21 <[g2]>  15:       3792   serial
May 15 16:40:23 <[g2]>  28:         79   eth2
May 15 16:40:25 <[g2]> Err:          0
May 15 16:40:27 <[g2]> eth0 is down to test eth2
May 15 16:40:44 <[g2]> Oh... 1 more thing
May 15 16:40:59 <[g2]> cat /proc/meminfo
May 15 16:40:59 <[g2]> MemTotal:        62820 kB
May 15 16:40:59 <[g2]> MemFree:         54928 kB
May 15 16:41:28 <[g2]> Ok.... So to change the default command line before I forget :)
May 15 16:42:18 <beewoolie> Looks great.
May 15 16:43:03 <[g2]> Ok... I still gotta patch the environ.c file for the command line params ?
May 15 16:49:48 <[g2]> Ok... so I chaged the command line in mach-ixp42x and it recompiled, but I don't think it did it properly in the sense that the change didn't flow all the way through
May 15 16:50:16 <[g2]> make
May 15 16:50:16 <[g2]>   CC      src/mach-ixp42x/env.o
May 15 16:50:16 <[g2]>   LD      src/mach-ixp42x/built-in.o
May 15 16:50:16 <[g2]>   LD      apex
May 15 16:50:16 <[g2]>   OBJCOPY src/arch-arm/rom/apex.bin
May 15 16:50:16 <[g2]> bash-2.05b$ scp src/arch-arm/rom/apex.bin root@192.168.1.79:/home/root/apex_1.2.11_64.bin
May 15 16:50:43 <[g2]> root@avila:~# md5sum apex_1.2.11_64.bin
May 15 16:50:43 <[g2]> e7d9619778682c498a06eec37f5b4ee8  apex_1.2.11_64.bin
May 15 16:50:57 <[g2]>  md5sum src/arch-arm/rom/apex.bin
May 15 16:50:57 <[g2]> e7d9619778682c498a06eec37f5b4ee8  src/arch-arm/rom/apex.bin
May 15 16:51:53 <[g2]> beewoolie, is there anything you want me to look at before I just make clean; copy .config; make ?
May 15 16:52:11 <beewoolie> I don't know what you mean?
May 15 16:52:36 <[g2]> I'm saying that I think there is still a quirk in the make process
May 15 16:52:54 <beewoolie> How so?
May 15 16:52:59 <[g2]> the change I just made for the env.c didn't flow all the way throught
May 15 16:53:08 <[g2]> through
May 15 16:53:16 <beewoolie> Show me what you mean?
May 15 16:53:24 <[g2]> I just did above
May 15 16:53:38 <[g2]> I modified env.c right and did a make
May 15 16:53:54 <[g2]> it got compiled and apex was reloaded properly
May 15 16:54:03 <beewoolie> Can you show me the diff?
May 15 16:54:21 <[g2]> then I scp'd that to the target and verified on the target and the build the md5sum and it didn't have the change
May 15 16:55:45 <[g2]> /                 " root=/dev/slug"
May 15 16:55:46 <[g2]>                    " root=/dev/mtdblock4 rw"
May 15 16:55:49 <beewoolie> I fixed a problem with the makefiles in this release.  From your pasted output, I can see that it worked.
May 15 16:56:04 <beewoolie> If you send a diff for env.c, I'll look at it.
May 15 16:56:27 <[g2]> "//                 " root=/dev/slug"
May 15 16:56:27 <[g2]>                    " root=/dev/mtdblock4 rw"
May 15 16:56:40 <[g2]> There no " on the first of those two lines
May 15 16:56:52 <[g2]> that's an x-chat artifact
May 15 17:01:51 <[g2]> OK... after the clean it works fine
May 15 17:09:05 <beewoolie> [g2]: you still there? I've been running the FW through some of the admin stuff and it all looks OK.
May 15 17:20:26 <[g2]> FW ?
May 15 17:20:36 <[g2]> firmware
May 15 17:22:55 <[g2]> bb in a couple hours
May 15 17:23:13 <[g2]-away> I'll try the slug then
May 15 20:46:09 <ByronT> IRC Channel Special Announcement
May 15 20:46:23 <ByronT> OpenSlug 1.12 beta firmware binary is available for download at http://www.openslug.org
May 15 20:46:38 <ByronT> Unslung 4.20 beta firmware binary is available for download at http://www.unslung.org
May 15 20:49:27 <[g2]> beewoolie-afk, hey did you get my e-mail ?
May 15 20:49:39 <beewoolie-afk> [g2]: Just reading it.
May 15 20:56:11 <beewoolie-afk> Are we using APEX for any of these releases?
May 15 20:56:53 <[g2]> beewoolie-afk, NO.
May 15 20:57:00 <[g2]> Not yet :)
May 15 20:57:12 <beewoolie-afk> Just curious.
May 15 20:57:30 <[g2]> Ummm.. we usually test stuff a lot more
May 15 20:57:31 <ByronT> it's probably in OpenSlug's future.....
May 15 20:59:27 <beewoolie-afk> I hope it's OK if I hang on the JTAG dongle for a bit.
May 15 21:00:00 <[g2]> beewoolie-afk, are you talking to me ?
May 15 21:00:07 <beewoolie-afk> Yeah. sorry.
May 15 21:00:25 <[g2]> beewoolie-afk, Ummmm that was a 1-way ticket
May 15 21:00:55 <beewoolie-afk> Really?  You're a superstar.
May 15 21:01:21 <beewoolie-afk> Dollface is calling us super geeky right now.
May 15 21:01:34 <[g2]> give her a hug for me
May 15 21:01:58 <[g2]> and she's right. we are super geeky
May 15 21:09:15 <[g2]> beewoolie-afk, and all good night.
May 15 21:09:20 <[g2]> ByronT, congrats on the release
May 15 21:09:48 <ByronT> no, thank you and all of the other devs who put in the hard work
May 15 21:10:15 <[g2]> well we've got a great community and it just keeps getting better
May 15 21:10:30 <[g2]> I'm just happy to be a part of it
May 15 21:16:22 <beewoolie-afk> ...nite.
May 15 21:19:04 <ka6sox-away> nite
May 15 21:19:16 <ka6sox-away> oh your still here!
May 15 21:19:20 <beewoolie-afk> ka6sox-away: Hey.
May 15 21:19:30 <ka6sox-away> heya...
May 15 21:19:31 <beewoolie-afk> did you hear?  We've got APEX working.
May 15 21:19:32 <ka6sox-away> wazzup
May 15 21:19:35 <ka6sox-away> w00t!
May 15 21:19:37 <beewoolie-afk> Full on.
May 15 21:19:42 <ka6sox-away> excellent1
May 15 21:19:59 <beewoolie-afk> Version 1.2.11 boots on the slug and G2's avilla.  he got the GigE.  We've got USB
May 15 21:20:02 <beewoolie-afk> ...and ethernet.
May 15 21:20:14 <ka6sox-away> excellent
May 15 21:20:21 <ka6sox-away> did you ever get my jtag dongle?
May 15 21:20:27 <ByronT> ka6sox-away- away!! Larry, we're officially released!
May 15 21:20:31 <ka6sox-away> or did the mail eat it?
May 15 21:20:44 <beewoolie-afk> I thought that you saw that I got it a couple of hours after I got the one from g2.
May 15 21:21:01 <ka6sox-away> no..I didn't see it!
May 15 21:21:03 <beewoolie-afk> ka6sox-away: Do you want me to send it back?  Or can I hang on to it for a while to use in testing?
May 15 21:21:14 <ka6sox-away> hang on to it...do the testing.
May 15 21:21:52 <beewoolie-afk> Cool.  I appreciate that.
May 15 21:22:12 <beewoolie-afk> I couldn't have figured out the APEX problem without JTAG.
May 15 21:22:14 <ka6sox-away> np...I want it done.
May 15 21:22:44 <beewoolie-afk> BTW, I've been thinking about our JTAG project again.
May 15 21:22:55 <ka6sox-away> excellent.
May 15 21:23:05 <ka6sox-away> we *need* faster JTAG...
May 15 21:23:09 <beewoolie-afk> Is there any way to use the FPGA to cache little program-lets for performing JTAG macros?
May 15 21:23:21 <beewoolie-afk> Way.  This dongle thing is practically impossible.
May 15 21:23:31 <beewoolie-afk> The only saving grace has been that APEX is only 30K.
May 15 21:23:57 <beewoolie-afk> We can always bootstrap flashing with APEX, but I'd like to have an efficient JTAG solution.
May 15 21:24:10 * dyoung-zzzz me toos
May 15 21:24:26 <ka6sox-away> I agree...well...the BIG FPGA has 1MB of memory.
May 15 21:24:38 <ka6sox-away> soooo...we could use it for doing various things.
May 15 21:24:40 <beewoolie-afk> yo dyoung-zzzz 
May 15 21:25:00 <dyoung-zzzz> Yo G Dog.
May 15 21:25:11 <beewoolie-afk> is there an interesting mode with the USB 2232 where we can use the FPGA to operate the JTAG levers?
May 15 21:25:13 <ka6sox-away> hiya dyoung-zzzz 
May 15 21:25:21 <beewoolie-afk> dyoung-zzzz: Did ya hear?  We've got APEX running.
May 15 21:25:37 <dyoung-zzzz> Yeah, I've been following along for the past 24hrs. :-)
May 15 21:25:58 <beewoolie-afk> The problem, I think, is that I needed to perform a PCI reset and send a couple of configuration commands to the PCI controller.
May 15 21:26:04 <beewoolie-afk> Not much, really.
May 15 21:26:20 <dyoung-zzzz> Cool!
May 15 21:26:34 <dyoung-zzzz> And I'm glad it was a 2-for-1 special.
May 15 21:26:58 <beewoolie-afk> You and me both.  I didn't want to think I needed to link the NPE code to get the ethernet running in Linux.  Phooey!
May 15 21:27:48 <ka6sox-away> okay so what does this mean?
May 15 21:28:09 <beewoolie-afk> What does what mean?
May 15 21:28:10 <ka6sox-away> is APEX still small? or do we have a lot of Hooey to get it all that stuff going.
May 15 21:28:20 <beewoolie-afk> No.  APEX is about 30K.
May 15 21:28:27 <ka6sox-away> VERY Small
May 15 21:28:28 <beewoolie-afk> I'm looking into adding USB support.
May 15 21:28:45 <ka6sox-away> nice
May 15 21:28:48 <beewoolie-afk> That might add some 10-20k (at the worst).
May 15 21:28:58 <beewoolie-afk> I don't really know because I'm not sure how the interfaces work.
May 15 21:29:07 <ka6sox-away> ah...okjay
May 15 21:29:15 <beewoolie-afk> USB, though, would give us some really nice options.  We could read the kernel from a USB disk.
May 15 21:29:16 <ka6sox-away> so we need a FASTER JTSG.
May 15 21:29:22 <beewoolie-afk> Rite.
May 15 21:29:32 <ka6sox-away> yes we could.
May 15 21:29:37 <beewoolie-afk> I still want JTAG because I know that this is not the last project.
May 15 21:29:47 <ka6sox-away> ya
May 15 21:30:23 <ka6sox-away> getting some of this hardware going is still going to require JTAG and projects with FPGA's/CPLD's
May 15 21:30:27 <ka6sox-away> require it :)
May 15 21:30:35 <beewoolie-afk> Here's one of my questions.  Is the parallel port JTAG interface slow because of the 1MHz limit on signaling?  Or is it slow because the algorithms are sloppy?  Will 6MHz only be 6* faster?
May 15 21:30:38 <ka6sox-away> (rite dyoung-zzzz 
May 15 21:32:07 <ka6sox-away> 6mhz will only be 6X faster..
May 15 21:32:26 <ka6sox-away> 1 problem with the Xscale is the size of the BSDL
May 15 21:32:32 <ka6sox-away> its 498bits
May 15 21:32:34 <ka6sox-away> VERY long
May 15 21:33:20 <ka6sox-away> since we only need to program 30KB instead of 256KB (for REDBOOT) the 6X will make it snappy
May 15 21:34:57 <dyoung-zzzz> Right.
May 15 21:35:14 <ka6sox-away> currently it takes 40 minutes for 256KB.
May 15 21:36:22 <dyoung-zzzz> isnt 6mhz close to the limit of the IXP42x JTAG anyways?
May 15 21:36:35 <dyoung-zzzz> Yes I realise there will be other targets.
May 15 21:37:07 <ka6sox-away> 6mhz is max for the IXP jtag.
May 15 21:37:23 <ka6sox-away> but its a HUGE BSDL
May 15 21:38:40 * ka6sox-away can't wait until I get a Spartan IIIe board.
May 15 21:41:26 <ka6sox-away> okay so the FT2232 and a CPLD to do voltage conversion...
May 15 21:42:16 <ka6sox-away> I'm going to have to send a email to Xilinx about using different I/O voltages / section ...to see if I can use the CPLD for matching voltages to different targets.
May 15 21:42:49 <dyoung-zzzz> wait, what was wrong with what I suggested the other day?
May 15 21:43:14 <ka6sox-away> refresh my sun baked brain...
May 15 21:43:47 <dyoung-zzzz> ie: power the cpld vcc with the usb, but pullup the jtag-side to the outputs using the 95xx oc trick.
May 15 21:44:22 <ka6sox-away> of course...never mind...I'm fried...out in the Sun all day.
May 15 21:44:27 <dyoung-zzzz> "pull up to the JTAG DUT Vcc"
May 15 21:46:48 <ka6sox-away> yes..that will work.
May 15 21:47:59 <ka6sox-away> okay I want to use a 44pin device instead of a 64 pin one..or maybe even smaller.
May 15 21:48:24 <ka6sox-away> I have to go lay down...too much sun today...
May 15 21:48:32 <ka6sox-away> but I like these Ideas.
May 15 21:48:36 <ByronT> get some rest Larry!
May 15 21:48:45 <ka6sox-away> catch up with you guys later.
May 15 21:49:11 <beewoolie-afk> Cool.  I look forward to working with the new hardware.
May 15 21:50:13 <ka6sox-away> cya a little laters...I'll be on from the couch after a little rest.
May 15 22:02:46 <dyoung-zzzz> Even the 44-pin part is overkill.  Toobad there isnt a smaller one.
May 15 22:04:00 <ka6sox-away> there is...I'm looking now.
May 15 22:53:49 <beewoolie-afk> At ~500 bits in the chain and a 1MHz scan rate, seems like we should be able to write at least 512B/s, no?
May 15 22:54:19 <beewoolie-afk> That's 2000 complete scans a second.
May 15 22:55:01 <beewoolie-afk> I suspect that there is an algorithmic opportunity here for increased throughput.
May 15 22:55:32 <beewoolie-afk> nite all.
May 15 22:55:43 <ByronT> good night!
**** ENDING LOGGING AT Sun May 15 23:59:57 2005