I took every shortcut, depending on the initialization that U-Boot had done to get the console port working. This is of course lazy, but the goal here is to get some code working with an absolute minimum of effort.
After sorting out two problems, it worked! It took only an hour or two, most of which were spent locating appropriate files in other projects that I could copy. The only real work was typing in a struct for the RK3399 uart hardware.
You can see below that this thing fits in 472 bytes. The code that didn't work because it was compiled for 32 bit was only 250 bytes, which is interesting. But I have 4G of ram, so "what me worry"?
You will find the sources for the "hello" project on my Github page:
Bytes transferred = 251 (fb hex) ## Starting application at 0x02000000 ... "Synchronous Abort" handler, esr 0x02000000 elr: ffffffff0a2e6008 lr : ffffffff082e6000 (reloc) elr: 0000000002000008 lr : 0000000000000000 x0 : 0000000000000001 x1 : 00000000f5f1df68 x2 : 00000000f5f1df68 x3 : 00000000ff1a0000 x4 : 00000000ff1a0000 x5 : 00000000f5f034e8 x6 : 0000000000000030 x7 : 000000000000000f x8 : 00000000f5f03b58 x9 : 0000000000000008 x10: 00000000ffffffd0 x11: 0000000000000010 x12: 0000000000000004 x13: 0000000000000200 x14: 000000000000003a x15: 0000000000000001 x16: 0000000002000000 x17: 0000000000000000 x18: 00000000f5f11dd0 x19: 00000000f5f1df68 x20: 00000000f5f1df67 x21: 0000000000000002 x22: 00000000f5f1df60 x23: 0000000000000002 x24: 00000000f7fd57ac x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000f5f1dfc0 x29: 00000000f5f03b90 Code: ffffffff ffffffff eb000034 eafffffe (e52db004) Resetting CPU ...This was because I was using the 32 bit arm compiler and really needed the 64 bit compiler. So I robbed the makefile from my Allwinner H5 project.
After doing this, my code didn't get exceptions, but it didn't do anything. This turned out to be because the UART that the Orange Pi 4 board uses is UART2 and not UART0. Who knows why, but this is not the first time I have been surprised by this sort of thing. The clue was in the U-Boot messages, which had this bit of useful information:
In: serial@ff1a0000
When it finally runs, I see this:
GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xc7ec8 RunBL31 0x40000 NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.04-orangepi (Mar 04 2021 - 09:49:58 +0800) Model: OrangePi 4 AI board DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... OK In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: OrangePi 4 AI board Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 Booting Kyu via dhcp ethernet@fe300000 Waiting for PHY auto negotiation to complete........ done Speed: 1000, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.0.34 (0 ms) Using ethernet@fe300000 device TFTP from server 192.168.0.5; our IP address is 192.168.0.34 Filename 'rock.bin'. Load address: 0x2000000 Loading: # 230.5 KiB/s done Bytes transferred = 472 (1d8 hex) ## Starting application at 0x02000000 ... hello hello hello hello hello hello hello hello hello hello hello ....
Tom's electronics pages / tom@mmto.org