| 05:43.02 | *** join/#openjtag pleemans (n=peter@dD577D009.access.telenet.be) |
| 05:54.00 | sn9 | timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0 |
| 05:54.05 | sn9 | anybody? |
| 06:05.31 | *** join/#openjtag drath_ (i=vmaster@p5B07C8D5.dip.t-dialin.net) |
| 06:11.11 | sn9 | drath_: hi |
| 09:37.14 | drath_ | hey sn9 |
| 09:59.42 | sn9 | drath: ideas? |
| 09:59.56 | sn9 | timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0 |
| 10:02.52 | drath | sn9: you're using a feroceon, iirc? |
| 10:03.13 | sn9 | yep |
| 10:03.34 | sn9 | svn r950 finally got it to halt |
| 10:04.31 | sn9 | apparently, the undef exception trumps both dbgrq and vector-catch |
| 10:04.45 | sn9 | so i forced a watchpoint |
| 10:05.44 | sn9 | i suspect that the lack of clearing the watchpoint anywhere may have something to do with this, or am i way off-base? |
| 10:06.36 | drath | what did you do when you got the message? |
| 10:06.44 | drath | read/write memory? |
| 10:06.48 | drath | halt/resume? |
| 10:07.02 | sn9 | any attempt to write to the flash locks up with the message above, as does verify_image |
| 10:07.17 | drath | ok, memory accesses |
| 10:07.29 | sn9 | dump_image is ok |
| 10:07.58 | drath | ok, could you run with -d3 and post the log in pastebin? |
| 10:13.16 | sn9 | drath: http://pastebin.com/f7140f060 |
| 10:17.40 | drath | looks like it fails as soon as you're writing to the working area (0x00400000) |
| 10:18.00 | sn9 | i tried commenting that out |
| 10:18.13 | sn9 | in the .cfg |
| 10:18.49 | sn9 | the board has 32M ram |
| 10:20.03 | drath | are you sure there is ram at that address? |
| 10:21.18 | sn9 | i was guessing that the 32M began at 0x0 |
| 10:21.59 | drath | which processor exactly do you use? |
| 10:22.53 | sn9 | the board is RD-88F5181L-VOIP-GE, so i would guess 88f5181l |
| 10:23.28 | sn9 | i really don't want to pry the heatsink off to make sure |
| 10:28.23 | drath | ok, couldn't find any docs on the 88f5181, but the 88f5182 has ddr-sdram at 0x0..., 0x1..., 0x2..., and 0x3... |
| 10:28.30 | drath | but did you enable that sdram? |
| 10:28.44 | sn9 | you mean, with a write? |
| 10:28.54 | drath | well, program the sdram controller? |
| 10:29.15 | sn9 | no idea where to write to to do that, nor the value |
| 10:29.28 | drath | well, you can't use SDRAM without programming the controller |
| 10:29.38 | sn9 | figures |
| 10:29.40 | drath | what happens if you remove the "working_area" |
| 10:29.51 | sn9 | same thing, pretty much |
| 10:30.07 | drath | can you post a log? |
| 10:30.10 | drath | -d3 again |
| 10:30.13 | sn9 | one moment |
| 10:32.36 | sn9 | oh, wait, this was different: http://pastebin.com/f261f8f67 |
| 10:33.48 | drath | ok, looks like there's a bug in the code: |
| 10:33.49 | drath | Error: 268 47555 target.c:952 target_read_buffer(): address+size wrapped(0xff800000, 0x00800000) |
| 10:36.08 | sn9 | the flash probe emits an odd msg, too |
| 10:36.30 | drath | in src/target/target.c, target_read_buffer and target_write_buffer: |
| 10:36.38 | drath | - if (address+size<address) |
| 10:36.38 | drath | + if ((address + size - 1) < address) |
| 10:36.44 | sn9 | Warning:configuration specifies 0x800000 size, but a 0x800000 size flash was found |
| 10:37.32 | sn9 | how about: if (address+size<=address) |
| 10:37.58 | sn9 | drath: ? |
| 10:39.01 | drath | should do the same |
| 10:39.14 | sn9 | cleaner, though |
| 10:39.19 | drath | no |
| 10:39.32 | drath | not to me, at least |
| 10:40.13 | drath | 0xff800000 + 0x800000 - 1 = 0xffffffff, which is the last address written |
| 10:40.50 | drath | which is what the check is for - you want to no if the last address written is smaller than the first address written |
| 10:40.56 | drath | s/no/know/ |
| 10:41.24 | sn9 | are address and/or size declared as signed or unsigned? |
| 10:42.02 | sn9 | if they are both declared as unsigned, then you're right |
| 10:42.27 | drath | they are |
| 10:42.32 | sn9 | ok |
| 10:43.27 | drath | the warning about flash size is another bug |
| 10:43.40 | sn9 | Fri 22 Aug 2008 03:43:39 AM PDT |
| 10:44.20 | sn9 | this is why i hadn't thought of the wrap issue ^^^ |
| 10:44.50 | drath | heh, ok |
| 10:45.57 | sn9 | so, basically, i've simply run into target-independent bugs? |
| 10:46.21 | drath | after you figured that you can't use a working area, yeah ;) |
| 10:46.47 | drath | did you try with the fix to target_read/write_buffer? |
| 10:47.04 | sn9 | and here i was worried that my non-cleared watchpoint was wreaking havoc on working code... |
| 10:53.04 | drath | you could still have a bug in your config file |
| 10:53.13 | sn9 | drath: trying now. is verify_image going to take the same amount of time as dump_image? |
| 10:53.25 | drath | what does your "flash bank" look like? |
| 10:53.41 | sn9 | in the .cfg? |
| 10:53.49 | drath | sn9: without a working area the whole image has to be read from memory, so it's going to take pretty long |
| 10:53.57 | drath | sn9: flashing is going to take even longer (several hours) |
| 10:54.04 | drath | yeah, in the .cfg |
| 10:54.21 | sn9 | any hope of being able to activate sdram instead? |
| 10:54.47 | sn9 | flash bank cfi 0xff800000 0x800000 1 2 0 jedec_probe |
| 10:55.32 | drath | how many flash chips does your board have? |
| 10:56.34 | sn9 | the dump_image had taken this long: dumped 8388608 byte in 6836.459473s |
| 10:56.51 | sn9 | it has one |
| 10:57.24 | drath | then change the '2' in your flash bank line into a '1' |
| 10:57.34 | drath | and the warning about the flash size should disappear |
| 10:57.35 | sn9 | that makes the probe fail |
| 10:57.55 | drath | ok, hold on... |
| 10:59.28 | drath | ok, change the '1' into a '2' :) |
| 10:59.50 | drath | assuming your flash is 16 bits wide, and you have one |
| 11:01.18 | sn9 | 2 2 0 also makes the probe fail |
| 11:02.12 | drath | what type of flash do you haveà |
| 11:02.14 | sn9 | chip is a samsung k8d6316ubm |
| 11:10.36 | drath | 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 |
| 11:11.28 | sn9 | then, i have, because neither did |
| 11:12.18 | drath | ok, assuming it's in a x16 configuration (no sense connecting the flash only x8), post the log from a "2 2" config |
| 11:14.02 | sn9 | i will have to interrupt the verify_image |
| 11:17.15 | sn9 | drath: doesn't fail anymore -- must have been the target_read/write_buffer |
| 11:18.15 | sn9 | and flash info 0 makes sense now, too |
| 11:20.31 | sn9 | drath: now, any idea how to activate sdram? |
| 11:25.50 | drath | sn9: find the documentation for your particular feroceon, study its SDRAM controller, study your SDRAM's datasheet, write the initialization sequence |
| 11:26.31 | drath | 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 |
| 11:26.51 | drath | do you have any source code for the borad? like u-boot? |
| 11:27.04 | sn9 | u-boot, yes |
| 11:27.39 | sn9 | should be easier to deal with than datasheets |
| 11:28.02 | sn9 | but, i'm wondering how to do the init fom within openocd |
| 11:29.28 | sn9 | *from |
| 11:29.32 | drath | memory writes to the appropriate locations |
| 11:29.40 | drath | you can put them in a file, and have them execute as an init script |
| 11:30.10 | drath | but if you have a working u-boot binary, it might be easier to flash just that |
| 11:30.25 | sn9 | that was my intention |
| 11:30.48 | sn9 | but i am hoping to use the working_area to do that |
| 11:31.32 | drath | 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 |
| 11:32.33 | sn9 | i want to verify_image before flashing, to make sure i have something to roll back to |
| 11:39.45 | sn9 | drath: in the meantime, might as well commit the target_read/write_buffer fix |
| 13:28.43 | *** join/#openjtag DGMurdockIII (n=dgmurdoc@64-184-10-254.bb.hrtc.net) |
| 13:30.44 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:42.02 | *** part/#openjtag DGMurdockIII (n=dgmurdoc@64-184-10-254.bb.hrtc.net) |
| 13:55.52 | *** join/#openjtag prpplague^2 (n=dave@mail.americanmicrosystems.com) |
| 18:05.25 | sn9 | drath: ping |
| 18:05.52 | drath | sn9: pong |
| 18:06.12 | sn9 | "flash fillw" doesn't seem to do anything |
| 18:06.19 | sn9 | just returns |
| 18:07.32 | sn9 | btw, line 908 of src/flash/flash.c has the same mistake you fixed in r957 |
| 18:11.10 | drath | sn9: are you sure? at first glance that line seems ok |
| 18:11.15 | sn9 | nope |
| 18:11.33 | sn9 | - if ((addr >= c->base) && (addr < c->base + c->size) && target == c->target) |
| 18:11.33 | sn9 | + if ((addr >= c->base) && (addr - 1 < c->base + c->size - 1) && target == c->target) |
| 18:12.03 | drath | ah, ok, i see what you mean |
| 18:13.39 | sn9 | doesn't fix "flash fillw" though -- something else is going on there |
| 18:15.37 | drath | "flash fillw" always felt like a pretty useless command to me - probably didn't get a lot of testing |
| 18:16.51 | sn9 | it's not useless to me atm -- i need to zero almost 2 megs |
| 18:17.23 | drath | zero? |
| 18:17.28 | sn9 | yep |
| 18:17.59 | drath | well, dd if=/dev/zero of=zero_2m bs=1024 count=2048 would get you a 2MB zero binary |
| 18:18.13 | sn9 | takes forever to flash that, though |
| 18:18.32 | drath | why do you think "flash fillw" could be faster? |
| 18:18.59 | sn9 | no transfer of the data -- just tell the cpu to do it, right? |
| 18:19.44 | drath | sn9: did you manage to get working_area 'working'? |
| 18:20.08 | sn9 | no, i duplicated the writes in the u-boot source exactly, no diff |
| 18:20.42 | drath | well, setting up sdram is pretty complex, and easy to get wrong |
| 18:20.53 | drath | fillw doesn't anything different than a normal flash write |
| 18:21.05 | drath | it builds a buffer using the desired pattern, and writes that to flash |
| 18:24.39 | sn9 | i'll try just leaving that part FF |
| 18:35.31 | sn9 | now flashing u-boot on (finally) |
| 21:51.30 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 23:51.17 | *** join/#openjtag ChanServ (ChanServ@services.) |
| 23:51.17 | *** join/#openjtag wookey__ (n=wookey@stoneboat.aleph1.co.uk) |
| 23:51.18 | *** mode/#openjtag [+o ChanServ] by irc.freenode.net |
| 23:52.33 | *** join/#openjtag ChanServ (ChanServ@services.) |
| 23:52.33 | *** join/#openjtag wookey__ (n=wookey@stoneboat.aleph1.co.uk) [NETSPLIT VICTIM] |
| 23:52.33 | *** mode/#openjtag [+o ChanServ] by irc.freenode.net |