On Fri, 2026-10-09 at 16:34 +0200, Andre Przywara wrote:
> 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.
>
FYI, I've got the TF-A patches in-flight for A733 atm, and have a working
U-Boot for the Orange Pi 4 Pro (A733 LPDDR5 here):
https://github.com/InfernoEmbedded/u-boot/commits/upstream-v1-core-bringup/
There is a gotcha though, I'm not submitting that branch as-is, as the PMU
firmware was reverse engineered, and not in a clean-room fashion, so I'm
not comfortable putting that forwards.
I'm currently working on a clean-room reimplementation (and keeping a
provenance log) which I will submit soon.
Now, I only have hardware on hand for LPDDR5, so I can't really validate
DDR4 PMU firmware, so I was not planning on putting that forwards in the first
pass. I would be very grateful to have someone help ensure the PMU firmware
can successfully bring up a DDR4 board.
Cheers,
--
Alastair D'Silva
