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>
