This is different in many ways. Most hardware (such as the serial port) has not been initialized. DRAM has not been initialized. We don't have the handy ability of letting U-Boot use TFTP to load a binary file for us over the network. What we have to do is to package up our binary in a form that the bootrom will recognize then put it onto an SD card. This means that any experimentation involves taking cards in and out of the SD card socket and writing new images onto them using an SD card reader, connected to a USB port on my linux development system.
This diagram is someones view of the boot process. What we are doing is replacing what the diagram shows as "idbloader.img" with something of our own.
dd if=bare.img of=/dev/sdx seek=64 conv=notruncI will note in passing that the diagram above also indicates that the USB-OTG port can be used to send a boot image to the bootrom. I have not investiated the details of this, but it does require a host side program to communicate with the board.
The bootrom loads code into SRAM within the RK3399. There is 200K of this (some references say 192K). I have never had any temptations to push the limit, so the exact size is so far unimportant. Looking at existing code (namely the U-Boot TPL), the code loads to 0xff8c2000 and execution starts at 0xff8c2004. This is 0x2000 into the SRAM, skipping the first 8K bytes, which perhaps holds a stack.
I wrote a program called "mkrock" to generate the bootable image. This has a special header, which is rc4 encrypted using a well known rockchip key. I wrote this program after inspecting the mkimage program which ships with U-Boot. I could have simply used mkimage with the proper image, but I was interesting in learning all the details.
After this it was easy to copy my already tested and working printf function and write code to dump the bootrom locations, which was my goal in all of this anyway.
Tom's electronics pages / firstname.lastname@example.org