Hi Vinicius,
On 10/9/26 14:03, Vinicius Pedrosa wrote:
Hi Yixun, Andre,
I'm porting U-Boot to the Radxa Cubie A7Z (A733, 1 GiB LPDDR4) and have
I read this wording ("I port xxx to the <board name>") now multiple
times, from different people (blame AI?), but please avoid that.
First: The main thing here is the SoC support, the board is just a minor
technicality. Once we have the DT bindings(!) settled, and figured the
clocks and other basic peripherals, enabling a certain board is not a
big problem, it's mostly just the board .dts bits on top of the SoC.
dtsi. Relatively easy for boards with schematics.
Second: you *contribute* to the efforts, building on the work of others.
Doing this all on your own would be a big effort, and not be
recommended, and be it just to avoid working in the wrong direction.
Third: Honest question, is it really *you*, or is it some LLM? I grew a
bit suspicious lately when it comes to lengthy contributions out of the
blue from "new" people.
> a board series (DTS, defconfig, MAINTAINERS, doc) on top of your A733
work. Before posting it I'd like to settle the base and the boot flow.
With A733/next (165f07a69706), TF-A A733 (f4c0b0dba78a) and sunxi-tools
PR #223, the SPL/FIT flow works here: boot0 trains DRAM, drops into FEL
on "2" over UART, and the SPL loads BL31 and U-Boot. I had to clamp the
SPL's fixed 2 GiB to the board's 1 GiB, and BL31 was linked for DRAM at
0x48000000, which the vendor kernel needed.
Andre's suggestion from January works too: load BL31 and U-Boot proper
directly over FEL, no FIT. I used BL31 at 0x48000000 and U-Boot at
0x4a000000, then reset64 into BL31. The RMR request gets the core to
AArch64 EL3 without an SPL, and the same BL31 and U-Boot binaries reach
the prompt.
Please note that this is all temporary. IIUC, some people already
cracked the DRAM init, within a mainline U-Boot base, which involves
uploading some firmware to the DRAM controller. I haven't seen any code
yet, but I guess it sits tightly on some github.
So we don't need to make those hacks we are using for now pretty, it
just needs to be something usable.
What I am using meanwile:
Have *just* boot0 on an SD card, which automatically drops into FEL, if
it can't find the rest of the firmware. From there I just upload U-Boot
proper and TF-A, maybe the kernel via FEL.
I have masssaged Yixun's patches to just cover U-Boot proper, which
looks much cleaner. I will post that at some point, but it's all a bit
premature without having the SoC .dtsi, which is still waiting for the
clock DT binding headers.
> What's missing there is the RAM size. I couldn't find a usable size
from boot0 in SRAM after entering FEL. Without it U-Boot falls back to
get_ram_size(), whose probe range covers BL31 and goes past the 1 GiB,
so I didn't let it run.
Why not? Probing DRAM is somewhat the idea of that routine, and it
should restore the previous values it overwrote? So have you tried
running that?
As for the rest: as I mentioned above, there is no reason in finding a
proper solution for that problem: we will have proper DRAM init soon
enough, it seems, and then the size will be at the right place in SRAM.
Meanwhile either hardcode it or place a memory node in the DT already.
Cheers,
Andre
I added a "reset64-dram" command to sunxi-tools
on top of #223: the thunk writes the usual SPL header with dram_size at
0x47000 once FEL has handed over, right before the RMR request. U-Boot
reads it as is. The A7Z U-Boot came up that way with 1 GiB from the
header and a working SD card.
The default SRAM BL31 layout clashes with that header. BL31 at 0x62000
has its .bss at 0x46000-0x48400 and clears it at startup, header
included, in the SPL flow as well. I ran that layout on October 7 and
got 1 GiB at the prompt, but didn't trace where the size came from.
Questions:
1. Which base should the A7Z series go on: A733/next, boot-2026.04 or
your next revision? The A7A defconfig differs between them (FIT at
0x4d000000 vs 0x48200000). Would SPL_LOAD_FIT_ADDRESS and
SPL_RAM_DEVICE fit better as SoC defaults?
2. Andre, is direct FEL with an explicit size header something you'd
take as a documented boot path, or do you prefer SPL/FIT?
3. For the size handoff, would you rather keep the header out of the
BL31 SRAM range, or use another interface? I'd also like to replace
the SPL's fixed 2 GiB without a board-specific hack.
Everything ran from RAM on a single board. Linux, secondary CPUs and
UHS are untested with these binaries. If nobody else is on an A7Z port,
I'll send the board series and the sunxi-tools change separately once
we agree on the approach.
Thanks,
Vinicius
