The Allwinner A523 is an SoC with eight Arm Cortex-A55 cores, and some
updated peripherals. The basic IP is very close to other recent SoCs, so
we just have to add the respective flags and base addresses to the new
SoC table, to allow boards with this SoC to run uart0-helloworld-sdboot.
The A523 comes with a GICv3, at a different address, so add this to the
early generation detection code, and let it use the H6 SRAM controller
address for further SoC-ID detection.
Tested on an Avaota A1 board.
Signed-off-by: Andre Przywara <osp@andrep.de>
Our uart0-helloworld-sdboot tools lives in a single source file, so we
don't need to export any functions we use. Nevertheless most functions
were in the past not marked as "static".
Mark the one function that hasn't been touched and updated in the last few
patches as "static", to avoid the compiler exporting them, and to help
it with inlining functions.
Signed-off-by: Andre Przywara <osp@andrep.de>
Now that every SoC specific aspect of our tool is covered by the SoC
table, we don't need the old macros testing for each SoC anymore.
Remove them alongside the no longer needed versions to differentiate
the few SoC variants, which are already covered by a flag in the table.
Signed-off-by: Andre Przywara <osp@andrep.de>
After we have printed our greeting message, the code tries to figure out
from which media the devices has been booted, and prints that
information. When we were booted via FEL, we return there, so further
code can be uploaded.
To access this boot source information, we need to read from offset 0x28
of SRAM A1. The SRAM base address is different between the SoC
generations, so add this address to the table and use it directly.
Signed-off-by: Andre Przywara <osp@andrep.de>
To make the UART signal appear on the SoC pins, we have to select two
pins from the supported output pins and set up their pinmux to connect
to the UART peripheral.
As the name suggests, uart0-helloworld-sdboot always uses UART0, which
is used as a debug UART on most boards, and is also available as a
multiplex on the SD card pins, to be used with a breakout board.
At the moment there is a large if/else cascade, with each branch calling
three GPIO setup functions, with the right arguments for each SoC.
While this is easily extendable with copy&paste, it is very repetetive
and duplicates quite some code.
Use our new SoC table to put the pin number for the TX pin and the
required pinmux value in there, alongside the PIO base address. The RX
pin is so far always the pin after the TX pin, so we just need to store
one pin. We also store a flag marking the PIO IP generation for each
SoC, so we can just differentiate this easily in the GPIO setup
functions.
This also uses the opportunity to get rid of the idea to assign some
names to the pinmux values, when they are just seemingly random SoC
specific numbers. Instead just use a macro name with that number in it,
to make it obvious that this is the mux value, but don't try to put some
deeper meaning into them.
On one SoC we decided to use the SD card pinmux, which is always on pins
PF2 and PF4. Add a flag to allow a SoC to default to those pins.
Also remove the unneeded GPIO functions, and mark the rest of them
as static.
Signed-off-by: Andre Przywara <osp@andrep.de>
To make the UART work, we have to open the clock gate and de-assert the
reset for the UART0 peripheral. This is currently done by calling one of
four functions, even though there are actually only two different ways:
- Older SoCs need to set a bit in the APB1/2 bus clock register, and the
same bit in the respective reset register.
- Newer SoCs combines both the clock and the reset gate in one register,
so it's only one write, setting two bits.
Add a flag to the table to choose between the two methods for each SoC.
The offsets for these clock registers are very stable, but the CCU base
address changed a bit over time, so split this up and put the base address
separately into the table.
For the latest SoCs, the "new" clock structure is combined with an
updated GPIO IP, and the Allwinner BSP calls this SoC generation
"NCAT2". Add a symbolic name for this already, so we can mark those SoCs
now, and add the respective GPIO flag later when this gets added.
Signed-off-by: Andre Przywara <osp@andrep.de>
While the actual UART IP has always been the same across all Allwinner
SoC generations so far, the base address changed a few times recently.
Add a field to the SoC to hold that UART0 base address, and fill the
value in for each SoC. This is then used in the uart0_init() function,
so we can remove the explicit setting in the bases_init() function.
Signed-off-by: Andre Przywara <osp@andrep.de>
At the moment the various SoC specific settings are scattered throughout
the file, using mostly chains of "soc_is_xxx()" macros. While this might
have initially worked with just a few SoCs supported, this is becoming
more and more messy with our currently 22 supported SoCs. Also it is not
easy to support new SoCs, and it looks like some SoCs are already broken
(for instance the A80 is missing the GPIO setup).
The make the code more readable and allow easier addition of future
SoCs, let's add a table, where each entry holds all the various
information we will need to know for each chip: the UART base address,
the clock base address, the clock type, etc. This is conceptually
similar to what sunxi-fel does in soc_info.c.
To make review easier and avoid any regressions, add the table member by
member, and convert the various "subsystems" over one by one.
We start with the most simple table containing the SoC ID and the SoC
name (as a string), and use that already when printing the SoC name.
Since some SoCs share the same SoC ID, add a "flags" member and a in
there a variants bit, and set this accordingly for the four SoCs that
need it.
The soc_detection_init() function gets re-written (and renamed), to
return a pointer into the table, so that the other functions can use the
information there directly.
Signed-off-by: Andre Przywara <osp@andrep.de>
The SRAM controller's version register, which we use to identify a SoC,
is mapped at different locations in the different SoC generations. To find
the right MMIO address, we try to read some GICD_IIDR register, which
tells us which SoC generation we are dealing with.
Looking forward, this will need to be more flexible, as the A80 and A523
will not work with this scheme anymore: the A80 uses a completely
different memory map, and the A523 has a GICv3.
Rework the generation detection to be more flexible and easier to extend:
- First read the MIDR, and check for a Cortex-A8 core. This is the early
generation of SoCs (A10/A10s/A13), which don't have a GIC at all. Use
the legacy SRAM controller address in this case.
- Next check the address of the GIC in the H6 generation ("NCAT"). Its
base address is unmapped at all the other SoCs tested, so this is safe.
- Finally check the GIC address of the "legacy" generation of SoCs
(A20-A64).
- If nothing matches, we are dealing with an unknown SoC, and must stop.
The A80 detection was a nice idea, but didn't work, since the boot
cluster is the one with the A7 cores, so the boot CPU looks like all the
other 32-bit SoCs. Remove that, as the A80 is not supported anyways.
Signed-off-by: Andre Przywara <osp@andrep.de>
Field has 32 bits, not 16, as it is currently handled. This fixes
scratchpad address print when using "sunxi-fel ver" command on A523.
Before it printed "0x1500" and afterwards "0x61500", which makes much
more sense and it was verified by BROM disassembly.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
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>
When reading from the SID device using the normal memory access method,
we upload our "readl" routine (via fel_readl_n()), which expects a number
of *words* to read. However length is given in *bytes*, so we read four
times as much, and overflow our key buffer, clobbering the return address.
This is typically fatal:
===============
$ ./sunxi-fel sid
02c05200:12345678:34567890:76543210
Segmentation fault (core dumped)
$
===============
Fix this by giving the number of (32-bit) words instead. We already
checked that length is a multiple of 4, so we can just divide.
Signed-off-by: Andre Przywara <osp@andrep.de>
As over time we gain support for more and more SoCs, it would be
convenient to know which SoCs a particular build actually supports.
Add a "list-socs" command, that just iterates over the soc_info table
and outputs the SoC ID and the name for each entry.
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>
The new sid-dump command was missing documentation. Add it to the
internal usage() function as well as to the manpage.
Clarify on the existing sid-registers command on the way, and add
a stanza for the wdreset command.
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>
At the moment we have two functions reading the SID eFuses:
fel_get_sid_root_key() to read the "root key" (the first 128 bits), and
fel_get_sid() to read an arbitrary range. The latter does not use the
MMIO register workaround on affected SoCs, while the former only reads
that specific range of bits.
Unify the two functions into one that combines the advantanges of both:
we can read any range of eFuses, and it uses the MMIO register access
method, if needed. Switch the users to use the new function.
Signed-off-by: Andre Przywara <osp@andrep.de>
To workaround a hardware erratum on the H3 SoC, we use an MMIO register
based assembly routine to dump the SID registers, if needed. This is
hard-coded to read the first four 32-bit words of the SID fuses.
For the sid-dump command we need to access any arbitrary regions of the
fuses, so extend the routine to take a start and an end address to dump.
This changes the assembly source in the thunks/ directory:
- We load the start address into r1, instead of zeroing it. The start
address is put right after the SIO MMIO base address, at the end of
the code.
- When storing the read value into the result buffer, we automatically
increase the pointer register (r3), instead of adding the offset
address, since this is now no longer zero based.
- To check for the end, we read the end pointer (stored at the end of
the code, right after the offset), and compare against that instead of
the hardcoded value of 16.
This assembly file was put through the thunks Makefile, and the resulting
content was copied from thunks/sid_read_root.h into fel_lib.c.
For now we are still putting the constant values of 0 and 16 in, but
this time from the C code.
Signed-off-by: Andre Przywara <osp@andrep.de>
The prebuilt blob of uart0-helloworld-sdboot isn't updated for a long
time.
Update it with one built with 5cf618a21605 ("Merge pull request #180
from ChalesYu/a63-220729").
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
The F1C100s series of SoCs has some subtle differences in its UART
setup:
- The UART is at a previously unused address.
- The base clock is not APB2, but APB1.
- The input clock is not 24 MHz, but CPU clock / 2 / 2.
- The clock and reset gates are different bits at different addresses.
Add support for all those differences, tied to the F1C100s SoC ID.
Also change the GCC target architecture for uart0-helloworld-sdboot to
ARMv5, since this is now the oldest support architecture revision.
When the compiler defaulted to ARMv7, it was generating ubfx instructions,
which were only introduced in ARMv6.
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>
Clock and UART wise it's very similar to the V853, but UART0 is only on
pins PE2/3, using pinmux 6, with no other muxes other than PortF.
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 has a GPIO controller with the new register map, a brand
new GPIO base address and the same CCM/UART base address with R329.
Add support for it in uart0-helloworld-sdboot, also as the first SoC
that utilizes GPIO V2.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
GPIO controllers in some new Allwinner SoCs has altered register map.
Add basical support for the new GPIO controller register map.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
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>
On some new Allwinner SoCs, I-Cache is enabled by BROM but FEL write
command cannot correctly invalidate I-Cache, so thunks will not get
properly executed.
Implement a hack that tries to disable I-Cache each time trying to write
data via FEL, to prevent stall thunks in I-Cache.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
The sunxi-boards.git repository has been fixed to address the two
remaining issues in the .fex files there, so we can run our fex compiler
tests on the unpatched repository content.
Remove the patch file, as it is no longer needed and won't apply
anymore anyway on the current sunxi-boards master.
Signed-off-by: Andre Przywara <osp@andrep.de>
The suniv SoCs has a SPI controller like the one in H3, but with base
address like sun4i and no SPI module clock in CCU.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Andre Przywara <osp@andrep.de>
The original fel-remotefunc-spi-data-transfer.h contains code only
suitable for ARMv7+. The F1C100s family is ARM9 (ARMv5TE), so rebuild it:
$ ./fel-remotefunc-compiler.rb fel-remotefunc-spi-data-transfer.{c,h}
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner also has ARM926EJ-S (ARMv5TE) based SoCs.
Consider them when set -march parameter. Also switch to -Os, since we
are more interested in compact code - performance is secondary when doing
mostly MMIO anyway.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
