Add FEL support for Allwinner SoC A733 #223

dlan17 · 2025-08-14T11:32:53Z

the PR tries to add FEL support for A733, tested on Radxa Cubie A7A board
it's capable of booting uboot spl image..

still need some help to check if the commit message is accurate..

the spl_address is coded to 0x52000, as in my case I've tried, the <0x51000 isn't working..

Icenowy · 2025-08-14T13:35:22Z

Is the WIP U-Boot port available anywhere?

Icenowy · 2025-08-14T13:35:31Z

And is there any BROM dump of this SoC?

dlan17 · 2025-08-14T13:56:51Z

Is the WIP U-Boot port available anywhere?

have a local repo, but not sorted out yet,
the main challenge is to bring up DDR..

dlan17 · 2025-08-14T13:58:24Z

And is there any BROM dump of this SoC?

no idea of what's the aim to do the dump, not really needed of this from my side..

apritzel

Thanks for posting this. I guess we need to adjust some addresses, to be able to later load the same mainline SPL as used on an SD card.

apritzel · 2025-08-15T13:23:02Z

soc_info.c

 };
+
+sram_swap_buffers a733_sram_swap_buffers[] = {
+	{ .buf1 = 0x48800, .buf2 = 0x72000, .size = 0x0400 },


Can you double check that the area at 0x72000 is not used by the BROM?
Try to write something to that area, using "sunxi-fel write", then try to read it back (using the "read") command. This should work without using the swap buffers, and this way you can check if the BROM uses that area. Feel free to poke around nearby, it would be good if you could actually find something that the BROM changes, and the confirm that it's NOT between 0x72000 and 0x72400.
Another way would be to dump the BootROM, then check the disassembly for addresses used for buffers and stack.

Can you double check that the area at 0x72000 is not used by the BROM? Try to write something to that area, using "sunxi-fel write", then try to read it back (using the "read") command. This should work without using the swap buffers, and this way you can check if the BROM uses that area. Feel free to poke around nearby, it would be good if you could actually find something that the BROM changes, and the confirm that it's NOT between 0x72000 and 0x72400. Another way would be to dump the BootROM, then check the disassembly for addresses used for buffers and stack.

I've done a "write then read back" test with sunxi-fel, and found 0x46E00 - 0x48C00 is the space that we can't write (touched it will corrupt FEL) and should be preserved, so I will use it as swap_buffer

This (the space that we can't write) is the space that needs to be backed up (buf1 here) instead of the used swap buffer (buf2).

If any higher SRAM is available, then buf2 should be as high as possible.

apritzel · 2025-08-15T13:26:03Z

soc_info.c

+	},{
+		.soc_id       = 0x1903, /* Allwinner A733 */
+		.name         = "A733",
+		.spl_addr     = 0x52000,


So this should be 0x47000, to match the load address used by the BROM when loading from SD cards (and other boot media). Making this the same is crucial to be able to use the same SPL binary for FEL and boot media, since we need a fixed link address for the SPL (since we cannot use PIE).
And we should double check that it's really 0x47000, and not 0x44000. Again the BROM disassembly would help.

So this should be 0x47000, to match the load address used by the BROM when loading from SD cards (and other boot media). Making this the same is crucial to be able to use the same SPL binary for FEL and boot media, since we need a fixed link address for the SPL (since we cannot use PIE). And we should double check that it's really 0x47000, and not 0x44000. Again the BROM disassembly would help.

agree, I will use 0x47000

in my test, both 0x44000 and 0x47000 works fine, address 0x44000 will give more space, but downside is that we have to maintain two different value for FEL and booting from SD, so will leave it for now

Sure, most addresses will work in FEL, but please note that SD card compatibility is a hard requirement, not a "nice to have": we will only support one image, for FEL, SD card, eMMC and SPI booting.
And the "more space" is quite theoretical, we will probably not need more than say 64KB. For the A523, we are at 37KB at the moment, which leaves us quite some room, even for the probably higher DRAM setup demand of the A733.
So, what is your CONFIG_SUNXI_SRAM_ADDRESS in U-Boot, and does that work from an SD card? Just use the working version of this address.

So, what is your CONFIG_SUNXI_SRAM_ADDRESS in U-Boot, and does that work from an SD card? Just use the working version of this address.

Currently it's CONFIG_SUNXI_SRAM_ADDRESS=0, but while checking the code, it should be CONFIG_SUNXI_SRAM_ADDRESS=0x47000 for case A733?

for FEL mode, it seems doesn't matter of what the CONFIG_SUNXI_SRAM_ADDRESS is, or guess I'm only booting directly from ram.. but SD boot case, due to lacking of DDR initialization, I'm not able to fully test the SD boot procedure.. only got this log

U-Boot SPL 2025.10-rc1-00134-gc107a6ec79aa (Aug 27 2025 - 10:53:03 +0000) DRAM: 1024 MiB

then stuck, due to even in SPL stage it will utilize DDR memory space..

apritzel · 2025-08-15T13:30:07Z

soc_info.c

+		.soc_id       = 0x1903, /* Allwinner A733 */
+		.name         = "A733",
+		.spl_addr     = 0x52000,
+		.scratch_addr = 0x54000,


And I guess we should adjust this as well, to be 4096 bytes after the spl address.

And I guess we should adjust this as well, to be 4096 bytes after the spl address.

for spl_addr = 0x47000, then scratch_addr is 0x48000, which < 0x48C00, so it doesn't work..

I would pick 0x71000 if no objection, since it's a temp address for running code

apritzel · 2025-08-15T13:33:10Z

A BootROM dump would indeed be very helpful to confirm the various addresses used, for instance the SD card load address, the stack locations, and where any BROM buffers are. You can try to submit them to https://github.com/smaeul/sunxi-blobs, so that we have them on record for the future

apritzel · 2025-08-15T13:35:21Z

uart0-helloworld-sdboot.c

-		set_wbit(soc->ccu_base + 0x90c,
+		int reg_ofs;
+
+		reg_ofs = (soc->soc_id == 0x1903) ? 0xe00 : 0x90c;


Please use a new flag for the clock, like FLAG_A733_CLOCK. You can combine this with the other new flag to FLAG_NCAT3 or so.

apritzel · 2025-08-15T13:37:36Z

uart0-helloworld-sdboot.c

+		int reg_ofs;
+
+		reg_ofs = (soc->soc_id == 0x1903) ? 0xe00 : 0x90c;
+		set_wbit(soc->ccu_base + reg_ofs,


Please note that each UART has its own BGR register now. So I suggest something like:

if (soc->flags & FLAG_NCAT3_CLOCK) { set_wbit(soc->ccu_base + 0xe000 + uart_index * 4, 0x10001); } else if (soc->flags ^ FLAG_NCAT2_CLOCK) { ....

apritzel · 2025-08-15T13:38:29Z

uart0-helloworld-sdboot.c

 		pio_dat_off = 0x10;
 		pio_pull_off = 0x24;
+	} else if (soc->flags & FLAG_A733_GPIO) {
+		pio_bank_size = 0x80;


You also need an offset value, as you figured below, as on the A733, the bank A registers start at 0x80, not 0x0 as before. Either you add a new pio_bank_a_offset variable, and set this 0x80 here, or you adjust pio_base in here, directly.

apritzel · 2025-08-15T13:42:25Z

uart0-helloworld-sdboot.c

+	 * Adjust pio_base offset by shift size 0x80, as
+	 * PB bank start at 0x100 with the bank size 0x80
+	 */
+	if (soc->soc_id == 0x1903)


Please no SoC specific hacks, we now have the flags to take of this properly, so that it can be reused later on. I guess this won't be the last SoC using this pinctrl layout. See above for a better solution.

dlan17 · 2025-08-25T13:44:55Z

A BootROM dump would indeed be very helpful to confirm the various addresses used, for instance the SD card load address, the stack locations, and where any BROM buffers are. You can try to submit them to https://github.com/smaeul/sunxi-blobs, so that we have them on record for the future

I'm not familiar with this, I'd appreciate if someone else would do this..

The Allwinner A733 is built on a 12nm process and features a dual-core ARM Cortex-A76 combined with a hexa-core ARM Cortex-A55 using the big.LITTLE architecture. The chip has 16K + 192K of SRAM-A2, with first 16K used only by CPUS domain, later it follows by 512K of SHARED-SRAM with no gaps. SRAM_A2 0x40000 - 0x73FFF SHARED_SRAM 0x74000 - 0xF3FFF The BootROM SRAM usage is similar to other SoCs: there is the IRQ stack growing down from around 34K offset in SRAM-A2, and probably some buffers located towards the end of the SRAM. In this setup, we've only tried to use the 192K block of SRAM-A2, which should be enough for SPL setup. It's possible to use more SRAM, for example, the SHARED-SRAM, but we leave it for now. This setup is known to boot the WIP mainline U-Boot setup, including some placeholder TF-A port for now. SPL execution, including returning back to the BROM, works, also the 64-bit switch, as well as the SID dump. Signed-off-by: Yixun Lan <[email protected]>

Icenowy · 2025-08-25T14:15:40Z

At least N-BROM should be easy to dump -- just use sunxi-fel read functionality to dump the memory zone of BROM according to the manual.

Icenowy · 2025-08-25T14:24:12Z

Looks like the branch is still quite broken -- sunxi-fel read on BROM does not work at all (while sunxi-fel readl can read individual words from BROM)

Enable UART's pinctrl and clock settings. The clock and pio offset for UART controller is changed in A733. Signed-off-by: Yixun Lan <[email protected]>

dlan17 · 2025-08-25T14:51:11Z

Looks like the branch is still quite broken -- sunxi-fel read on BROM does not work at all (while sunxi-fel readl can read individual words from BROM)

$ ./sunxi-fel read 0x17000 0x200 dump.bin
usb_bulk_recv() ERROR -7: Operation timed out

it seems these address space aren't readable? I have no idea why..

Icenowy · 2025-08-25T14:59:35Z

smaeul/sunxi-blobs#5

BROM dumps here (HS-BROM seems to be not available now).

Maybe I should try to do some trick like what @apritzel does on A523, on my Teclast tablet, to retrieve the secure part.

apritzel · 2025-08-30T00:21:36Z

Thanks @Icenowy for the BROM dump! That looks like the usual BootROM setup procedure, with all the hotplug checks, and including setting the ACTLR.SMP bit that isn't there anymore on the A55. Oh well ....
Normal stack is at 0xf3400 (towards the end of the NPU SRAM aka "SHARED_SRAM), IRQ stack is at 0x48c00.

0x46E00 - 0x48C00 is the space that we can't write

Are you sure it's that large? Typically the IRQ stack usage is pretty small, like at most 1KB (0x400), which would mean we just need to save/restore from 0x48800-0x48c00.
I wonder if we can use the area before the SPL load address for thunk and scratch? So 0x44000 and 0x45000 or so?
I will continue wading through the BROM disassembly, to see if I can find some buffer addresses somewhere, or if it touches more in the lower SRAM area.

dlan17 · 2025-08-30T01:02:01Z

Are you sure it's that large? Typically the IRQ stack usage is pretty small, like at most 1KB (0x400), which would mean we just need to save/restore from 0x48800-0x48c00.

Yes, it's my actual test result, just boot straight into FEL mode (without SD or eMMC), then I did something like this a) "fel write 512bytes" b) "fel read back 512bytes" c) do m5sum to compare

for 0x46e00, it's fail at stage a - fel write

for the large buffer, is the space used by anything else than IRQ stack, like FEL/usb buffer? or maybe simply access forbidden?

I wonder if we can use the area before the SPL load address for thunk and scratch? So 0x44000 and 0x45000 or so?

I think it's possible, but haven't tested, I will try it some day and will let you know..

apritzel requested changes Aug 15, 2025

View reviewed changes

uart0-helloworld-sdboot: add support for Allwinner A733

5d99673

Enable UART's pinctrl and clock settings. The clock and pio offset for UART controller is changed in A733. Signed-off-by: Yixun Lan <[email protected]>

dlan17 force-pushed the A733 branch from 93c733c to 5d99673 Compare August 25, 2025 14:43

Uh oh!

Add FEL support for Allwinner SoC A733 #223

Are you sure you want to change the base?

Add FEL support for Allwinner SoC A733 #223

Uh oh!

Conversation

dlan17 commented Aug 14, 2025

Uh oh!

Icenowy commented Aug 14, 2025

Uh oh!

Icenowy commented Aug 14, 2025

Uh oh!

dlan17 commented Aug 14, 2025

Uh oh!

dlan17 commented Aug 14, 2025

Uh oh!

apritzel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlan17 Aug 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apritzel commented Aug 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlan17 commented Aug 25, 2025

Uh oh!

Icenowy commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Icenowy commented Aug 25, 2025

Uh oh!

dlan17 commented Aug 25, 2025

Uh oh!

Icenowy commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

apritzel commented Aug 30, 2025

Uh oh!

dlan17 commented Aug 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dlan17 Aug 27, 2025 •

edited

Loading

Icenowy commented Aug 25, 2025 •

edited

Loading

Icenowy commented Aug 25, 2025 •

edited

Loading