More mystery SoC progress. The Big Trace yielded results; tracing the memory read on a debugging string lead me to what presumably is the printf function, and going back from there I could see its address getting loaded into registers. That gave me the instructions to load a register (which actually are two: one loads the top 16 bit, a second one loads the bottom 16 bit) as well as the flash mapping: it simply lives in its entirety at 0x06000000 in the address space.
Now I had a nice plan to figure out the rest of the opcodes: simply put a 'printf("%x %x %x %x")' somewhere at the start of the boot sequence, dump the instructions to test in front of it, flash, run, see the results. Only issue: what I thought was an UART pin, is not. It's labeled 'TX' but also goes to the poweron led. I'm wondering if they ran out of pins, made that pin dual-use for power and debug tx, and in the final firmware simply disabled the debug tx function... in that case, I have no way to see the output of the printf function at all.
I'm gonna snoop around on the pins a bit more; perhaps there still is a hidden tx somewhere. If not, I may try to trace where the LED is initialized; perhaps nixing out that subroutine yields me a working UART. If all that fails, I need to find another way to get the info out... I could use memory dereferences as one way as I can spot those on the logic analyzer, but that would be limiting (because limited address space and the data cache) as well as incredibly tedious. I could use the LCD if I could find a sprintf/show_string function, but that combination seems to not really exist in the firmware; perhaps I can still hack something though.
One lead at least is that I found a test mode: if you put a file called selftest.bin on the sd-card, it goes into a self test mode that shows things like serial, chip number, battery status, lcd type, sensor types etc. Possibly I can hijack one of those print functions to do what I need.
