| 00:45.59 | *** join/#openjtag Openfree` (~Openfreer@116.228.88.131) |
| 00:55.25 | *** join/#openjtag _julian (~quassel@hmbg-4d06d645.pool.mediaWays.net) |
| 02:03.48 | *** join/#openjtag lool (~lool@debian/developer/lool) |
| 04:02.22 | *** join/#openjtag hazelnusse (~quassel@c-98-255-2-50.hsd1.ca.comcast.net) |
| 05:24.43 | *** join/#openjtag toi (~peter@vrt.nat.ibbt.be) |
| 07:41.38 | *** join/#openjtag LikWidChz (LikWid2k@c-71-236-175-13.hsd1.or.comcast.net) |
| 07:47.54 | *** join/#openjtag Rogan (~rogan@196-210-202-168.dynamic.isadsl.co.za) |
| 07:48.09 | Rogan | 'm trying to get a JLink adapter to talk to my DNS323 (Feroceon CPU) |
| 07:48.17 | Rogan | unfortunately, when OpenOCD starts, it executes the reset, and then powers off a few seconds later |
| 07:48.25 | Rogan | I suspect that I have some problems with my reset configuration, and was wondering if anyone could help me debug it |
| 07:48.34 | Rogan | is a JTAG n00b :-P |
| 08:50.22 | roxfan | try increasing debug level |
| 08:52.05 | Rogan | hi roxfan, will do |
| 08:53.53 | Rogan | Actually, it seems to have been as a result of the specification of trst_and_srst that the resets happen |
| 08:54.08 | Rogan | changing that to just srst_only solved the resets |
| 08:54.37 | Rogan | however, now I see the board resetting three times when openocd is run, and then I get a bunch of errors from OpenOCD |
| 08:57.44 | Rogan | starting with: |
| 08:57.44 | Rogan | Error: 162 328 jlink.c:967 jlink_usb_message(): jlink_usb_message failed with result=1) |
| 08:57.45 | Rogan | Error: 163 328 jlink.c:790 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) |
| 09:09.56 | *** join/#openjtag LikWidCHH (LikWid2k@c-71-236-175-13.hsd1.or.comcast.net) |
| 09:28.55 | Rogan | here is my detailed log: http://pastie.org/1766984 |
| 12:23.46 | Rogan | FWIW, and if anyone is googling for that error message, I solved the problem by forcing the jtag_khz to 50 |
| 12:24.01 | Rogan | any faster than that and I get error messages. |
| 12:54.35 | rigid | just thought, would it make sense to implement DFU in OpenOCD? |
| 12:54.56 | rigid | i'm not sure since it's only about firmware up-/downloading, no debugging or such |
| 14:20.40 | *** join/#openjtag Rogan (~rogan@196-210-202-168.dynamic.isadsl.co.za) |
| 15:00.43 | *** join/#openjtag Rogan (~rogan@196-210-222-49.dynamic.isadsl.co.za) |
| 15:40.05 | *** join/#openjtag Rogan (~rogan@196-210-222-49.dynamic.isadsl.co.za) |
| 15:49.35 | *** join/#openjtag Ceriand|work (~Ceriand@unaffiliated/ceriand) |
| 16:07.34 | *** join/#openjtag Weaselweb (~quassel@2001:6f8:9e4:123:21a:92ff:fe5a:1409) |
| 16:45.04 | *** join/#openjtag mnt_real (~mnt_real@bas11-montrealak-1177756264.dsl.bell.ca) |
| 16:55.57 | *** join/#openjtag Rogan (~rogan@196-210-153-155.dynamic.isadsl.co.za) |
| 18:59.04 | *** join/#openjtag toi (~peter@d54C2AA76.access.telenet.be) |
| 19:05.57 | *** join/#openjtag dub00t (~nslottow@brazos-old.eecs.umich.edu) |
| 19:06.43 | dub00t | Hi all. Does anyone have experience working with or writing NAND flash drivers for OpenOCD? |
| 19:07.45 | dub00t | Documentation is sparse. I though I'd ask here before trying to tear apart some of the drivers in the project. |
| 19:26.45 | Rogan | not i, I'm afraid |
| 19:27.31 | Rogan | I'm wondering how to get out of the state that I'm currently in, that my device won't halt at all, now that I have killed the existing bootloader |
| 19:31.08 | ius | dub00t: The headers/code were pretty self-explanatory for me |
| 19:31.51 | ius | (As in, I hacked together a OneNAND driver) |
| 19:32.21 | ius | Would be really nice to upstream, but it's hacked up and probably quite specific to my target nand |
| 19:39.40 | dub00t | ius: Ah. So maybe I'll just have a look at the code. Are there any bits of code that you looked at that were particularly helpful? Anything to watch out for? |
| 19:41.04 | dub00t | ius: I'm going to have to insert our software flash translation layer between the JTAG and the flash for programming and debugging purposes |
| 19:51.18 | ius | Hmm that might be a bit more complicated |
| 19:53.39 | ius | flash/nand/driver.h contains the meat, the functions it wants you to implement for a NAND driver |
| 19:54.08 | ius | Which is supposed to have a notion of blocks, pages etc. Not sure how it would fit if you're actually trying to fit a FTL inbetween |
| 19:54.58 | ius | The other alternative is the 'flash' driver framework, which seems to be oriented towards nor/random access flash |
| 20:02.27 | Rogan | can anyone help me out? I have bricked my device, and can't seem to get it back to life |
| 20:03.18 | Rogan | I have managed to upload an abbreviated u-boot (minus the low level boot code), but I can't instruct the device to execute it |
| 20:03.38 | Rogan | I get the following: |
| 20:03.39 | dub00t | ius: Hm, I think the NAND interface is what I'm looking for as our FTL doesn't abstract the chip to be random access (it moves blocks around). I'll start there, thanks. |
| 20:03.42 | Rogan | > resume 0x3000000 |
| 20:03.42 | Rogan | target state: halted |
| 20:03.43 | Rogan | target halted in ARM state due to debug-request, current mode: Supervisor |
| 20:27.58 | Ceriand|work | Rogan: if your device has DRAM, you probably have to setup the controller before you can use it |
| 20:31.03 | Rogan | Ceriand|work: I believe that is the problem, yes |
| 20:31.15 | Rogan | I have tried to execute the appropriate command |
| 20:31.44 | Rogan | mww 0xd0001480 0x00000001 |
| 20:31.53 | Rogan | which did not give any errors |
| 20:32.16 | Rogan | and I was able to upload new code to try to recover |
| 20:32.47 | Rogan | but was not able to execute that code due to the errors shown above |
| 20:33.06 | Rogan | any hints on how to get out of supervisor mode? |
| 20:48.36 | Ceriand|work | u-boot should be running in supervisor mode |
| 20:48.52 | Rogan | oh. I guess I don't understand something then :-) |
| 20:49.27 | Ceriand|work | sometimes chips can get in a weird state if you suspend them while they're running |
| 20:49.41 | Rogan | how do i get it to execute the code I just uploaded? resume 0x3000000 doesn't seem to work |
| 20:49.49 | Ceriand|work | have you tried doing a reset halt before jumping to your code? |
| 20:50.13 | Ceriand|work | what chip is your device using? |
| 20:50.19 | Rogan | times out waiting for the halt |
| 20:50.23 | Rogan | feroceon |
| 20:50.35 | Rogan | orion5x with a feroceon core |
| 20:50.53 | Rogan | to be precise, it is a Marvell MV8F5182 |
| 20:51.02 | Rogan | to be precise, it is a Marvell MV88F5182 |
| 20:51.14 | Ceriand|work | haven't done much with those personally |
| 20:52.00 | Rogan | I did the reset halt, then resume 0x3000000 |
| 20:52.10 | Rogan | still got the same error messages |
| 20:52.20 | Rogan | > resume 0x3000000 |
| 20:52.20 | Rogan | target state: halted |
| 20:52.20 | Rogan | target halted in ARM state due to debug-request, current mode: Supervisor |
| 20:52.20 | Rogan | cpsr: 0x000000d3 pc: 0x03000014 |
| 20:52.20 | Rogan | MMU: disabled, D-Cache: disabled, I-Cache: disabled |
| 20:55.48 | Ceriand|work | Rogan: what are you trying to do again? |
| 20:56.03 | Rogan | I have a DNS323 NAS, which has a crippled U-boot |
| 20:56.14 | Rogan | vendor u-boot has no features |
| 20:56.18 | Rogan | I want to replace it |
| 20:56.46 | Ceriand|work | with what? |
| 20:56.53 | Rogan | I have got a new u-boot working, that I can chain load from the vendor one, using CONFIG_SKIP_LOWLEVEL_INIT |
| 20:57.13 | Rogan | now I have undefined that, and wanted to try to flash it in place of the vendor one |
| 20:57.20 | Rogan | which I did |
| 20:57.27 | Ceriand|work | does u-boot have support for that board? |
| 20:57.28 | Rogan | but now it won't boot |
| 20:57.34 | Rogan | it does now :-) |
| 20:57.48 | Rogan | well, I have got it working over the last several months |
| 20:57.53 | Rogan | but only using CONFIG_SKIP_LOWLEVEL_INIT |
| 20:58.19 | Ceriand|work | I suspect your lowlevel init is probably wrong/broken |
| 20:58.27 | Rogan | i.e. boot vendor u-boot, download my new image using kermit, use vendor u-boot to bootm into the new one |
| 20:58.37 | Rogan | Ceriand|work: I think so too |
| 20:59.00 | Rogan | I'm relying on work done for a similar device, using the same SoC |
| 20:59.17 | Ceriand|work | does reading/writing to ram work? |
| 20:59.20 | Rogan | but clearly it doesn't do the right thing, for some reason |
| 20:59.25 | Rogan | I can read flash |
| 20:59.27 | Ceriand|work | from openocd |
| 21:00.14 | Rogan | did an mdw, and it showed bytes as expected in the flash region |
| 21:00.24 | Ceriand|work | i'm talking about RAM |
| 21:00.37 | Rogan | am reuploading the ram-only image, and will see if I can read it back |
| 21:00.37 | Ceriand|work | u-boot probably won't work unless you have the RAM setup correctly |
| 21:00.55 | Ceriand|work | you can just poke in a dummy value and see if you can read it back |
| 21:01.13 | Rogan | well, the upload is in progress |
| 21:01.22 | Rogan | will finish in a minute or so |
| 21:02.10 | Ceriand|work | shouldn't flash be at 0xf8000000 on that cpu? |
| 21:02.24 | Ceriand|work | not 0x3000000 |
| 21:02.26 | Rogan | 0xff8000000 |
| 21:02.49 | Rogan | I uploaded the RAM-only image to 3000000, so I can start that |
| 21:02.56 | Ceriand|work | ah |
| 21:03.05 | Rogan | then use that to flash the replacement to NOR |
| 21:03.15 | Rogan | I haven't managed to get openOCD to recognise my flash |
| 21:03.44 | Rogan | I guess if I can get that right, I can avoid all this unpleasantness :-P |
| 21:04.49 | Rogan | well, I can read my RAM-only image back from RAM |
| 21:04.58 | Rogan | at least, the first 8 bytes :-) |
| 21:05.03 | Ceriand|work | good sign :) |
| 21:05.08 | Rogan | I assume the rest will match too |
| 21:05.17 | Ceriand|work | you could do a crc32 on it |
| 21:05.23 | Ceriand|work | I believe oocd supports that |
| 21:05.42 | Rogan | help crc gives nothing |
| 21:05.52 | *** join/#openjtag RikusW (~RikusW@41.8.127.226) |
| 21:06.06 | RikusW | http://sites.google.com/site/megau2s/home/jtag |
| 21:06.12 | RikusW | http://www.ruemohr.org/docs/debugwire.html |
| 21:06.38 | RikusW | for AVR |
| 21:07.45 | Ceriand|work | Rogan: I would disassemble the vendor u-boot and see if you're missing anything in the lowlevel init |
| 21:08.30 | Rogan | hehe. Over my head, I'm afraid |
| 21:09.11 | Ceriand|work | or find the source code to the vendor u-boot and look at what they did |
| 21:09.14 | Rogan | I've pinged the maintainer for the ARM branch of u-boot, and the other device using the same SoC |
| 21:09.28 | Rogan | hopefully he will be able to help me |
| 21:10.21 | Ceriand|work | reversing bootloaders isn't very hard |
| 21:10.42 | Ceriand|work | just grab http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf and a copy of IDA |
| 21:11.00 | Rogan | ok, will have to wait for another night |
| 21:11.01 | Ceriand|work | or just run it though objdump if you're cheap |
| 21:11.02 | Rogan | bedtime |
| 21:11.10 | Rogan | hehe, that I am |
| 21:11.15 | Rogan | thanks for your help |
| 21:11.22 | Ceriand|work | np, gl |
| 22:31.48 | *** join/#openjtag roxfan (dunno@91.180.56.250) |
| 23:39.09 | *** part/#openjtag RikusW (~RikusW@41.8.127.226) |