The Allwinner A133 is a slightly older SoC (around 2020) with four
Cortex-A53 cores, sharing many treats with the H6.
The A100 and R818 are reportedly the same chip, just in different bins
or packaging.
The chip has only 16K of SRAM-A1, but this is immediately followed by
128K of SRAM-C, with later 64K of SRAM-A2, after some gap.
The BootROM SRAM usage is similar to other SoCs: there is the IRQ stack
growing down from a 5K offset in SRAM A1, and probably some buffers
located towards the end of SRAM C. We can use the area just before those
buffers for the IRQ stack backup, which gives us a nice contiguous 128K
SRAM area for any payloads.
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: Andre Przywara <osp@andrep.de>
The SRAM situation on the A523 family of SoCs is a bit more involved:
while there is indeed a large 128KB SRAM region at offset 0x20000, this
is labeled as "MCU0 SRAM" and is apparently switchable, to the RISC-V
MCU. It is unclear at this point whether the MCU will take posession of
this region at some point, and whether it might not be available when
rebooting or doing some suspend/resume operations. The BootROM doesn't
use this SRAM, and actually loads the initial boot0/SPL payload from MMC
to 0x44000, so at an 16K offset into SRAM A2.
To keep the SPL compatible between MMC/SPI and FEL loads (we cannot be
position independent), move the SPL address to this 0x44000.
This means we do need a swap buffer, since the FEL stack is right on
early in this region. The region after 0x5c000 seem to be used by the
BROM, so we cannot use that for buffers, without further limiting the
FEL payload. To leave the MCU0 SRAM alone, put those buffers in the 16K
*before* the new SPL load address. Since U-Boot will use 0x44000 for the
initial SPL stack, put the thunk buffer at the beginning, where it should
not be overwritten. The scratch address goes at the usual 4K offset of
the SPL address, where it is located just before the FEL stack.
Signed-off-by: Andre Przywara <osp@andrep.de>
The Allwinner A523 BROM sets the SCTLR.I bit, to enable the I-cache when
running the FEL BROM code. To avoid the required cache maintenance when
uploading and executing code, just flag the SoC with our .icache_fix
bit, so turn the .I bit off as early as possible.
This fixes more advanced sunxi-fel routines like readl/writel and the
"spl" command on the A523.
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner T7 share the same CCM/UART base address with H6.
Add support for it in uart0-helloworld-sdboot.
Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
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>
At the moment we can search for a specific SoC in our supported SoC
table by looking for its SoC ID, but we cannot otherwise enumerate all
supported SoCs.
Add a get_next_soc() function that allows iterating over our (internal)
table: The first call will take NULL as an argument, subsequent calls
pass in the pointer returned by the previous call. When we reach the end
of the list, the function returns NULL.
Signed-off-by: Andre Przywara <osp@andrep.de>
The Allwinner H616 ships in at least two die variants, sometime under a
different name (H618, T507), but sometimes labeled as a normal "H616".
The die variants differ in their CPU cluster control subsystem, which
affects the location of the RVBAR shadow register used to reset the core
into 64-bit mode. We use that in the "reset64" command, but also as part
of the boot process using the "uboot" command, on ARMv8 cores.
Add code to detect the die variant by reading the VER_REG MMIO register,
where the original die reports 0x00 in the lower 8 bits, but the newer
die variants apparently 0x02. In the latter case let the aw_rmr_request()
function use the alternative RVBAR address to do the 64-bit switch.
This matches what we do in U-Boot and Trusted Firmware.
Signed-off-by: Andre Przywara <osp@andrep.de>
The generic_2k_sid_maps, describing the SID sections for chips where we
don't have any specific information yet, was missing the terminating
NULL section, so we would run off into to woods, beyond the array limit.
This would most commonly result in a segfault:
$ sunxi-fel sid-dump
....
00000000 00000000 00000000 00000000
Segmentation fault (core dumped)
=================
Add the NULL sentinel to terminate the loop correctly.
Signed-off-by: Andre Przywara <osp@andrep.de>
At the moment we only have a SID map for the R40. Add a generic
placeholder map, covering the 2048 bits that most SoCs have (at least).
The linux-sunxi Wiki page [1] for the SID register layout describes
entries for the H6 and "SoCs before H6". Add those tables as well, and
use the latter one for some SoCs which were released the closest to the
H6 (H3, A64, H5).
If people have more information, more specific maps can be added.
[1] https://linux-sunxi.org/SID_Register_Guide#eFUSE_Region_Overview
Signed-off-by: Andre Przywara <osp@andrep.de>
The V5 is (yet another) example of a more recent SoC with A7 cores, so
it goes with the H6 memory map and peripherals, but with 32-bit cores.
Add basic support, to facilitate development.
Signed-off-by: Andre Przywara <osp@andrep.de>
This SoC is using the same die as the RISC-V D1, but we don't support
non-ARM yet. The memory map and peripherals (watchdog) are very similar
to the V853, also the BROM enabled the instruction cache, so requires
the same I cache hack.
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner V853 is a new SoC from Allwinner that has I-Cache enabled
(thus broken FEL write-and-execute) in BROM.
Add support for it.
The SRAM infomation was gathered by reverse engineering its BROM and
checking its SRAM usage, confirmed by the manual.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
[Andre: fix watchdog]
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner F1C100s is one of the new ARM9 SoCs produced by Allwinner.
Add support for it in FEL.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner R329 has no SRAM A1, but a huge SRAM A2 that is partly
utilized as boot time SRAM.
Add basical support for it. The spl subcommand is tested with modified
uart0-helloworld-sdboot and extracted original boot0.
Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
The A64 and H5 have a rather generous SRAM C directly adjacent to
SRAM A1, so we can make use of the larger continuous SRAM area to
increase the maximum SPL size.
Move the location of the FEL stack backup buffer up, towards the end of
SRAM C. We restrict ourselves to the slightly tighter requirements of
the H5, to be able to still share the joint swap_buffers data structure.
Signed-off-by: Andre Przywara <osp@andrep.de>
The H6 has quite a large chunk of continuous SRAM, and also the BROM
allows to load eGON images far bigger than 32KB.
Move the FEL stack backup buffers and the thunk address towards the end
of SRAM C, so that we have a larger chunk of continuous SRAM available
for the SPL.
Signed-off-by: Andre Przywara <osp@andrep.de>
The H616 has quite a large chunk of continuous SRAM, and also the BROM
allows to load eGON images far bigger than 32KB. U-Boot's SPL is
actually relying on this, as we need more code for the PMIC and DRAM
driver.
Move the FEL stack backup buffers and the thunk address towards the end
of SRAM C, so that we have a larger chunk of continuous SRAM available
for the SPL.
Signed-off-by: Andre Przywara <osp@andrep.de>
At the moment we assume the SPL load size to be limited to 32KB, even
though many SoCs have more SRAM A1 or a large SRAM C directly after SRAM
A1.
To later allow to extend the SPL load size, let's introduce a SoC
specific variable to hold the SRAM size after the SPL load address. This
could either cover the whole of SRAM A1, or even SRAM C, if that is
contiguous to SRAM A1.
Eventually this variable is meant to hold the *usable* SRAM size, so not
including regions that are used by the BROM code. However this value is
very SoC specific and not documented, and the SPL size is limited by the
thunk and stack buffers anyway at the moment, so the values used here
right now are just taken from the respective manuals.
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner H6 is a new SoC with its memory map changed.
Add its SoC info, including SRAM addresses and SID address.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
As per the wiki[1] set ttbr0 to 0x44000 to enable the MMU. Transfer
speed is increased from 191KB/s to ~800KB/s which is handy when
transferring larger kernels and root filesystems.
Tested on a custom H8/A83T board.
[1] https://linux-sunxi.org/FEL/USBBoot
Use a hardwired L.NOP instruction from the OpenRISC reset
vector as a way to check if the workaround is necessary.
Because these L.NOP instructions are guaranteed to be there
and are read-only, this is the most reliable non-invasive test.
Reading SID would be less reliable because it is one-time
programmable and theoretically may be set to zero on some boards.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
H3 SID controller has some bug, that makes the initial value at
0x01c14200 wrong.
This commit workarounds this bug by reading them with register access
first.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>
This is a preparatory step. Instead of using memory-based access,
we might want to retrieve SID keys (e-fuses) via SID registers.
For this, it's convenient if the plain base address is available.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
open_fel_device() will automatically provide this member field,
based on the SoC ID from FEL/BROM version data. The field will
either receive a human-readable identifier, or the ID in 4-digit
hexadecimal representation (for unknown SoCs).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
The SID block in the A80 is at 0x01c0e000, with the e-fuses we care
about at offset 0x200 within the block.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The R40 is marketed as the successor to the A20. The SRAM layout is the
same as the A20, but there doesn't seem to be a secure SRAM block.
The SID block is at a completely different address. The layout is the
same as the newer SoCs, with the e-fuses at an offset of 0x200.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Besides having fewer lines of code, the #define macros should
also prevent users from accidentally using these names without
braces (i.e. as function pointers). Instead, this will cause
compiler errors now.
soc_info.c: add "A10s" label in comment for SoC ID 0x1625.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
While at it, modify the former "sram_info" identifiers
to carry a broader "soc_info" meaning.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
