**** BEGIN LOGGING AT Fri Jan 20 02:59:58 2006
Jan 20 06:57:53 <AchiestDragon> ka6sox:  ka6sox-office  ,, ping 
Jan 20 07:14:37 <vmaster> my best guess is that he isn't up yet
Jan 20 07:14:48 <AchiestDragon> np
Jan 20 07:14:57 <vmaster> usually ~16:00 your time
Jan 20 07:17:18 <AchiestDragon> k , is working on the high speed jtag board , looks like we could get a bit faster speed if we use .5" pitch ribbon cable between the board and the adaptor plug 
Jan 20 07:18:51 <AchiestDragon> the cheapest option would be a 40pin (80way cable) like the ata133 ide drives use , but that is a 2" wide cable  so not realy a practical option  
Jan 20 07:19:24 <vmaster> are there lvds ports available on the s3?
Jan 20 07:21:27 <AchiestDragon> grr , did not save the data sheet , 1 min 
Jan 20 07:22:49 <vmaster> as i understand it, lvds seems to be a common answer to the problems that arise when having to go from one board to another at higher speeds
Jan 20 07:31:44 <AchiestDragon> the fpga will do    GTL,HSTL,LVCMOS,LVTTL,PCI,SSTL and  diferential modes LDT,LVDS,LVPECL,RSDS,HSTL and SSTL
Jan 20 07:31:47 <AchiestDragon> but 
Jan 20 07:33:40 <AchiestDragon> that is direct from the fpga and its buffered with a auto sencing level conveter so we will just use one standard from the fpga , and the buffers will convert the levels for us 
Jan 20 07:38:06 <AchiestDragon> theres more than that reason for using buffers also , in that if you blow up an input its easyer and cheaper to change a 24 pin buffer than a 144pin fpga
Jan 20 07:40:17 <AchiestDragon> ie when you acidentaly mistake a 10 pin rs232c header for a 10 pin jtag port and get +and -12v up the interface 
Jan 20 07:46:14 <vmaster> okay, the arm realview ice offers either a normal connection, or a lvds connection that uses an additional small board that plugs directly into the standard 20-pin arm header - and the faq states that this probe is necessary at speeds >=20mhz
Jan 20 07:46:42 <vmaster> so the buffer converting between lvds and target voltage sits on the probe-pcb
Jan 20 07:47:43 <AchiestDragon> yes , as we want the board to opperate faster the main problem is the loss of the .1" pitch cable 
Jan 20 07:48:21 <AchiestDragon> so the use of the .05" pitch cable is better suited
Jan 20 07:51:59 <AchiestDragon> but to use it means a diferent style connector from the board to an adaptor board with the socket to connect directly to the jtag port beeing tested 
Jan 20 07:54:17 <vmaster> well, having to use adapter boards is quite likely, looking at all the different layouts
Jan 20 07:55:25 <AchiestDragon> yes so not a big problem that way if the cable connector to the adaptor and the jtag test board are diferent 
Jan 20 07:56:27 <AchiestDragon> http://www.farnell.com/datasheets/66315.pdf  < this seems sutable 
Jan 20 08:30:56 <ka6sox> yawn
Jan 20 08:33:59 <ka6sox> its too early to be up
Jan 20 08:34:12 <AchiestDragon> :)
Jan 20 08:35:33 <ka6sox> mawnin AchiestDragon 
Jan 20 08:35:44 <ka6sox> (thats Cajun for good morning)
Jan 20 08:36:51 <ka6sox> AchiestDragon, I read the backlog and am worried about the same thing
Jan 20 08:37:09 <ka6sox> obviously we could save some pins if we used a smaller connector.
Jan 20 08:37:30 <ka6sox> but a 10 pin might not be the right connector
Jan 20 08:37:46 <ka6sox> we also need at least a common ground for the boards.
Jan 20 08:37:57 <ka6sox> so that would be 12 pins
Jan 20 08:38:22 <ka6sox> the LVDS certianly would be very fast (think U320 SCSI)
Jan 20 08:38:49 <ka6sox> when we crank up the speed think Terminations.
Jan 20 08:39:12 <AchiestDragon> well theres  10 , 12, 16 and 20 pin jtag connectors in use , so we are going to need an adaptor at the end of the cable anyway 
Jan 20 08:39:52 <ka6sox> right
Jan 20 08:40:16 <ka6sox> the current adapter (which can eventually be changed) is a 40 pin DIP one.
Jan 20 08:40:36 <ka6sox> that can change after we test.
Jan 20 08:41:09 <AchiestDragon> if we drove the jtag port directly from the fpga , we would lose the 2.5ns buffer delay , but lose the protection that the buffers offer 
Jan 20 08:42:41 <AchiestDragon> there could still be auto voltage setting , but may need the fpga to be configured to use them right ,, will have to read the data for the fpga see if that would be ok 
Jan 20 08:44:07 <ka6sox> I think that we need to keep the buffers there
Jan 20 08:44:16 <AchiestDragon> yes 
Jan 20 08:44:33 <ka6sox> the auto voltage and driving capability of the driver chip is very important
Jan 20 08:45:53 <AchiestDragon> not a problem , there maybe a problem with delays on the buffers , been reading the data for them 
Jan 20 08:46:32 <ka6sox> okaiy
Jan 20 08:46:51 <ka6sox> unfortunately today is an early work day so I must go now.
Jan 20 08:46:56 <ka6sox> back in 4hrs.
Jan 20 08:49:03 <AchiestDragon> k
Jan 20 09:00:24 <velinp> ka6sox: ping
Jan 20 09:04:45 <vmaster> [16:47] < ka6sox> unfortunately today is an early work day so I must go now.
Jan 20 09:04:45 <vmaster> [16:47] < ka6sox> back in 4hrs.
Jan 20 09:04:48 <vmaster> that was 15 minutes ago
Jan 20 09:05:25 <velinp> vmaster: thanks
Jan 20 09:43:04 <[g2]> lennert hey
Jan 20 10:30:22 <velinp> [g2]: ping
Jan 20 10:36:26 <[g2]> velinp pong
Jan 20 10:36:41 <[g2]> velinp waazz up ?
Jan 20 10:37:08 <velinp> hi; i'm preparing to replace redboot (hdw not yet ready :( ); which mtdblock on a nslu2 is redboot in?
Jan 20 10:38:26 <[g2]> velinp do you have confirmed JTAG ?
Jan 20 10:38:52 <velinp> [g2], no; I only intend to read the mtd, not write it ):
Jan 20 10:39:25 <[g2]> well replacing RedBoot would be writing it in my book
Jan 20 10:39:59 <velinp> [g2], ??
Jan 20 10:40:05 <vmaster> hence the preparing, i guess
Jan 20 10:40:19 <vmaster> i.e. he just wants to read it to have a backup
Jan 20 10:40:28 <velinp> yes, I want to play safe
Jan 20 10:41:15 <velinp> and read in yesterday's log that maybe a byte/word swap was necessary; is it?
Jan 20 10:41:39 <velinp> I mean if I need to reflash the readboot later
Jan 20 10:42:14 <[g2]> the kernel console output prints out the partitions
Jan 20 10:42:22 <[g2]> it's the first one numbered 0
Jan 20 10:42:43 <[g2]> so,  dd if=/dev/mtdblock0 of=redboot.bin 
Jan 20 10:42:56 <[g2]> backs up your Redboot to the file redboot.bin
Jan 20 10:43:20 <velinp> it is 256K, md5 is 3785ddc9def010c8ab108855fce0d9ca, but it includes my MAC?
Jan 20 10:43:27 <[g2]> it is VERY IMPORTANT to check the if versus the of !!!
Jan 20 10:43:43 <[g2]> yeah near the end
Jan 20 10:44:12 <[g2]> I think the first 254+K are identical for all NSLU2 users
Jan 20 10:44:34 <[g2]> it's probably only the last 100/140 bytes that are different
Jan 20 10:45:57 <velinp> my md5 on the first 254 K is f063eb7f8c77d3e38bf250d25edf3a1b; could you confirm (as I only have 1 slug)
Jan 20 11:08:45 <[g2]> velinp I haven't touched the slugs in 4-5 months... I'm running the Loft
Jan 20 11:10:32 <velinp> [g2]: ok, thanks and good luck with the loft; do you think beewoolie might be able/willing to help me?
Jan 20 11:11:25 <[g2]> velinp as in openslug
Jan 20 11:11:51 <velinp> yes, i am
Jan 20 11:41:19 <velinp> beewoolie: hi; care to help me verify the redboot image I dumped off mtdblock0 ?
Jan 20 11:55:06 <beewoolie-afk> velinp: I'm not sure I can help.
Jan 20 11:55:34 <beewoolie-afk> You can pull the redboot image from an openslug flash image.
Jan 20 11:57:29 <velinp> beewolie-afk: i have done upslug -u several times; i thought it did not touch redboot
Jan 20 12:04:22 <prpplague> beewoolie-afk: hey hey
Jan 20 12:04:27 <beewoolie-afk> poenhey
Jan 20 12:04:27 <prpplague> beewoolie-afk: whats cookin?
Jan 20 12:04:30 <beewoolie-afk> hey..
Jan 20 12:04:35 <prpplague> hehe
Jan 20 12:04:38 <beewoolie-afk> Been hacking on the JTAG flash code.
Jan 20 12:04:42 <beewoolie-afk> It's coming along.
Jan 20 12:04:44 <prpplague> beewoolie-afk: cool
Jan 20 12:05:06 <beewoolie-afk> My goal, for the moment, is to determine how fast I can flash this way using a parallel port JTAG interface.
Jan 20 12:05:14 <beewoolie-afk> This will give me a baseline for comparison.
Jan 20 12:05:19 <prpplague> beewoolie-afk: cool
Jan 20 12:08:57 <beewoolie-afk> prpplague: et tu?
Jan 20 12:16:39 <prpplague> beewoolie-afk: finally got full RW access to buildroot,busybox,uclibc and such, so i've been uploading a ton of fixes
Jan 20 12:17:30 <prpplague> beewoolie-afk: trying to get rid of this legacy usb issue, its like a nasty bugger on my finger, just can't seem to get rid of it
Jan 20 12:20:48 <beewoolie-afk> bummer
Jan 20 12:21:15 <prpplague> beewoolie-afk: probably get you a patch saturday after noon for the s3c2410
Jan 20 12:21:29 <prpplague> beewoolie-afk: and then sunday probably the mmc/sd patch for the lnode80
Jan 20 12:21:35 <beewoolie-afk> np.
Jan 20 12:21:59 <prpplague> beewoolie-afk: i'm getting ready to check in apex to buildroot
Jan 20 12:22:11 <beewoolie-afk> Awesome!
Jan 20 12:23:06 <beewoolie-afk> BTW, Voodoo_Z flashed apex into his slug and finds that it works.  It boots faster than RedBoot, so he was motivated to use it.
Jan 20 12:23:47 <prpplague> hehe
Jan 20 12:24:06 <prpplague> beewoolie-afk: well if you have any busybox,buildroot issues, let me knwo
Jan 20 12:24:18 <beewoolie-afk> Not at the moment.
Jan 20 12:24:34 <beewoolie-afk> I have been interested in  uclib, but it's too low priority for me to get into it.
Jan 20 12:30:33 <prpplague> beewoolie-afk: buildroot works great
Jan 20 12:30:41 <prpplague> beewoolie-afk: i add the lnode80 to the build
Jan 20 12:30:52 <prpplague> beewoolie-afk: so adding the other lh7952x devices would be easy
Jan 20 12:31:00 <beewoolie-afk> That isn't what I'm looking for.
Jan 20 12:31:10 <beewoolie-afk> I'd like to build a uclib toolchain for the Sharp BSp.
Jan 20 12:31:16 <prpplague> beewoolie-afk: right
Jan 20 12:31:19 <prpplague> beewoolie-afk: thats what this does
Jan 20 12:31:33 <beewoolie-afk> It's just that I've been lazy about updating the BSP to cope with anything other than crosstool.
Jan 20 12:31:41 <prpplague> beewoolie-afk: ahh
Jan 20 12:31:53 <beewoolie-afk> as I wrote, it's very low priority.
Jan 20 12:32:07 <beewoolie-afk> If someone wants a small development system, they can experiment on their own.
Jan 20 12:32:18 <beewoolie-afk> I mean, small runtime.
Jan 20 12:32:26 <prpplague> yea
Jan 20 12:32:46 <prpplague> well like i said its as easy as pie to do, not like getting OE running
Jan 20 12:33:26 <beewoolie-afk> I looked at buildroot when I wrote the BSP.  I don't recall why I chose not to use it.  There was a show stopper there somewhere.
Jan 20 12:33:56 <beewoolie-afk> and believe me, I'd have used someone else's solution if I could have.
Jan 20 12:40:03 <prpplague> hehe
Jan 20 12:42:40 <beewoolie-afk> Damn redboot.  Their network code is quite buggy.
Jan 20 14:21:55 <ka6sox-office> ugh...back from the mines
Jan 20 14:50:17 <beewoolie-afk> lennert: ping?
Jan 20 16:00:35 <lennert> pong
Jan 20 16:02:46 <lennert> beewoolie-afk: pong
Jan 20 16:04:03 <[g2]> lennert hey
Jan 20 16:05:08 <[g2]> lennert I'll be getting a spec for the Parallel FPGA dongle next week and a can get several devices
Jan 20 16:06:28 <lennert> okay, cool
Jan 20 16:06:34 <lennert> what do they cost each?
Jan 20 17:20:26 <vmaster> [g2]: parallel as in "PC parallel port"?
Jan 20 17:24:59 <[g2]> vmaster yes Parallel on S3
Jan 20 17:25:14 <[g2]> lennert you get one free
Jan 20 17:25:16 <[g2]> ;)
Jan 20 17:27:02 <vmaster> i have a parallel port to cpld dongle here, and the limiting factor is the parallel port access times - even using epp accesses, you wont achieve more than 1 to 1.5 us per access
Jan 20 18:29:52 <[g2]> vmaster I think FPGA has it's own clock
Jan 20 18:30:09 <[g2]> I'm pretty sure it runs at least at 8MHz
Jan 20 18:30:15 <[g2]> for TCLK
Jan 20 19:48:42 <beewoolie-afk> [g2]: Neato.
Jan 20 19:49:02 <beewoolie-afk> Is this the one that gateworks sells?
Jan 20 19:49:27 <beewoolie-afk> lennert: Hey.  The question I had was whether or not sid was good on the slug.
Jan 20 19:50:24 <[g2]> beewoolie-afk not yet
Jan 20 19:50:40 <[g2]> beewoolie-afk you're welcome to get one too you know
Jan 20 19:50:47 <beewoolie-afk> Really?  I'd like that.
Jan 20 19:50:59 <beewoolie-afk> I'm making good progress on my JTAG code.
Jan 20 19:51:01 <[g2]> well I sent you your last cable right ?
Jan 20 19:51:07 <[g2]> heh
Jan 20 19:51:20 <beewoolie-afk> I'm using the one from ka6sox at the moment because of the fly leads.
Jan 20 19:51:28 <[g2]> ah
Jan 20 19:51:35 <beewoolie-afk> But the one you sent is the only one I've used on the slug.
Jan 20 19:51:43 <[g2]> nod
Jan 20 19:52:02 <beewoolie-afk> My plan is to get this code working for the slug so we can flash over JTAG without having to wait over-night.
Jan 20 19:52:07 <[g2]> Gateworks is writing up their API
Jan 20 19:52:12 <beewoolie-afk> Excellent.
Jan 20 19:52:23 <beewoolie-afk> So, yes.  I'd like one, too.
Jan 20 19:52:24 <[g2]> then we can compare APIs 
Jan 20 19:52:28 <beewoolie-afk> :-)
Jan 20 19:52:57 <[g2]> and I'm sure they can probably do some FGPA tweaks if need be
Jan 20 19:54:05 <beewoolie-afk> It would help prove the concept.
Jan 20 19:55:35 <[g2]> prove which concept ?
Jan 20 19:55:54 <beewoolie-afk> The protocol for handling JTAG scanning and testing.
Jan 20 19:56:40 <beewoolie-afk> If the FPGA can be reprogrammed by someone like me, then I can evaluate protocol enhancements before committing other resources.
Jan 20 20:17:03 <[g2]> I'd think the FPGA could be reporgrammed
Jan 20 20:17:16 <[g2]> clearly that'd be what we want
Jan 20 20:17:48 <[g2]> get a default bitsteram (or what ever they are called) which conforms to the API
Jan 20 20:18:07 <[g2]> and then we can reflash the flasher
Jan 20 20:18:30 <[g2]> test or reset it back to the original
Jan 20 20:18:56 <[g2]> they could come with the digilent cable which can reflash the flasher :)
Jan 20 20:21:51 <beewoolie-afk> Sounds kinda dirty.
Jan 20 20:31:04 <[g2]> well boot strapping is always dirty
Jan 20 20:31:40 <[g2]> having a eeprom on the adapter with an option to override the loading is another option
Jan 20 21:17:35 <AchiestDragon> well ram bandwidth on the high speed adaptor is not going to be a problem ,  16 bit  read or write cycles of upto 167mhz , looks like its if the fpga will be able to drive it that fast 
Jan 20 21:24:06 <[g2]> AchiestDragon I dunno how big the BlockRAM is on the S3
Jan 20 21:24:15 <[g2]> I'd image stuff may be in there
Jan 20 21:25:10 <AchiestDragon> thats not the block ram thats the external 32mb sdram chips max speed 
Jan 20 21:25:27 <[g2]> ah
Jan 20 21:27:53 <AchiestDragon> if the fpga was fast enough that would allow it to burst the full 32mb at  2Ghz 
Jan 20 21:28:04 <AchiestDragon> on the jtag 
Jan 20 21:29:24 <AchiestDragon> but should easy cope with 40Mhz , maybe even upto 160Mhz  
Jan 20 21:29:25 <[g2]> That'd be sweet :)
Jan 20 21:30:26 <AchiestDragon> it also would give us a 160Mhz 16bit logic analizer capability 
Jan 20 21:33:39 <AchiestDragon> a bit more usefull than a logic probe for debuging with 
Jan 20 22:05:53 <velinp> goog morning from BG; ka6sox: ping
Jan 20 22:08:15 <velinp> good morning from .bg :) ka6sox: ping
Jan 20 22:08:24 <ka6sox> morning
Jan 20 22:08:48 <velinp> hi, are you managing bob and wendy?
Jan 20 22:09:18 <ka6sox> the base system but not the buildd..that is yoe.
Jan 20 22:11:27 <velinp> ok, I was looking what the buildds are doing; (mine is stuck with doxygen_1.4.6-1; I noticed "vfork: Cannot allocate memory" on wendy, building gcj-4.0_4.0.2-6
Jan 20 22:12:25 <ka6sox> then its run out of Memory again...bob has been idle for 2 weeks.
Jan 20 22:12:49 <velinp> so i though maybe more virtmem is necessary; on velnas i have 32 + 176; have any idea how much mem we shoud have ?
Jan 20 22:12:58 <velinp> s/though/thought/
Jan 20 22:12:59 <purl> velinp meant: so i thought maybe more virtmem is necessary; on velnas i have 32 + 176; have any idea how much mem we shoud have ?
Jan 20 22:13:39 <ka6sox> we acutally put up about 512MB on Bob and it grunted thru building gcc
Jan 20 22:14:07 <velinp> 512 swap not enough for gcc ?
Jan 20 22:15:58 <ka6sox> nope
Jan 20 22:16:27 <ka6sox> I think that eventually we used about 800MB
Jan 20 22:17:12 <velinp> ok, i will setup 1G on velnas, in some file; btw, wouter fixed compilers, etc on velnas, but a reboot was necessary so that buildd starts again
Jan 20 22:17:53 <ka6sox> okay I'll try restarting Bob
Jan 20 22:19:49 <velinp> wouter said it should be safe
Jan 20 22:20:51 <ka6sox> okay it restarted...takes a few minutes to start the process
Jan 20 22:21:45 <velinp> on nslu2, there are /dev/mtdblock[0-5], redboot in 0; is partitioning the flash a stricture in it, or just a convention (between humans) ?
Jan 20 22:24:14 <ka6sox> I think that redboot has to be there. but the rest is negotiated.
Jan 20 22:25:15 <ka6sox> in the base partition.
Jan 20 22:25:26 <velinp> about bob: i waited for buildd-watcher (cron 0,20,40) to restart the buildd by itself;
Jan 20 22:26:46 <velinp> the strataflash has a base partition (like harddisks?) where the structure is defined?
Jan 20 22:29:58 <ka6sox> best to ask this in #nslu2-linux
Jan 20 22:31:12 <velinp> ok, thanks; nice evening to you :)
Jan 20 22:32:36 <ka6sox> thanks..have a good day.
Jan 20 22:33:14 <velinp> bye; see you later (when I finally have the hdw modified; friend said (maybe) next week :)
Jan 20 22:33:48 <AchiestDragon> :)
Jan 20 22:35:01 <ka6sox> cool
**** ENDING LOGGING AT Sat Jan 21 02:59:56 2006