OpenOCD and SIMtrace

OpenOCD and SIMtrace

This is just a short note to myself (and then copied into our SIMtrace wiki).

This is working for OpenOCD (74558296d1e185fc4a7522f08832eceed460cbd7) and the Amontec JTAGKey (but should work with any JTAG adapter). The easiest way is to start OpenOCD with default config files.

The SIMtrace v1.0 hardware is powered by the Atmel SAM7S microcontroller and the closest match for this platform is the atmel_at91sam7s-ek.cfg board configuration file.

First try

$ sudo openocd -f interface/jtagkey.cfg -f board/atmel_at91sam7s-ek.cfg
…
Error: An adapter speed is not selected in the init script. Insert a call to adapter_khz or jtag_rclk to proceed…

Second try

You can patch one of the two files, create a new config file and load it with -f
or specify the command. The below example specifies it on the command line.

$ sudo openocd -f interface/jtagkey.cfg -f board/atmel_at91sam7s-ek.cfg -c “adapter_khz 30”

Final config

$ echo “adapter_khz 30
> arm7_9 dcc_downloads enable
> init
> reset init
> ” > myinit.cfg

$ sudo openocd -f interface/jtagkey.cfg -f board/atmel_at91sam7s-ek.cfg -f myinit.cfg

One of the calls appear to fix ‘halt’ not really halting the SoC, I have not investigated which of the options is doing it.

Flashing First try

$ telnet 127.0.0.1 4444
> flash write_image /tmp/main_simtrace.samba 0 bin
wrote 0 bytes from file /tmp/main_simtrace.samba in 0.238727s (0.000 KiB/s)

With a quick look into the NOR Flash code, it appears to fail as it does not
find a flash region at the address it is looking for one and then reports to
you the success of 0 bytes (instead of a failure).

Flashing Working

$ telnet 127.0.0.1 4444
> flash write_bank 0 /tmp/main_simtrace.samba 0
wrote 37020 bytes from file /tmp/main_simtrace.samba to flash bank 0 at offset 0x00000000 in 39.175068s (0.923 KiB/s)
> reset init
> resume

Standing on the shoulders of giants – Fixing OpenOCD for the Beagleboard

Standing on the shoulders of giants – Fixing OpenOCD for the Beagleboard

Ever since fixing a little bug in the breakpoint code for the s3c2442 I’m subscribed to the OpenOCD mailinglist. One mail catched my eye, the mail was from a former Openmoko colleague Matt Hsu. He is working with most of the Taiwan Openmoko Team at the newly founded 0xlab and he was trying OpenOCD on the OMAP3 beagleboard.

Yesterday I decided to go to their lab to hack with Matt on the Cortex-A8 support in OpenOCD. After downloading the datasheets, we started to poke the code and tried to get a picture of how things are supposed to work. We have fixed various candidates for failures, like not waiting for the previous instruction to be finished when executing, not waiting for data to be there before reading.

Our symptoms were that after typing “halt” a lot of “invalid mode” messages got printed. After some tracing we ended at the execution of one instruction. The Cortex-A8 supports a mode were an ARM instruction can be written to a register and this instruction will be executed when being in debug mode. Now for a debugger the instruction is copying registers and other data to a special channel that can be read from the debugger. After looking further every register dumped liked this had the value 0x0…After this we were sure to have found the place were things go wrong. All we needed to find out why this instruction is not properly executed.

After studying the datasheet some more, going through the bits of DSCR and DCCR, and looking at the value of DSCR we have, it was clear that we just need to enable execution of instructions from the ITR (Instruction Transfer Register).

After this debugging session I still have little knowledge about ADI and the related things and this is why Free Software is so great, I can spend one afternoon, and can make a big change, and I can do it because I build on support from previous developers!