On Tue, Jul 10, 2012 at 4:03 PM, Nils Faerber <[email protected]> wrote: > Hello! > I curently experience a pretty strange situation on a new ARM11 MPcore > board I am working on... > The board is using a Cavium CNS3420 SoC. I have made a custom OpenOCD > config based partially on Scott Shu's blog entry: > http://scottshulinux.blogspot.de/2011_03_01_archive.html > (openocd-cnx.cfg) > and some more initializations for the custom board I am working on - > like proper DDR config etc. > > The first strange thing I am seeing should be pretty unrelated to extra > configs as I can also see this on the CNS3420 reference board: I can not > halt the CPU core. > After board switch-on U-Boot will come up and I can successfully attach > OpenOCD through the JTAG - the taps are found > > Info : JTAG tap: arm11.cpu0 tap/device found: 0x07b37477 (mfg: 0x23b, > part: 0x7b37, ver: 0x0) > Info : JTAG tap: arm11.cpu1 tap/device found: 0x07b37477 (mfg: 0x23b, > part: 0x7b37, ver: 0x0) > Info : found ARM11 MPCore > > If I then issue an OpenOCD "halt" command U-Boot will still be > responsive on the serial interface. > How is that? Shouldn't it *halt* the core? > > My custom board I have to bring-up does not have pre-programmed flash > chips so I have to rely on being able to download the initial U-Boot > code to RAM and execute it from there. > > I have written the necessary init sequence to get PLLs and the DDR > controller out of reset and can successfully write an image through JTAG > into the DDR RAM - I can after writing read back the image and it is > correct. > > But a "resume" from the load address (here it is by default 0x00) does > not start U-Boot. *Sometimes* (roughly one out of a felt 100 times) > U-Boot either suddenly starts to execute on its own or it starts after a > subsequent new reset and board init. > > > This is pretty strange :( > And especially this is too unreliable for me to start actual development... > > My current theory is that OpenOCD might communicate with the wrong core? > The CNS3420 is a SMP dual core CPU. After power on reset core0 takes > control and starts to execute from 0x00. > Assuming OpenOCD would go through core1 instead or core0 som eof my > above observations could probably explained.
Just a thought, and I don't really have a clue, but shouldn't the two taps corresponding to the two cores have different names? And the target creation reference the tap/core that you want to control? Something like: jtag newtap arm11 cpu0 -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id $_CPUTAPID jtag newtap arm11 cpu1 -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id $_CPUTAPID target create arm11.cpu arm11 -chain-position arm11.cpu0 -endian $_ENDIAN -variant arm11 /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
