**** BEGIN LOGGING AT Thu Sep 13 02:59:57 2007
Sep 13 09:02:23 <likewise> hello all
Sep 13 09:03:03 <likewise> Must the working_area be a data cache, instruction cache or might it be initialized (SD)RAM?
Sep 13 09:03:23 <likewise> that's for an xscale ixp4xx target
Sep 13 13:37:34 <likewise> prpplague: hi there
Sep 13 13:39:20 <prpplague> likewise: greetings earthling
Sep 13 13:50:17 <likewise> prpplague: long time no see here (due to me)
Sep 13 13:50:24 <prpplague> yep
Sep 13 13:50:29 <likewise> prpplague: you played with openocd and ixp4xx?
Sep 13 13:51:12 <prpplague> likewise: sorry no, i prefer to avoid marvell when i can
Sep 13 13:51:24 <likewise> prpplague: Intel still, AFAIK
Sep 13 13:52:06 <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
Sep 13 13:52:52 <likewise> prpplague: I know. How do you see the future then? We are moving to Freescale 83xx parts btw.
Sep 13 13:53:17 <prpplague> likewise: samsung is pretty much the leader right now
Sep 13 13:53:36 <prpplague> imho
Sep 13 13:53:39 <likewise> prpplague: also for industrial parts?
Sep 13 13:53:44 <prpplague> yea
Sep 13 13:54:06 <likewise> prpplague: hmm, I should see their product portfolio then. I need Gb Ethernet etc.
Sep 13 16:12:49 <likewise> drath: ping, hope I'm not disturbing
Sep 13 18:58:19 <drath> hey likewise 
Sep 13 18:58:28 <likewise> hey dominic
Sep 13 18:58:47 <drath> you're the one from openocd-development with the ixp problems?
Sep 13 18:59:04 <likewise> I was pleasantly surprised to see your xscale work be 99% right already, great work. Yes, I was struggling with the 1% :-)
Sep 13 18:59:26 <likewise> Yes, my name is Leon, nice to meet you.
Sep 13 18:59:37 <drath> Hey Leon
Sep 13 18:59:44 <drath> there are two issues
Sep 13 18:59:47 <drath> big-endian xscale in general
Sep 13 18:59:50 <drath> and big-endian cfi
Sep 13 18:59:57 <drath> this stuff is mostly ready
Sep 13 18:59:59 <drath> but barely tested
Sep 13 19:00:14 <drath> whenever someone appears with be hardware he disappears soon after
Sep 13 19:00:41 <drath> carsten schlote started some work
Sep 13 19:00:51 <drath> there's a separate branch with his work
Sep 13 19:01:22 <likewise> well, flashing *almost* works correctly for me. Out of 16 MB, only 4 bits where wrong :-)
Sep 13 19:02:02 <likewise> which branch is his?
Sep 13 19:02:36 <drath> xscale-ixp-be
Sep 13 19:02:58 <drath> the other xscale branch is old stuff, already merged into trunk
Sep 13 19:04:39 <likewise> I will test my efforts against his branch tomorrow then.
Sep 13 19:05:21 <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
Sep 13 19:05:47 <likewise> what are you doing (job and study)?
Sep 13 19:06:11 <drath> computer science, and now i started working for a small embedded/realtime company here
Sep 13 19:07:31 <likewise> which company is that, if I may ask?
Sep 13 19:07:46 <likewise> I finished EE/IT last year.
Sep 13 19:08:16 <prpplague> drath: http://www.elinux.org/Hammer_Board
Sep 13 19:08:16 <drath> IBV
Sep 13 19:08:20 <drath> doing mostly QNX
Sep 13 19:08:28 <likewise> I love QNX
Sep 13 19:09:17 <drath> heh, yeah, writing device drivers never was so easy
Sep 13 19:09:46 <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.
Sep 13 19:10:25 <likewise> There is now UIO in Linux, still have to try it. It will not make the kernel micro though...
Sep 13 19:10:58 <drath> prpplague: yeah, really sweet
Sep 13 19:11:11 <prpplague> drath: we are shipping the flyswatter with the hammerboard
Sep 13 19:11:19 <prpplague> drath: need to do some openocd docs for it
Sep 13 19:11:24 <prpplague> just been too busy
Sep 13 19:12:27 <drath> heh, yeah, busy sounds soooo familiar :)
Sep 13 19:13:14 <prpplague> hehe
Sep 13 19:23:55 <likewise> drath: does carsten show up on IRC ?
Sep 13 19:24:37 <drath> i've never seen him
Sep 13 19:24:48 <drath> and he wasn't active on the list for quite a whle
Sep 13 20:12:52 <likewise> in flash/cfi.c/cfi_intel_write_block(), if count = 1 and buswidth = 2, count / buswidth will be zero.
Sep 13 20:20:34 <drath> likewise: iirc that case should be caught before the block write
Sep 13 20:20:48 <drath> let me check the code
Sep 13 20:21:21 <likewise> don't bother if you have anyhting better to do :-)
Sep 13 20:22:08 <drath> a count of 1 with bus_width 2 should be treated as unaligned head byte
Sep 13 20:22:44 <drath> in cfi_write()
Sep 13 20:23:02 <drath> write_p gets aligned to the beginning of the first bus-width word we have to write
Sep 13 20:24:34 <drath> and the alignment-gap is filled with data from target memory
Sep 13 20:25:14 <drath> the intent is to re-write what was already in flash at that address
Sep 13 20:25:41 <drath> then bytes from the new data (buffer) are added
Sep 13 20:26:10 <drath> and in case the buffer is already finished, tail bytes are read from target memory, too
Sep 13 20:26:18 <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.
Sep 13 20:27:57 <drath> how's your flash layout?
Sep 13 20:28:11 <drath> i've never used anything but 16-bit bus/chip width
Sep 13 20:28:22 <drath> quite possble that there's something wrong with other layouts
Sep 13 20:28:28 <drath> s/but/bit/
Sep 13 20:30:42 <likewise> single chip, 16-bit bus/chip width
Sep 13 20:31:20 <drath> ok, the cfi_get_u8 code seems wrong
Sep 13 20:32:14 <drath> but it shouldn't be uninitialized
Sep 13 20:32:50 <likewise> for the little endian case, the code does not initialize data. Am I right?
Sep 13 20:33:28 <drath> the read_memory reads bus_width bytes into data
Sep 13 20:33:58 <drath> the i++ seems wrong
Sep 13 20:34:08 <drath> guess it should be i+=bank->chip_width
Sep 13 20:34:18 <drath> i.e. take the first byte from every chip
Sep 13 20:35:34 <likewise> ah yes, I see both your points now
Sep 13 20:36:22 <likewise> data is indeed initialized, and I *think* I should increase with the chip width indeed.
Sep 13 20:37:18 <drath> i always meant to review the cfi stuff, but it's rarely used, so that wasn't high priority
Sep 13 20:39:56 <drath> the other query stuff seems severely broken, too
Sep 13 20:40:12 <drath> in the big-endian case
Sep 13 20:41:02 <drath> there's also a case the code doesn't address at all - x8/x16 devices in x8 mode
Sep 13 20:41:50 <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
Sep 13 20:46:27 <likewise> Given that my second nibble (4 bits) always fall over, after programming I suspect this line:
Sep 13 20:46:29 <likewise> int cfi_write(struct flash_bank_s *bank, u8 *buffer, u32 offset, u32 count)
Sep 13 20:46:30 <likewise> /* return to read array mode */
Sep 13 20:46:32 <likewise> cfi_command(bank, 0xf0, current_word);
Sep 13 20:46:55 <likewise> fall over = they become zero, if I let write() finish. If I perform CTRL-C during write_image(), the bits are OK.
Sep 13 20:48:54 <likewise> According to my Intel docs, returning to "read array" mode, cfi_command(bank, 0xff, current_word); is needed, nothing else.
Sep 13 20:49:59 <drath> yeah, that's the problem with AMD/Spansion vs. Intel vs. JEDEC vs. whoeverelse
Sep 13 20:50:41 <likewise> drath: I can test this tomorrow. I'll remove the 0xf0 command. I suspect that command clears the second nibble.
Sep 13 20:51:03 <likewise> For the rest, I have verified that flashing works on be ixp42x.
Sep 13 20:51:33 <drath> do you have a "working_area" defined?
Sep 13 20:52:05 <likewise> yes
Sep 13 20:52:12 <likewise> In SDRAM even :-)
Sep 13 20:52:16 <likewise> external
Sep 13 20:52:33 <drath> are you on a LE or on a BE host?
Sep 13 20:54:34 <likewise> LE host
Sep 13 20:55:58 <drath> ok - BE host used to cause even more problem, but I suppose most of that should be clean by now
Sep 13 20:56:02 <likewise> https://lists.berlios.de/pipermail/openocd-development/2007-September/000339.html
Sep 13 20:56:09 <likewise> This is a summary of my test and config
Sep 13 20:56:56 <drath> cool, thanks
Sep 13 20:57:12 <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.
Sep 13 20:57:44 <likewise> I'll report tomorrow if removing the "0xf0" write works for me.
Sep 13 20:58:11 <likewise> Thanks for the excellent work on OpenOCD, and your time listening to my chatter :-)
Sep 13 20:59:58 <drath> heh, guess that time is well invested if it makes you fix the bugs :)
Sep 13 21:00:05 <drath> anyway, I'm off for today
Sep 13 21:00:54 <likewise> good nite
Sep 13 21:01:02 <drath> n8
**** ENDING LOGGING AT Fri Sep 14 02:59:56 2007