Stingray support

[gezedo]

Hi there,
I started to work on a similar project for the Stingray module, which is the successor of Barracuda, because my Grace Digital Internet radio has one.
I am not sure whether people are still hacking around here, but I will be happy to share my progresses to whoever is interested.

[trygvelu]

Did you make any progress on this?
I would be interested in any findings..

[gezedo]

I failed to find a way into the stingray without soldering. My first goal being to install my ssh key and use an USB/ethernet adapter.
I had to solder JTAG, and I used openOCD to hack into the memory while the kernel booted to force init script to write my ssh key to the flash storage.
Now I can log in fine.
I want to write some test sw, but I am currently stuck rebuilding a toolchain.
Not my top priority at the moment, I will likely come back to it some time later.

[trygvelu]

Well that's a start - I'd be happy if I could do the same. What kind of jtag adapter did you use?

[gezedo]

I use Amontec's jtagkey-tiny, which is more or less equivalent to any ftdi232/MPSSE based adapter.
I think that there is something interesting to do with 3 inputs of the Stingray board that are used (voltage sampling) during by the bootloader and Linux boot scripts, to get some identifier of the system. One or more identifier could match a dev board and allow to do unauthenticated upgrades. That would remove the need to jtag the board to get access to it.

[trygvelu]

Did you map up the pin headers? My radio is a Rotel RT-12, and it might be somewhat special since the Stingray seems to be running in slave mode (through i2c?) - the main CPU of the RT-12 is a STM32 variant. I pulled out the Stingray module, and it seems to be the 'A' variant - i.e. no DAB/FM, those parts are unpopulated on the PCB. The Stingray is supposed to be pin compatible with the Barracuda - but there are some extra pins. A developer manual or technical reference would be really handy I think!

[gezedo]

I am afraid I do not know much about the pinout except for the part compatible with barracuda. Extra pins are likely to support a better LCD (more colors, more pixels), and others stuff I don't know yet. I'll check that later.
I am currently focused on the 3 analog inputs that can serve as board identifier.

[trygvelu]

I soldered the jtag test points and was so far able to connect and dump the nand flash (32M) - but not really experienced with openocd, so if you have some notes on how you were able to modify the init script to get the ssh key in - that could potentially save me some headache.

[gezedo]

Just notes. This is not an easy method, yet I used it because it not destructive to get a command executed.
Her is the idea: put a breakpoint until the kernel loaded the linuxrc init script, then search the memory, modify the script to write a public ssh key into /root/.ssh/authorized_keys, so that you can connect through ssh later.

The following connects and halts the cpu, useful to interrupt the boot process, then place the breakpoint:
openocd -d -f interface/ftdi/jtagkey.cfg -f s3c2412.cfg -c init -c halt

s3c2412.cfg is derived from openocd package, you must change the work-area-size to 0x1000 if not already at that value.

Here are a few commands that have been useful for me, note that addresses might be different on your target, since they depend on the build for bootloader and kernel, you need to disassemble them to check addresses:

bp 0xc00097fc 4 hw; resume
load_image cmdline.txt 0x30016110
bp 0xc0066c84 4 hw; resume
dump_image logbuf.txt 0xc01d381c 0x4000
set fh [open dram.txt wb]; for {set i 0xc0000000} {$i < 0xc2000000} {set i [expr {$i+0x1000}]} { puts -nonewline $fh [mdb $i 16] }; close $fh
dump_image linuxrc.ram 0xc034d000 0x1000
load_image linuxrc.ram 0xc034d000
resume

First breakpoint halts in the kernel at setup_arch().
The command line is stored at a fixed address (check kernel parse_tag_cmdline() to find out), then modify it to add "nohlt" which prevents kernel to use WFI and keeps the debug connection alive.
Second breakpoint halts in search_binary_handler(), which is where the kernel will parse linuxrc after it has been loaded from flash. Now you need the address in DRAM of the file content.
The dump command to get the logbuf can be handy to confirm where the kernel halted, or to analyse crashes. The address can be found by analysing the emit_log_char() function.
The long command exports the first 16 bytes of each DRAM pages are dumped, to find out where linuxrc is stored. There should be a better method, but I find out this one give a good result (long to run though).
Then linuxrc is dumped, modified and execution resumed.
I told you, not super simple, but it worked for me.