| 02:23.00 | *** join/#openjtag rd_ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) |
| 05:17.18 | *** join/#openjtag pleemans (n=peter@leemanpe.ugent.be) |
| 06:37.36 | *** join/#openjtag aproemel (n=aproemel@p508A1349.dip0.t-ipconnect.de) |
| 09:01.16 | *** join/#openjtag likewise (n=chatzill@atwork-186.r-212.178.104.atwork.nl) |
| 09:01.31 | likewise | hello all |
| 09:02.10 | likewise | Must the working_area be a data cache, instruction cache or might it be initialized (SD)RAM? |
| 09:02.31 | likewise | that's for an xscale ixp4xx target |
| 09:40.11 | *** join/#openjtag rd_ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) |
| 09:42.21 | *** join/#openjtag rd__ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) |
| 12:19.37 | *** join/#openjtag rd_ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) |
| 13:12.42 | *** join/#openjtag prpplague (n=DaveAnde@mail.americanmicrosystems.com) |
| 13:36.39 | likewise | prpplague: hi there |
| 13:38.26 | prpplague | likewise: greetings earthling |
| 13:49.23 | likewise | prpplague: long time no see here (due to me) |
| 13:49.29 | prpplague | yep |
| 13:49.34 | likewise | prpplague: you played with openocd and ixp4xx? |
| 13:50.17 | prpplague | likewise: sorry no, i prefer to avoid marvell when i can |
| 13:50.30 | likewise | prpplague: Intel still, AFAIK |
| 13:51.12 | prpplague | likewise: ahh yea i think ixp stayed with intel, either way i don't do much with xscale since their isn't any future for it |
| 13:51.57 | likewise | prpplague: I know. How do you see the future then? We are moving to Freescale 83xx parts btw. |
| 13:52.22 | prpplague | likewise: samsung is pretty much the leader right now |
| 13:52.41 | prpplague | imho |
| 13:52.44 | likewise | prpplague: also for industrial parts? |
| 13:52.49 | prpplague | yea |
| 13:53.11 | likewise | prpplague: hmm, I should see their product portfolio then. I need Gb Ethernet etc. |
| 16:10.48 | *** join/#openjtag cbrake (n=cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 16:11.53 | likewise | drath: ping, hope I'm not disturbing |
| 18:35.00 | *** join/#openjtag likewise (n=chatzill@82-171-189-134.dsl.ip.tiscali.nl) |
| 18:52.47 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 18:57.22 | drath | hey likewise |
| 18:57.31 | likewise | hey dominic |
| 18:57.49 | drath | you're the one from openocd-development with the ixp problems? |
| 18:58.07 | likewise | I was pleasantly surprised to see your xscale work be 99% right already, great work. Yes, I was struggling with the 1% :-) |
| 18:58.29 | likewise | Yes, my name is Leon, nice to meet you. |
| 18:58.40 | drath | Hey Leon |
| 18:58.47 | drath | there are two issues |
| 18:58.50 | drath | big-endian xscale in general |
| 18:58.53 | drath | and big-endian cfi |
| 18:59.00 | drath | this stuff is mostly ready |
| 18:59.02 | drath | but barely tested |
| 18:59.16 | drath | whenever someone appears with be hardware he disappears soon after |
| 18:59.43 | drath | carsten schlote started some work |
| 18:59.54 | drath | there's a separate branch with his work |
| 19:00.25 | likewise | well, flashing *almost* works correctly for me. Out of 16 MB, only 4 bits where wrong :-) |
| 19:01.04 | likewise | which branch is his? |
| 19:01.38 | drath | xscale-ixp-be |
| 19:02.00 | drath | the other xscale branch is old stuff, already merged into trunk |
| 19:03.42 | likewise | I will test my efforts against his branch tomorrow then. |
| 19:04.24 | drath | just started working on a new job, and still have to submit my master's thesis, which is why i'm a bit busy right now |
| 19:04.50 | likewise | what are you doing (job and study)? |
| 19:05.13 | drath | computer science, and now i started working for a small embedded/realtime company here |
| 19:06.34 | likewise | which company is that, if I may ask? |
| 19:06.49 | likewise | I finished EE/IT last year. |
| 19:07.18 | prpplague | drath: http://www.elinux.org/Hammer_Board |
| 19:07.18 | drath | IBV |
| 19:07.23 | drath | doing mostly QNX |
| 19:07.31 | likewise | I love QNX |
| 19:08.20 | drath | heh, yeah, writing device drivers never was so easy |
| 19:08.49 | likewise | Great microkernel approach. We almost chose QNX, but went for Linux due to more drivers etc and less royalty. I love the memory seperation of drivers. |
| 19:09.27 | likewise | There is now UIO in Linux, still have to try it. It will not make the kernel micro though... |
| 19:10.00 | drath | prpplague: yeah, really sweet |
| 19:10.14 | prpplague | drath: we are shipping the flyswatter with the hammerboard |
| 19:10.22 | prpplague | drath: need to do some openocd docs for it |
| 19:10.27 | prpplague | just been too busy |
| 19:11.29 | drath | heh, yeah, busy sounds soooo familiar :) |
| 19:12.16 | prpplague | hehe |
| 19:22.57 | likewise | drath: does carsten show up on IRC ? |
| 19:23.39 | drath | i've never seen him |
| 19:23.51 | drath | and he wasn't active on the list for quite a whle |
| 20:11.54 | likewise | in flash/cfi.c/cfi_intel_write_block(), if count = 1 and buswidth = 2, count / buswidth will be zero. |
| 20:19.36 | drath | likewise: iirc that case should be caught before the block write |
| 20:19.50 | drath | let me check the code |
| 20:20.23 | likewise | don't bother if you have anyhting better to do :-) |
| 20:21.10 | drath | a count of 1 with bus_width 2 should be treated as unaligned head byte |
| 20:21.46 | drath | in cfi_write() |
| 20:22.04 | drath | write_p gets aligned to the beginning of the first bus-width word we have to write |
| 20:23.36 | drath | and the alignment-gap is filled with data from target memory |
| 20:24.16 | drath | the intent is to re-write what was already in flash at that address |
| 20:24.43 | drath | then bytes from the new data (buffer) are added |
| 20:25.12 | drath | and in case the buffer is already finished, tail bytes are read from target memory, too |
| 20:25.20 | likewise | Ok, I'll see if that works at advertised, it might be the culprit of my problem. Something else: in u8 cfi_get_u8() data is not initiatilized to zero and is ORed afterwards, and then returned. |
| 20:26.59 | drath | how's your flash layout? |
| 20:27.13 | drath | i've never used anything but 16-bit bus/chip width |
| 20:27.24 | drath | quite possble that there's something wrong with other layouts |
| 20:27.30 | drath | s/but/bit/ |
| 20:29.44 | likewise | single chip, 16-bit bus/chip width |
| 20:30.22 | drath | ok, the cfi_get_u8 code seems wrong |
| 20:31.16 | drath | but it shouldn't be uninitialized |
| 20:31.52 | likewise | for the little endian case, the code does not initialize data. Am I right? |
| 20:32.30 | drath | the read_memory reads bus_width bytes into data |
| 20:33.00 | drath | the i++ seems wrong |
| 20:33.10 | drath | guess it should be i+=bank->chip_width |
| 20:33.20 | drath | i.e. take the first byte from every chip |
| 20:34.36 | likewise | ah yes, I see both your points now |
| 20:35.24 | likewise | data is indeed initialized, and I *think* I should increase with the chip width indeed. |
| 20:36.20 | drath | i always meant to review the cfi stuff, but it's rarely used, so that wasn't high priority |
| 20:38.58 | drath | the other query stuff seems severely broken, too |
| 20:39.14 | drath | in the big-endian case |
| 20:40.04 | drath | there's also a case the code doesn't address at all - x8/x16 devices in x8 mode |
| 20:40.51 | drath | something with the way cfi addresses have to be calculated - iirc it's x16 addressing (A0 don't care) even when the device is in x8 |
| 20:45.29 | likewise | Given that my second nibble (4 bits) always fall over, after programming I suspect this line: |
| 20:45.31 | likewise | int cfi_write(struct flash_bank_s *bank, u8 *buffer, u32 offset, u32 count) |
| 20:45.32 | likewise | /* return to read array mode */ |
| 20:45.34 | likewise | cfi_command(bank, 0xf0, current_word); |
| 20:45.57 | likewise | fall over = they become zero, if I let write() finish. If I perform CTRL-C during write_image(), the bits are OK. |
| 20:47.56 | likewise | According to my Intel docs, returning to "read array" mode, cfi_command(bank, 0xff, current_word); is needed, nothing else. |
| 20:49.02 | drath | yeah, that's the problem with AMD/Spansion vs. Intel vs. JEDEC vs. whoeverelse |
| 20:49.43 | likewise | drath: I can test this tomorrow. I'll remove the 0xf0 command. I suspect that command clears the second nibble. |
| 20:50.05 | likewise | For the rest, I have verified that flashing works on be ixp42x. |
| 20:50.35 | drath | do you have a "working_area" defined? |
| 20:51.07 | likewise | yes |
| 20:51.14 | likewise | In SDRAM even :-) |
| 20:51.18 | likewise | external |
| 20:51.35 | drath | are you on a LE or on a BE host? |
| 20:53.36 | likewise | LE host |
| 20:55.00 | drath | ok - BE host used to cause even more problem, but I suppose most of that should be clean by now |
| 20:55.03 | likewise | https://lists.berlios.de/pipermail/openocd-development/2007-September/000339.html |
| 20:55.11 | likewise | This is a summary of my test and config |
| 20:55.58 | drath | cool, thanks |
| 20:56.14 | likewise | After 1 sector, I tried with a 16 MB image, and even with single "mww" calls to manually emulate the FlashROM writes. In all cases, only one nibble becomes zero. |
| 20:56.46 | likewise | I'll report tomorrow if removing the "0xf0" write works for me. |
| 20:57.13 | likewise | Thanks for the excellent work on OpenOCD, and your time listening to my chatter :-) |
| 20:59.00 | drath | heh, guess that time is well invested if it makes you fix the bugs :) |
| 20:59.07 | drath | anyway, I'm off for today |
| 20:59.56 | likewise | good nite |
| 21:00.04 | drath | n8 |
| 22:15.20 | *** join/#openjtag drath_ (i=vmaster@p5B07F236.dip.t-dialin.net) |