**** BEGIN LOGGING AT Mon Jan 23 02:59:58 2006 Jan 23 03:08:48 ka6sox: i fixed another distortion bug, but there's still one left Jan 23 03:09:24 ka6sox: (or two) Jan 23 06:05:41 www.digilentinc.com down for other folks here too? Jan 23 06:07:53 yep Jan 23 06:08:18 well, "Service Unavailable" Jan 23 06:08:25 so something is working Jan 23 06:08:26 yeah, here too Jan 23 06:08:35 yeah, but not enough :) Jan 23 08:41:33 coffee makes the world go round. Jan 23 08:43:28 indeed Jan 23 08:43:42 got your messages. Jan 23 08:43:46 great Jan 23 08:44:18 how is school? Jan 23 08:44:34 struggling with some concepts Jan 23 08:44:49 but doing great otherwise, i'm way ahead of schedule Jan 23 08:46:16 ka6sox: do you have the xupv2p board and a scope by any chance? :) Jan 23 08:48:40 I have both but am in meetings this morning Jan 23 08:48:56 okay Jan 23 08:49:01 no hurry in any case Jan 23 08:49:05 i'm working on the ethernet now Jan 23 08:49:19 ethernet? Jan 23 08:49:24 yeah Jan 23 08:49:27 the ethernet port on the xupv2p Jan 23 08:49:32 ah Jan 23 08:49:33 there's a 10/100 on there Jan 23 08:49:39 :) Jan 23 08:50:07 Coffee's on.... Jan 23 08:50:11 back in a bit Jan 23 09:26:29 v Jan 23 10:31:06 ka6sox: so how much would the pc104 s3 board be? Jan 23 10:32:11 dunno yet...still designing. Jan 23 10:33:00 okay Jan 23 10:33:23 i'm training a friend in vhdl Jan 23 10:34:00 I hope to know *soon* Jan 23 10:52:35 fpga at $22 , ram $10 to 15 , 12* 74hc series chips at $4 a opamp $2 some resitors and caps so allow $10 and $15 for the pcb atm Jan 23 10:53:04 theres the power regulators and fpga config circut to do Jan 23 10:54:45 ho and £3+£4 *2 for the first jtag adaptor and £3 each for any others ( for the high speed connectors and cable Jan 23 10:55:36 and allow $10 for the pc104 connector and headders used Jan 23 10:58:54 so about $150 as a verry rough estimate , but should be less than that Jan 23 13:21:22 prpplague: patches? Jan 23 13:22:02 beewoolie: yea they are ready, but i've been doing buildroot cleanup all day, as i'm the defacto person for buildroot patches these days Jan 23 13:22:19 beewoolie: started with 187 cases in the bug/patch system this morning Jan 23 13:22:24 beewoolie: down to about 107 Jan 23 13:22:34 prpplague: You're the IT guy for buildroot? Jan 23 13:23:35 beewoolie: looks that way Jan 23 13:23:44 fascinating Jan 23 13:24:01 Which target of yours has a problem with buffered flash writes? Jan 23 13:24:26 both the lh79520 and s3c2410 when using 16-bit wide flash access Jan 23 13:24:38 Oh, yeah, and among your lh79520 designs, what signals are you using for enable flash writes? Jan 23 13:24:41 they both use the TE28F320 Jan 23 13:24:53 So, do you think it's the chip? Jan 23 13:25:25 beewoolie: yea i would suspect it is since i have another s3c2410 board (the little chips) that doesn't seem to be bothered by it Jan 23 13:26:02 Oh, so you mean that APEX doesn't work, but other software does. Jan 23 13:26:27 And what anout the flash write enable lines ? Jan 23 13:28:16 one sec Jan 23 13:29:38 beewoolie: no i mean apex works with both boards, but the littlechips board with amd flash works fine with the buffered flash writes, but not with our board with the the intel flash Jan 23 13:29:55 beewoolie: the lines are connected identical Jan 23 13:30:00 OK. Perhaps I have the algorithm wrong. Jan 23 13:30:22 About the lines, the LPD boards have changed their schematics. I am trying to get an idea about why they may have done this. Jan 23 13:30:36 Is the TE28F320 the intel chip? Jan 23 13:31:30 yea Jan 23 13:31:56 beewoolie: our layouts for the lh79520 board is based on the ref schematic from sharp Jan 23 13:33:41 The old LPD design uses nMWE0. The new design uses a different line, but I need to get the updated schematic to verify. Jan 23 13:34:09 It's a lame change for them to make on the sly. Jan 23 13:34:21 I found out because a customer called with a problem writing to flash. Jan 23 13:37:26 beewoolie: yea, i've never been very happy with logic pd's professionanlism Jan 23 13:37:55 I'll get the Intel data sheet and see what I can see. Jan 23 13:38:04 okie dokie Jan 23 13:38:49 you're having a problem with the TE28F320? Jan 23 13:39:17 probably a software issue. It doesn't like by buffered write code Jan 23 13:39:57 prpplague: I found a reference to this flash part that says it isn't CFI compliant. Jan 23 13:40:07 what is the full part number of the chip you're using? Jan 23 13:40:52 that chip doesn't have a write buffer Jan 23 13:41:05 at least the TE28F320C3 i'm using doesn't have one Jan 23 13:41:07 vmaster: that would explain the problem :-) Jan 23 13:41:36 prpplague: So, are you sure that your chip has a write buffer? Jan 23 13:42:19 [g2]: Do you remember how long it took to program redboot into flash using openwince's jtag? Jan 23 13:43:03 beewoolie: iirc it does not, thats why i requested the ability to turn it off in apex Jan 23 13:43:42 Ah, OK. I thought it had one and the driver couldn't use it. Jan 23 13:44:04 APEX only includes one write routine, for compactness. Jan 23 13:44:26 beewoolie: http://www.intel.com/design/flcomp/datashts/290645.htm Jan 23 13:48:49 According to this, it is CFI compliant. The MTD thread must have been about a different part. Jan 23 13:49:21 the C3 is cfi compliant, the B3 isn't Jan 23 13:49:36 beewoolie: well it is cfi compliant but there are some querks Jan 23 13:50:13 beewoolie: as the cfi specs say that several of the registers don't require an address, however the intel one does Jan 23 13:50:25 beewoolie: so imho its not 100% cfi compliant Jan 23 13:50:43 It seems to work aside from the write buffer issue. Jan 23 13:51:43 I suppose it wouldn't be too much to ask that APEX checks for the write buffer and reports an error if there isn't one...it requires one. Jan 23 13:52:04 the write-buffer size field is correctly set to 0 Jan 23 13:52:09 you could just check for that Jan 23 13:52:42 Right, it does that, but it doesn't cope with a zero value. Jan 23 14:08:58 prpplague: OK. The buffered write routine will return an error if the chip doesn't support it. Jan 23 14:19:06 beewoolie: lovely Jan 23 16:01:14 I have a preliminary result with the JTAG flash writing code. Jan 23 16:01:25 I'm able to write about 1K to flash every 1.45 seconds. Jan 23 16:01:55 This translates into about 6.2 minutes for a 256K write. Jan 23 16:02:15 Note that this is for a 32 bit wide flash bank comprised of two chips. Jan 23 16:02:28 I'll be doing some testing on a slug pretty soon here. Jan 23 16:03:16 also, this is using the ARM debug scan chain, instead of the BSDL boundary scan, and it is using the flash chip's buffered write mode. Jan 23 16:04:31 I expect that the best performance will come from downloading a flash-write helper into cache memory, so that there is only one JTAG transaction per 32 bit write. Jan 23 16:13:22 cheap pci fpga board: http://www.enterpoint.co.uk/moelbryn/raggedstone1.html Jan 23 16:13:38 ideal candidate for high-speed jtagging ;-) Jan 23 16:14:20 E100 or so Jan 23 16:18:56 PCI is problematic. Jan 23 16:19:22 lennert: it requires a chassis for installation. Jan 23 16:21:29 people have PCs? Jan 23 16:22:20 NO! could it be? Jan 23 16:22:28 not a good candidate. Jan 23 16:22:40 he he Jan 23 16:23:18 i have 5 PCs in this room alone.. guess i'll pulling up the world average, hm? :-) Jan 23 16:23:38 PCI has problems. Jan 23 16:24:06 :-( Jan 23 16:29:01 lennert: I want to be able to jtag from this laptop or other funky hardware if possible, not just from full-box PCs Jan 23 16:29:03 lennert: I use a notebook for most of my work with a server, locked in the dungeon, for the heavy lifting. Jan 23 16:29:17 yes, I have a PC. No, I'm not going to be plugging boards into it. Jan 23 16:29:22 it is cheap, but I'd rather hope for something more flexible Jan 23 16:30:09 And increasingly people have funky shuttle or EPIA boxes where the one valuable slot is already full of something Jan 23 16:32:22 beewoolie 6 mins for 256K is not bad. (with parallel I'm getting 50K in 19 mins or thereabouts) Jan 23 16:32:51 but I was hoping 'latest tech' could go even faster... Jan 23 16:32:57 wookey_: What software? Jan 23 16:33:04 jflash Jan 23 16:33:08 wookey_: I'm working my way up to better code. Jan 23 16:33:20 (well, jflash-balloon, but derived from intel's jflash Jan 23 16:33:26 This is the first working code. It uses the ARM debug registers, so it only works on ARMv4. Jan 23 16:33:36 Jflash isn't very graceful. Jan 23 16:33:47 no 'primitive' seems about right Jan 23 16:33:51 I hope to do much better with this naive (sort of) code. Jan 23 16:33:56 :-) Jan 23 16:34:11 I look forward to it Jan 23 16:34:14 The Xscale is amenable to some very elegant solutions. Jan 23 16:34:23 BTW how big is an APEX loader at the moment? Jan 23 16:34:30 wookey_: Depends on the options. Jan 23 16:34:46 You can get a version that is under 16 K if you disable most of the fancy stuff. Jan 23 16:34:53 OK, with minimal options, but enough to download something better Jan 23 16:34:55 The largest executables are about 60K. Jan 23 16:35:14 wookey_: It is designed to fit into SRAM on the Sharp LH processors. Jan 23 16:35:14 that sounds promising - the thing I liked about blob was that it was 19K Jan 23 16:35:43 for bootldr we have a minimal one (56K) to jflash then serial-download a 200K full-featured version Jan 23 16:35:48 It isn't 19K with all of the drivers. Jan 23 16:35:53 whole process is rather slow Jan 23 16:36:08 apex is full-featured at 60K. Jan 23 16:36:23 Actually, I don't really know the size of the largest versoins. Jan 23 16:36:27 It may only be about 50K. Jan 23 16:36:31 OK - so is anyone threatening to do pxa support? Jan 23 16:36:48 If I had HW, I'd support it. Jan 23 16:37:00 Adding a new target isn't very difficult. Jan 23 16:37:14 As long as it is ARM. Jan 23 16:37:27 what does it need? memoory set-up code and what else? Jan 23 16:37:44 How similar is it to IXP? Jan 23 16:37:57 I'm not sure - I've not had much to do with IXP Jan 23 16:38:02 The bulk of the changes are in the SDRAM and target init. Jan 23 16:38:04 they both come from intel :-) Jan 23 16:38:05 ...hang on... Jan 23 16:38:54 The IXP has only a couple of files: Jan 23 16:39:27 cmd-reset.c, exception_vectors.c, spinner-nslu2.c, pci,c, timer.c, initialize.c, serial.c Jan 23 16:39:31 A few. Jan 23 16:40:05 You need a serial driver, a timer, pci is for pci setups, you can add a custom reset command, and the most work goes into the initialize code. Jan 23 16:40:18 Gotta get the SDRAM inits right. Jan 23 16:40:36 So if we sent you a board you'd add support? That's tempting Jan 23 16:40:52 then we could concentrate on adding yaffs support Jan 23 16:40:53 There are a couple of header files that help the nor flash driver as well as a couple of other drivers. Jan 23 16:41:09 yaffs isn't hard, but I don't have anything with NAND flash ATM. I used to. Jan 23 16:41:24 It would be a good thing for several targets. Jan 23 16:41:29 yaffs read-only is less then 2K of code and we have an example Jan 23 16:41:43 After all, there is a JFFS2 driver. YAFFS can't be much more difficult. Jan 23 16:41:51 yaffs read-write is a bit more work, Jan 23 16:42:00 yaffs is much simpler than JFFS2 Jan 23 16:42:11 APEX doesn't do any FS writing. Jan 23 16:42:32 It could, but I've never wanted to do all of that work. Jan 23 16:42:36 OK - that'd be why it's small. How do you store a loaded image? Jan 23 16:42:48 raw write? Jan 23 16:42:51 What do you mean? Jan 23 16:43:06 Most of the time, the loader isn't responsible for storing the boot image. Jan 23 16:43:15 well if you upload a kernel it's handy if the bootloader can store it in flash Jan 23 16:43:28 You can download the kernel from an available medium, and go. Jan 23 16:43:41 the available medium is flash Jan 23 16:43:41 It can do a simple write to NOR/NAND flash. Jan 23 16:44:01 It doesn't have FS support for writing, EXT2, Jff2, FAT. Jan 23 16:44:08 But it can read fine. Jan 23 16:44:09 right - I understand Jan 23 16:44:20 And it can list directories in EXT2 and JFFS2. Jan 23 16:44:38 FAT would be nice, but I've been lazy about it. Jan 23 16:44:43 yaffs write is useful because raw to NAND is unreliable Jan 23 16:44:52 Don't I know it. Jan 23 16:45:54 I'll try and find the time to take a proper look at this. I should seriously consider it, but finding the time to support strongarm/pxa will be difficult Jan 23 16:46:12 Feel free to send HW :-) Jan 23 16:46:13 I should be able to steal most of the code from other bootloaders :-) Jan 23 16:46:42 Indeed. The task isn't really difficult. I wrote APEX because maintenance' is a bear with all of the boot loaders I've worked with. Jan 23 16:46:47 we have balloons2 (SA1110), but balloon3 will be a while yet Jan 23 16:47:26 or at least a while before we have one spare enough to send anywhere :-) Jan 23 16:48:21 now - must get back to the task I was sent in March last year :-( Jan 23 16:50:28 AchiestDragon: anything new on the hardware ? Jan 23 16:54:30 1 min Jan 23 17:04:33 ? Jan 23 17:07:45 AchiestDragon? Jan 23 17:10:02 trying to sort out a way to configure the fpga via the pc104 bus Jan 23 17:10:46 think i found one ,, just working out best way to impliment it Jan 23 17:14:23 and looks like it will work in the following way Jan 23 17:16:04 http://www.dspfpga.com/?page=eus_100lx Jan 23 17:16:53 as the fpga will be using the memrd , memwr and only use 16 bit access so , this will allow for the 8 bit accessed to be used diferently Jan 23 17:17:54 i am working on a simple 8 bit port that will allow us to bit bang the onboard fpga for config Jan 23 17:19:18 but the design is looking good Jan 23 17:19:34 AchiestDragon: did you have a look on the link ? Jan 23 17:19:39 yes Jan 23 17:20:48 what u think about it Jan 23 17:20:49 ? Jan 23 17:21:44 2 bga packages for a start Jan 23 17:22:06 key2: looks expensive for what we're looking to do. Jan 23 17:22:46 yes and will still need the level translators and jtag adaptors Jan 23 17:23:50 well I told u the best is a simple ARM7 + FPGA + FT2232 Jan 23 17:24:01 you can bitbang at a very high rate Jan 23 17:24:14 and you can program whatever you want in the ARM7 Jan 23 17:24:48 yes but the ts7200 plus this bord gives us that and more Jan 23 17:25:14 like ethernet Jan 23 17:27:46 ah ts7200 - is that a board from embeddedarm.com? Jan 23 17:28:06 (they are just sending us a ts7205 (because it's not playing nice with YAFFS2) Jan 23 17:28:10 ) Jan 23 17:31:24 yes Jan 23 17:32:35 although they do a ts7250 and another new low power one that would all do the job , the ts7200 has the compact flash card on it that may be usefull for all the software needed Jan 23 17:32:59 but a usb memory stick could also provide that Jan 23 17:33:09 or usb hdd Jan 23 17:34:21 as far as pc104 boards go there the best value ones i have come accross , all the others i have seen are at least dubble the cost of that Jan 23 17:55:24 vmaster: ping? Jan 23 18:19:08 <[g2]> key2 any idea what eus_100lx costs ? **** BEGIN LOGGING AT Mon Jan 23 18:53:52 2006 Jan 23 19:37:01 <[g2]> hey beewoolie lennert ping Jan 23 20:25:44 [g2]: hey. I was at the store. Jan 23 20:26:32 <[g2]> cool... food store or hw store ? Jan 23 20:28:10 shopping for dinner Jan 23 22:46:03 ka6sox: hey Jan 23 22:47:09 yo Jan 23 22:47:52 ka6sox: I had a little success with JTAG programming. Jan 23 22:48:11 I can write to the flash on one of my board at about 1.45 seconds/K. Jan 23 22:48:26 Which translates into 256K in 6.2minutes. Jan 23 22:48:40 It's somewhat faster than the openwince jtag code Jan 23 22:48:44 thats a lot faster than the 40 minutes thru teh wiggler. Jan 23 22:48:51 s/teh/the Jan 23 22:49:03 And that's unoptimized flash writing code. Jan 23 22:49:10 what hardware? Jan 23 22:49:23 Xilinx III and an ARM9 board. Jan 23 22:49:23 JTAG Jan 23 22:49:28 Yeah Jan 23 22:49:32 ozky Jan 23 22:49:55 well...that means that most of the code is unoptimized. Jan 23 22:49:58 It's the first useful result I've gotten, so I thought I'd share. Jan 23 22:50:03 Certainly. Jan 23 22:50:10 that is a good benchmark. Jan 23 22:50:22 how long is the bsdl file? Jan 23 22:50:26 I am using the ARM code debug facilities which are faster than a rote boundaryt scan. Jan 23 22:50:28 (how many bits) Jan 23 22:50:56 ah Jan 23 22:51:16 does it have an i-cache like the Xscale? Jan 23 22:51:21 The boundary scan is over 593 bits., Jan 23 22:51:31 No, I cannot write to the Icache as far as I can tel. Jan 23 22:51:40 k Jan 23 22:51:49 The Xscale has a really slick way to handle that. Jan 23 22:51:58 However, I won't be able to use it with this JTAG dongle. Jan 23 22:52:06 k Jan 23 22:52:13 Actually, I take that back. Jan 23 22:52:30 I may be able to use it, but not in the load-before-CPU-exec mode. Jan 23 22:52:39 ah Jan 23 22:52:47 With code in the cache, programming has to be way faster. Jan 23 22:53:06 should be. Jan 23 22:53:09 That will be closer to 32 TCK clocks per 32 bit write. Jan 23 22:53:20 I Jan 23 22:53:26 I'm working on arm7 at the moment. Jan 23 22:53:37 It's proving to be harder than I expected. Jan 23 22:53:42 same technique? Jan 23 22:53:57 Yeah. There's somthing not working with the debug scan chain. Jan 23 22:54:14 It's probably the same hitch I encountered before: incorrect documentation. Jan 23 22:54:26 That is, I'm reading the wrong file or I misunderstand what I'm reading. Jan 23 22:56:46 ka6sox: Are you planning to manufacture the PC104 board that will host the FPGA? Jan 23 22:56:55 Or, find something off-the-shelf? Jan 23 22:57:58 manuf Jan 23 22:58:34 K. There was some chatter about this earlier. AchiestDragon ( think) was shopping a board to handle the FPGA. Jan 23 22:58:48 Seemed like an expensive solution for what should be very simple. Jan 23 22:58:55 I haven't found anything that has what we need except for a board that is in development Jan 23 22:59:18 (has ARM9, 64MB ram,10/100,S3 Jan 23 23:03:05 but I don't even know if I can get ahold of that. Jan 23 23:03:15 its a 200mhz ATMEL part. Jan 23 23:04:00 but its not real yet. Jan 23 23:35:23 Isn't the ts7200 going to work? Jan 23 23:35:35 ka6sox: Sorry, I've been debugging. Jan 23 23:38:15 yes it is Jan 23 23:38:16 :) Jan 23 23:38:36 I think that the TS7200 will be an excellent platform. Jan 23 23:39:02 Is you plan to have two boards as well as the ep1220 interface board? Jan 23 23:39:18 yes Jan 23 23:39:38 we might be limited in speed by the EP board only because of cable lengths. Jan 23 23:40:02 So, what are you thinking of doing? Jan 23 23:40:14 I'm going to talk to ep1220 about the situation. Jan 23 23:40:35 what is your opinion on the FT2232 solution? faster or failure? Jan 23 23:44:46 I don't yet know. I've been working on this code for handling the scans so that I have a way to measure performance. Jan 23 23:44:59 The next step is to build the board and see how it compares. Jan 23 23:45:21 k Jan 23 23:45:23 vmaster has made the 2232 solution out to be a failure, as far as I can tell. Jan 23 23:45:40 I'm the sort of person who needs to see it before I'll believe it. Jan 23 23:45:53 you are certianly getting better performance out of the Parallel port solution. Jan 23 23:46:03 Xilinx III Jan 23 23:46:10 than openwince? Jan 23 23:47:49 what interface did you use for your tests? Jan 23 23:48:19 I thought it was the Xilinx III part. Jan 23 23:48:23 Yeah. Jan 23 23:48:34 It's the only one that is convenient at the moment. Jan 23 23:48:43 k Jan 23 23:48:58 that is a good benchmark as a lot of people have that one. Jan 23 23:49:00 So, I suppose I'm going better with the Xilinx than openwince does. Jan 23 23:49:15 But really, that code isn't particularly clever. It *is* very general. Jan 23 23:50:19 did you optimize your code for the ARM9 target? Jan 23 23:50:55 That's the only one that works right now. Jan 23 23:51:08 It isn't exactly optimized for the target, tho. Jan 23 23:51:16 k Jan 23 23:51:23 I am using a special, short, scan chain to push instructions into the CPU. Jan 23 23:51:29 It's only 67 bits long. Jan 23 23:51:36 that should help alone Jan 23 23:51:47 The full scan chain is really long, almost 600 bits. Jan 23 23:51:58 So, I'm doing that, and I'm using buffered writes. Jan 23 23:52:10 The one thing I want to try is removing the status checks. Jan 23 23:52:20 Right now, I check the status of the flash after every write. Jan 23 23:52:32 I *can* assume that the writes complete in the time specified by the CFI data. Jan 23 23:52:48 And I believe that these times are far shorter than the time it takes to read the status. Jan 23 23:53:05 So, right now the code is perfectly correct. Jan 23 23:53:22 Some clever changes and it might be made faster. Jan 23 23:53:48 maybe just do a block checksum. Jan 23 23:54:07 Of course, a verify is needed. Jan 23 23:56:32 sounds like there are optimizations still to come. this is going to help even when we have hardware assist. Jan 24 00:06:49 Definitely. Jan 24 00:07:55 the plan hasn't changed and things are still on track. Jan 24 00:09:00 to be fair, doing better than openwince is like shooting fish in a barrel. Jan 24 00:09:25 I kinda feel bad for the author(s) of that tool. Jan 24 00:12:26 it probably works fine for smaller devices but when you try to do something like program up a 16MB flash it falls down. Jan 24 00:45:00 NN Jan 24 00:45:12 night night? Jan 24 00:45:27 :-) Jan 24 02:37:10 pong [g2] **** ENDING LOGGING AT Tue Jan 24 03:00:00 2006