Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fel: add Allwinner A523 SoC support #202

Merged
merged 1 commit into from
Nov 21, 2023

Conversation

apritzel
Copy link
Contributor

The Allwinner A523 has 128KiB of MCU0 SRAM, which the BootROM will not touch. The BROM will use some memory in SRAM A2, which it also clears upon entering FEL mode, starting from address 0x44000. The lowest allocation seems to be the IRQ stack growing down from 0x45400. So we won't touch any of that memory, but can freely use the full 128KB of the primary SRAM for payloads. This means we won't need to swap any buffers for preserving BROM stacks.
We put the SPL thunk code just below 0x44000, to leave as much SRAM for the payload as possible.
The rest of the SoC is pretty standard, although the watchdogs are now in separate MMIO frames, not part of some timer block anymore.

The secure boot mode will prevent even reading the BootROM, so we can use an address in there to test for the secure boot state. However, even though a simple "smc #0" will return to its caller, the NS bit is still set, so we are still in non-secure state afterwards. So leave this bit out for now until we figure out how to switch to secure state properly.

The Allwinner A523 has 128KiB of MCU0 SRAM, which the BootROM will not
touch. The BROM will use some memory in SRAM A2, which it also clears
upon entering FEL mode, starting from address 0x44000. The lowest
allocation seems to be the IRQ stack growing down from 0x45400.
So we won't touch any of that memory, but can freely use the full 128KB
of the primary SRAM for payloads. This means we won't need to swap any
buffers for preserving BROM stacks.
We put the SPL thunk code just below 0x44000, to leave as much SRAM for
the payload as possible.
The rest of the SoC is pretty standard, although the watchdogs are now
in separate MMIO frames, not part of some timer block anymore.

The secure boot mode will prevent even reading the BootROM, so we can
use an address in there to test for the secure boot state. However, even
though a simple "smc #0" will return to its caller, the NS bit is still
set, so we are still in non-secure state afterwards. So leave this bit
out for now until we figure out how to switch to secure state properly.

Signed-off-by: Andre Przywara <osp@andrep.de>
@paulkocialkowski
Copy link
Member

Great, thanks for looking into it! Seems like an interesting new platform (finally). Have you seen some actual board with it (not a tablet)?

@paulkocialkowski paulkocialkowski merged commit 34573bf into linux-sunxi:master Nov 21, 2023
1 check passed
@apritzel
Copy link
Contributor Author

Hi @paulkocialkowski many thanks for having a look and merging it!
If you google for "Avaota Router" (and correct Google that you really didn't mean Avatar!) you will find some board from Yuzuki, which is in the making. That looks pretty cool, though with a PCIe switch and two PCIe NICs probably not on the cheap side. She recently added some sibling SoCs (sharing the same die) to the Wiki, I think the A527 with HDMI and the T527 with 2 GMACs are even more interesting. We'll see, but I am hopeful someone picks this SoC up. I have mainline Linux and U-Boot patches halfway done, though am blocked because of FEL not allowing me to escape non-secure, for now :-(

@paulkocialkowski
Copy link
Member

Very nice find! I see you are spending much more time than I am looking for new Allwinner hardware.
A527 does sound quite interesting and it will be good for the sunxi community to have new hardware to play with.
Do you have any leads on DRAM init?

I've seen that aodzip has done some work on A133 DRAM init so I'm considering getting one of those (no community hardware is available though). And lack of HDMI is a major drawback for general-purpose use cases too.

@apritzel
Copy link
Contributor Author

I have an A133 tablet, and have opened it to get access to the UART pins and a FEL pin. And I get it into FEL, and can run code and see output on the UART. However it's stuck in non-secure state as well, even though I can access SRAM A2, so I doubt it's using secure boot. I cannot boot from SD card though, so I am a bit stuck on there. It's a lower hanging fruit, upstream-wise, since the basics are in for a while now (the A100 is reportedly just a lower bin of the A133), and I have already rebased the second bunch of patches that were already on the list back then. But without secure state to reset into AArch64 it's a bit of a lost cause :-(
If you are after some A133 hardware, there is the Liontron A133 devboard, which looks well equipped and very accessible. They offer versions with up to 4GB DRAM, and it's not too expensive (25-55 EUR on Aliexpress, for instance).

@apritzel
Copy link
Contributor Author

apritzel commented Nov 23, 2023

oh, forgot:

Do you have any leads on DRAM init?

Well, I extracted the boot0 from a recovery image, so I guess it's just a question of diligence and persistence to get this reverse engineered (or get @jernejsk interested ;-). In the past I managed to hack the vendor boot0 to return to FEL after DRAM init, so this code can be used to unblock further development, and get U-Boot proper and Linux to boot.
That tablet has LPDDR3 (despite the adverts saying LPDDR4X), so at least no new DRAM types there.

@parthitce parthitce mentioned this pull request Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants