BOOTROM Anyka 3918v300

[oliv3r]

Not sure if this repo, this way, is the best way of discussing things or dumping information, but I've extracted the bootrom from this chip, and thought it be good to leave somewhere :)

Dumping was done using the env trick mentioned elsewhere, and just write the first 16k of address space onto the mmc. bootrom.bin.gz

Obviously, not a lot of string in there, but there are some; meaning the bootrom can print something 'somewhere'.

HANYKA_H3
H0@-
failed in buffer state!
failed in buffer state2!
USBCL'
SCSI=
donwload finish.
goto addr: 0x
  id
A: 0x
 L: 0x
upload A: 0x
 V: 0x
UNDERRUN.
STALL.
SUNDANCEH3_Massboot>#
FDISK   UNIVERSAL       6168p
USBS
ANYKA DESIGNE

It should have bootloader support to boot from UART/USB/MMC (how do you provision otherwise) as bootrom's do; but at 16k, not much will be supported of course. Lets see what ghidra finds for fun :)

One thing that was curious to me; and maybe I'm cheering to soon; is that the reset vector does indeed branch off to execute code in this bit; but all other vectors, are setup to jump to RAM. Which is of course very odd, as the ram controller has not been setup yet, nor is there any data at these addresses yet; I think the standard practise is to put either a jump to the reset vector, or a nop; but not to jump to something non-existant ...

[guino]

@oliv3r did you ever email me about the UART access ? I don't remember.

These bootloaders are sometimes compressed so they load somewhere, decompress and jump to a different location (where the vectors may point to). I haven't had a chance to look athis file, I'm just trying to answer your question.

[oliv3r]

@guino I can agree for a bootloader; but this is the BOOTROM in the SoC itself. It is highly unlikely they would do this, as they only have the SRAM to work with. I don't know yet how large it is (16k probably is my guess). So they probably do XIP (eXecute In Place) of the BROM, and with the 12k size of the current BOOTROM size that I have found so far, it just doesn't make sense to waste a lot of that space on a decompressor. Also, all code IS readable.

If you mean they decompress it into ram, they'd have to initialize the DRAM controller in the BROM; with the stacked stuff, this is def. possible. So far, I'm decoding only the first initial routines, so can't tell you this bit yet :) I'm using the Lamobo-D1 source code dump as register reference, so there's a big assumption that is correct for this chip.