**** BEGIN LOGGING AT Thu Apr 07 02:59:59 2011
Apr 07 07:48:29 <Rogan> 'm trying to get a JLink adapter to talk to my DNS323 (Feroceon CPU)
Apr 07 07:48:36 <Rogan> unfortunately, when OpenOCD starts, it executes the reset, and then powers off a few seconds later
Apr 07 07:48:45 <Rogan> I suspect that I have some problems with my reset configuration, and was wondering if anyone could help me debug it
Apr 07 07:48:54 * Rogan is a JTAG n00b :-P
Apr 07 08:50:42 <roxfan> try increasing debug level
Apr 07 08:52:25 <Rogan> hi roxfan, will do
Apr 07 08:54:13 <Rogan> Actually, it seems to have been as a result of the specification of trst_and_srst that the resets happen
Apr 07 08:54:28 <Rogan> changing that to just srst_only solved the resets
Apr 07 08:54:57 <Rogan> however, now I see the board resetting three times when openocd is run, and then I get a bunch of errors from OpenOCD
Apr 07 08:58:04 <Rogan> starting with:
Apr 07 08:58:05 <Rogan> Error: 162 328 jlink.c:967 jlink_usb_message(): jlink_usb_message failed with result=1)
Apr 07 08:58:05 <Rogan> Error: 163 328 jlink.c:790 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1)
Apr 07 09:29:16 <Rogan> here is my detailed log: http://pastie.org/1766984
Apr 07 12:24:07 <Rogan> FWIW, and if anyone is googling for that error message, I solved the problem by forcing the jtag_khz to 50
Apr 07 12:24:23 <Rogan> any faster than that and I get error messages.
Apr 07 12:54:57 <rigid> just thought, would it make sense to implement DFU in OpenOCD?
Apr 07 12:55:17 <rigid> i'm not sure since it's only about firmware up-/downloading, no debugging or such
Apr 07 19:07:06 <dub00t> Hi all.  Does anyone have experience working with or writing NAND flash drivers for OpenOCD?
Apr 07 19:08:08 <dub00t> Documentation is sparse.  I though I'd ask here before trying to tear apart some of the drivers in the project.
Apr 07 19:27:08 <Rogan> not i, I'm afraid
Apr 07 19:27:54 <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
Apr 07 19:31:32 <ius> dub00t: The headers/code were pretty self-explanatory for me
Apr 07 19:32:14 <ius> (As in, I hacked together a OneNAND driver)
Apr 07 19:32:44 <ius> Would be really nice to upstream, but it's hacked up and probably quite specific to my target nand
Apr 07 19:40:04 <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?
Apr 07 19:41:28 <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
Apr 07 19:51:42 <ius> Hmm that might be a bit more complicated
Apr 07 19:54:02 <ius> flash/nand/driver.h contains the meat, the functions it wants you to implement for a NAND driver
Apr 07 19:54:32 <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
Apr 07 19:55:21 <ius> The other alternative is the 'flash' driver framework, which seems to be oriented towards nor/random access flash
Apr 07 20:02:51 <Rogan> can anyone help me out? I have bricked my device, and can't seem to get it back to life
Apr 07 20:03:42 <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
Apr 07 20:04:02 <Rogan> I get the following:
Apr 07 20:04:02 <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.
Apr 07 20:04:06 <Rogan> > resume 0x3000000
Apr 07 20:04:06 <Rogan> target state: halted
Apr 07 20:04:06 <Rogan> target halted in ARM state due to debug-request, current mode: Supervisor
Apr 07 20:28:22 <Ceriand|work> Rogan: if your device has DRAM, you probably have to setup the controller before you can use it
Apr 07 20:31:27 <Rogan> Ceriand|work: I believe that is the problem, yes
Apr 07 20:31:39 <Rogan> I have tried to execute the appropriate command
Apr 07 20:32:08 <Rogan> mww 0xd0001480 0x00000001
Apr 07 20:32:17 <Rogan> which did not give any errors
Apr 07 20:32:40 <Rogan> and I was able to upload new code to try to recover
Apr 07 20:33:11 <Rogan> but was not able to execute that code due to the errors shown above
Apr 07 20:33:29 <Rogan> any hints on how to get out of supervisor mode?
Apr 07 20:48:59 <Ceriand|work> u-boot should be running in supervisor mode
Apr 07 20:49:16 <Rogan> oh. I guess I don't understand something then :-)
Apr 07 20:49:51 <Ceriand|work> sometimes chips can get in a weird state if you suspend them while they're running
Apr 07 20:50:05 <Rogan> how do i get it to execute the code I just uploaded? resume 0x3000000 doesn't seem to work
Apr 07 20:50:13 <Ceriand|work> have you tried doing a reset halt before jumping to your code?
Apr 07 20:50:37 <Ceriand|work> what chip is your device using?
Apr 07 20:50:43 <Rogan> times out waiting for the halt
Apr 07 20:50:47 <Rogan> feroceon
Apr 07 20:50:59 <Rogan> orion5x with a feroceon core
Apr 07 20:51:16 <Rogan> to be precise, it is a Marvell MV8F5182
Apr 07 20:51:26 <Rogan> to be precise, it is a Marvell MV88F5182
Apr 07 20:51:38 <Ceriand|work> haven't done much with those personally
Apr 07 20:52:24 <Rogan> I did the reset halt, then resume 0x3000000
Apr 07 20:52:34 <Rogan> still got the same error messages
Apr 07 20:52:44 <Rogan> > resume 0x3000000
Apr 07 20:52:44 <Rogan> target state: halted
Apr 07 20:52:44 <Rogan> target halted in ARM state due to debug-request, current mode: Supervisor
Apr 07 20:52:44 <Rogan> cpsr: 0x000000d3 pc: 0x03000014
Apr 07 20:52:44 <Rogan> MMU: disabled, D-Cache: disabled, I-Cache: disabled
Apr 07 20:56:11 <Ceriand|work> Rogan: what are you trying to do again?
Apr 07 20:56:27 <Rogan> I have a DNS323 NAS, which has a crippled U-boot
Apr 07 20:56:38 <Rogan> vendor u-boot has no features
Apr 07 20:56:42 <Rogan> I want to replace it
Apr 07 20:57:10 <Ceriand|work> with what?
Apr 07 20:57:17 <Rogan> I have got a new u-boot working, that I can chain load from the vendor one, using CONFIG_SKIP_LOWLEVEL_INIT
Apr 07 20:57:37 <Rogan> now I have undefined that, and wanted to try to flash it in place of the vendor one
Apr 07 20:57:44 <Rogan> which I did
Apr 07 20:57:51 <Ceriand|work> does u-boot have support for that board?
Apr 07 20:57:52 <Rogan> but now it won't boot
Apr 07 20:57:58 <Rogan> it does now :-)
Apr 07 20:58:12 <Rogan> well, I have got it working over the last several months
Apr 07 20:58:17 <Rogan> but only using CONFIG_SKIP_LOWLEVEL_INIT
Apr 07 20:58:43 <Ceriand|work> I suspect your lowlevel init is probably wrong/broken
Apr 07 20:58:51 <Rogan> i.e. boot vendor u-boot, download my new image using kermit, use vendor u-boot to bootm into the new one
Apr 07 20:59:01 <Rogan> Ceriand|work: I think so too
Apr 07 20:59:24 <Rogan> I'm relying on work done for a similar device, using the same SoC
Apr 07 20:59:41 <Ceriand|work> does reading/writing to ram work?
Apr 07 20:59:44 <Rogan> but clearly it doesn't do the right thing, for some reason
Apr 07 20:59:49 <Rogan> I can read flash
Apr 07 20:59:51 <Ceriand|work> from openocd
Apr 07 21:00:38 <Rogan> did an mdw, and it showed bytes as expected in the flash region
Apr 07 21:00:48 <Ceriand|work> i'm talking about RAM
Apr 07 21:01:01 <Rogan> am reuploading the ram-only image, and will see if I can read it back
Apr 07 21:01:01 <Ceriand|work> u-boot probably won't work unless you have the RAM setup correctly
Apr 07 21:01:19 <Ceriand|work> you can just poke in a dummy value and see if you can read it back
Apr 07 21:01:37 <Rogan> well, the upload is in progress
Apr 07 21:01:46 <Rogan> will finish in a minute or so
Apr 07 21:02:34 <Ceriand|work> shouldn't flash be at 0xf8000000 on that cpu?
Apr 07 21:02:48 <Ceriand|work> not 0x3000000
Apr 07 21:02:50 <Rogan> 0xff8000000
Apr 07 21:03:13 <Rogan> I uploaded the RAM-only image to 3000000, so I can start that
Apr 07 21:03:20 <Ceriand|work> ah
Apr 07 21:03:29 <Rogan> then use that to flash the replacement to NOR
Apr 07 21:03:39 <Rogan> I haven't managed to get openOCD to recognise my flash
Apr 07 21:04:07 <Rogan> I guess if I can get that right, I can avoid all this unpleasantness :-P
Apr 07 21:05:13 <Rogan> well, I can read my RAM-only image back from RAM
Apr 07 21:05:22 <Rogan> at least, the first 8 bytes :-)
Apr 07 21:05:27 <Ceriand|work> good sign :)
Apr 07 21:05:32 <Rogan> I assume the rest will match too
Apr 07 21:05:41 <Ceriand|work> you could do a crc32 on it
Apr 07 21:05:47 <Ceriand|work> I believe oocd supports that
Apr 07 21:06:06 <Rogan> help crc gives nothing
Apr 07 21:06:29 <RikusW> http://sites.google.com/site/megau2s/home/jtag
Apr 07 21:06:36 <RikusW> http://www.ruemohr.org/docs/debugwire.html
Apr 07 21:07:02 <RikusW> for AVR
Apr 07 21:08:09 <Ceriand|work> Rogan: I would disassemble the vendor u-boot and see if you're missing anything in the lowlevel init
Apr 07 21:08:54 <Rogan> hehe. Over my head, I'm afraid
Apr 07 21:09:35 <Ceriand|work> or find the source code to the vendor u-boot and look at what they did
Apr 07 21:09:38 <Rogan> I've pinged the maintainer for the ARM branch of u-boot, and the other device using the same SoC
Apr 07 21:09:52 <Rogan> hopefully he will be able to help me
Apr 07 21:10:45 <Ceriand|work> reversing bootloaders isn't very hard
Apr 07 21:11:06 <Ceriand|work> just grab http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf and a copy of IDA
Apr 07 21:11:24 <Rogan> ok, will have to wait for another night
Apr 07 21:11:25 <Ceriand|work> or just run it though objdump if you're cheap
Apr 07 21:11:27 <Rogan> bedtime
Apr 07 21:11:34 <Rogan> hehe, that I am
Apr 07 21:11:39 <Rogan> thanks for your help
Apr 07 21:11:46 <Ceriand|work> np, gl
**** ENDING LOGGING AT Fri Apr 08 02:59:58 2011