**** BEGIN LOGGING AT Fri Aug 22 02:59:56 2008 Aug 22 05:54:00 timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0 Aug 22 05:54:05 anybody? Aug 22 06:11:11 drath_: hi Aug 22 09:37:14 hey sn9 Aug 22 09:59:42 drath: ideas? Aug 22 09:59:56 timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0 Aug 22 10:02:52 sn9: you're using a feroceon, iirc? Aug 22 10:03:13 yep Aug 22 10:03:34 svn r950 finally got it to halt Aug 22 10:04:31 apparently, the undef exception trumps both dbgrq and vector-catch Aug 22 10:04:45 so i forced a watchpoint Aug 22 10:05:45 i suspect that the lack of clearing the watchpoint anywhere may have something to do with this, or am i way off-base? Aug 22 10:06:36 what did you do when you got the message? Aug 22 10:06:44 read/write memory? Aug 22 10:06:48 halt/resume? Aug 22 10:07:03 any attempt to write to the flash locks up with the message above, as does verify_image Aug 22 10:07:18 ok, memory accesses Aug 22 10:07:30 dump_image is ok Aug 22 10:07:59 ok, could you run with -d3 and post the log in pastebin? Aug 22 10:13:16 drath: http://pastebin.com/f7140f060 Aug 22 10:17:41 looks like it fails as soon as you're writing to the working area (0x00400000) Aug 22 10:18:00 i tried commenting that out Aug 22 10:18:13 in the .cfg Aug 22 10:18:49 the board has 32M ram Aug 22 10:20:03 are you sure there is ram at that address? Aug 22 10:21:18 i was guessing that the 32M began at 0x0 Aug 22 10:21:59 which processor exactly do you use? Aug 22 10:22:53 the board is RD-88F5181L-VOIP-GE, so i would guess 88f5181l Aug 22 10:23:28 i really don't want to pry the heatsink off to make sure Aug 22 10:28:23 ok, couldn't find any docs on the 88f5181, but the 88f5182 has ddr-sdram at 0x0..., 0x1..., 0x2..., and 0x3... Aug 22 10:28:30 but did you enable that sdram? Aug 22 10:28:45 you mean, with a write? Aug 22 10:28:54 well, program the sdram controller? Aug 22 10:29:15 no idea where to write to to do that, nor the value Aug 22 10:29:28 well, you can't use SDRAM without programming the controller Aug 22 10:29:38 figures Aug 22 10:29:40 what happens if you remove the "working_area" Aug 22 10:29:52 same thing, pretty much Aug 22 10:30:07 can you post a log? Aug 22 10:30:10 -d3 again Aug 22 10:30:14 one moment Aug 22 10:32:37 oh, wait, this was different: http://pastebin.com/f261f8f67 Aug 22 10:33:48 ok, looks like there's a bug in the code: Aug 22 10:33:50 Error: 268 47555 target.c:952 target_read_buffer(): address+size wrapped(0xff800000, 0x00800000) Aug 22 10:36:08 the flash probe emits an odd msg, too Aug 22 10:36:31 in src/target/target.c, target_read_buffer and target_write_buffer: Aug 22 10:36:38 - if (address+size + if ((address + size - 1) < address) Aug 22 10:36:44 Warning:configuration specifies 0x800000 size, but a 0x800000 size flash was found Aug 22 10:37:33 how about: if (address+size<=address) Aug 22 10:37:59 drath: ? Aug 22 10:39:01 should do the same Aug 22 10:39:15 cleaner, though Aug 22 10:39:19 no Aug 22 10:39:32 not to me, at least Aug 22 10:40:13 0xff800000 + 0x800000 - 1 = 0xffffffff, which is the last address written Aug 22 10:40:50 which is what the check is for - you want to no if the last address written is smaller than the first address written Aug 22 10:40:56 s/no/know/ Aug 22 10:40:56 drath meant: which is what the check is for - you want to know if the last address written is smaller than the first address written Aug 22 10:41:25 are address and/or size declared as signed or unsigned? Aug 22 10:42:03 if they are both declared as unsigned, then you're right Aug 22 10:42:27 they are Aug 22 10:42:32 ok Aug 22 10:43:27 the warning about flash size is another bug Aug 22 10:43:40 Fri 22 Aug 2008 03:43:39 AM PDT Aug 22 10:44:20 this is why i hadn't thought of the wrap issue ^^^ Aug 22 10:44:50 heh, ok Aug 22 10:45:57 so, basically, i've simply run into target-independent bugs? Aug 22 10:46:21 after you figured that you can't use a working area, yeah ;) Aug 22 10:46:48 did you try with the fix to target_read/write_buffer? Aug 22 10:47:04 and here i was worried that my non-cleared watchpoint was wreaking havoc on working code... Aug 22 10:53:05 you could still have a bug in your config file Aug 22 10:53:13 drath: trying now. is verify_image going to take the same amount of time as dump_image? Aug 22 10:53:25 what does your "flash bank" look like? Aug 22 10:53:41 in the .cfg? Aug 22 10:53:49 sn9: without a working area the whole image has to be read from memory, so it's going to take pretty long Aug 22 10:53:57 sn9: flashing is going to take even longer (several hours) Aug 22 10:54:04 yeah, in the .cfg Aug 22 10:54:21 any hope of being able to activate sdram instead? Aug 22 10:54:48 flash bank cfi 0xff800000 0x800000 1 2 0 jedec_probe Aug 22 10:55:32 how many flash chips does your board have? Aug 22 10:56:34 the dump_image had taken this long: dumped 8388608 byte in 6836.459473s Aug 22 10:56:51 it has one Aug 22 10:57:25 then change the '2' in your flash bank line into a '1' Aug 22 10:57:34 and the warning about the flash size should disappear Aug 22 10:57:35 that makes the probe fail Aug 22 10:57:55 ok, hold on... Aug 22 10:59:28 ok, change the '1' into a '2' :) Aug 22 10:59:50 assuming your flash is 16 bits wide, and you have one Aug 22 11:01:19 2 2 0 also makes the probe fail Aug 22 11:02:13 what type of flash do you haveß Aug 22 11:02:14 chip is a samsung k8d6316ubm Aug 22 11:10:36 ok, the chip could be in a x8 or in a x16 configuration - so either 1 1 or 2 2 must be correct - if that doesn't work, you could have hit another bug Aug 22 11:11:29 then, i have, because neither did Aug 22 11:12:19 ok, assuming it's in a x16 configuration (no sense connecting the flash only x8), post the log from a "2 2" config Aug 22 11:14:03 i will have to interrupt the verify_image Aug 22 11:17:15 drath: doesn't fail anymore -- must have been the target_read/write_buffer Aug 22 11:18:15 and flash info 0 makes sense now, too Aug 22 11:20:31 drath: now, any idea how to activate sdram? Aug 22 11:25:50 sn9: find the documentation for your particular feroceon, study its SDRAM controller, study your SDRAM's datasheet, write the initialization sequence Aug 22 11:26:32 usually that means setting up clocks, programming pin multiplexing, programming the sdram timings, then some access to the sdram that program the chips internal registers, followed by a refresh sequence Aug 22 11:26:51 do you have any source code for the borad? like u-boot? Aug 22 11:27:04 u-boot, yes Aug 22 11:27:40 should be easier to deal with than datasheets Aug 22 11:28:02 but, i'm wondering how to do the init fom within openocd Aug 22 11:29:28 *from Aug 22 11:29:32 memory writes to the appropriate locations Aug 22 11:29:40 you can put them in a file, and have them execute as an init script Aug 22 11:30:10 but if you have a working u-boot binary, it might be easier to flash just that Aug 22 11:30:25 that was my intention Aug 22 11:30:48 but i am hoping to use the working_area to do that Aug 22 11:31:32 well, you're probably looking at quite some work (hours) to figure out the init sequence, in that time you could flash the image as well Aug 22 11:32:33 i want to verify_image before flashing, to make sure i have something to roll back to Aug 22 11:39:45 drath: in the meantime, might as well commit the target_read/write_buffer fix Aug 22 18:05:25 drath: ping Aug 22 18:05:52 sn9: pong Aug 22 18:06:12 "flash fillw" doesn't seem to do anything Aug 22 18:06:20 just returns Aug 22 18:07:32 btw, line 908 of src/flash/flash.c has the same mistake you fixed in r957 Aug 22 18:11:11 sn9: are you sure? at first glance that line seems ok Aug 22 18:11:15 nope Aug 22 18:11:33 - if ((addr >= c->base) && (addr < c->base + c->size) && target == c->target) Aug 22 18:11:34 + if ((addr >= c->base) && (addr - 1 < c->base + c->size - 1) && target == c->target) Aug 22 18:12:04 ah, ok, i see what you mean Aug 22 18:13:39 doesn't fix "flash fillw" though -- something else is going on there Aug 22 18:15:37 "flash fillw" always felt like a pretty useless command to me - probably didn't get a lot of testing Aug 22 18:16:52 it's not useless to me atm -- i need to zero almost 2 megs Aug 22 18:17:23 zero? Aug 22 18:17:28 yep Aug 22 18:17:59 well, dd if=/dev/zero of=zero_2m bs=1024 count=2048 would get you a 2MB zero binary Aug 22 18:18:13 takes forever to flash that, though Aug 22 18:18:32 why do you think "flash fillw" could be faster? Aug 22 18:19:00 no transfer of the data -- just tell the cpu to do it, right? Aug 22 18:19:45 sn9: did you manage to get working_area 'working'? Aug 22 18:20:09 no, i duplicated the writes in the u-boot source exactly, no diff Aug 22 18:20:42 well, setting up sdram is pretty complex, and easy to get wrong Aug 22 18:20:53 fillw doesn't anything different than a normal flash write Aug 22 18:21:05 it builds a buffer using the desired pattern, and writes that to flash Aug 22 18:24:39 i'll try just leaving that part FF Aug 22 18:35:32 now flashing u-boot on (finally) **** ENDING LOGGING AT Sat Aug 23 02:59:57 2008