Our FEL code does not deal very well with the upload size being 0.
Check for that before calling any USB routines, and skip the call
entirely. Mark the buffer as "const" on the way, since we have no
business other than reading from it.
That helps to properly skip dummy images later.
Signed-off-by: Andre Przywara <osp@andrep.de>
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 limit the maximum SPL load size to 32 KB, because this
was a BROM limit in previous SoCs.
Newer SoCs (H6 and later) lift this limit, but also this tool is not
bound by the BROM limit, since we can load any size.
Use the just introduced SRAM size to establish an upper limit for the
SPL size, then limit this as we go if any part of the memory is used for
the FEL backup buffers.
Given the buffer addresses chosen wisely, this can drastically increase
the maximum SPL load size, even on those SoCs with a 32KB BROM limit.
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>
At the moment we always use a 32KB offset to place the U-Boot image
after the SPL.
Newer SoCs can (and will) have bigger SPLs, so we need to become more
flexible with this offset.
Read the actual SPL size, and assume the U-Boot payload is located right
behind the SPL, if the SPL size is bigger than 32KB.
We use at least 32KB, because this is how U-Boot is doing it today, even
when the SPL size is actually smaller than that.
Signed-off-by: Andre Przywara <osp@andrep.de>
We have a check to avoid that the SPL accidentally overwrites the thunk
buffer we use to execute code on the board.
Unfortunately this compares the SPL *size* against the thunk *address*,
which is only valid when the SPL starts at 0 (older 32-bit SoCs).
Factor in the SoC dependent SPL start address, to make this check work
properly on newer (64-bit) SoCs.
Signed-off-by: Andre Przywara <osp@andrep.de>
Currently we check the U-Boot (legacy!) image header checksum very early
and bail out with an error message if it does not match.
Move that check later into the function, *after* we have established
that we are actually dealing with such an U-Boot image.
This avoids confusing error messages in case there is no U-Boot image
used at all.
Signed-off-by: Andre Przywara <osp@andrep.de>
The H616 SPI is very similar to the H6, only differs in the GPIOs
(again).
Add the SoC-ID at the right places and add the GPIOs according to the
manual.
Tested on OrangePi Zero 2.
Signed-off-by: Andre Przywara <osp@andrep.de>
The CCU section in all Allwinner manuals asks to de-assert the reset
signal first, then to ungate the bus clock.
On a nearby note it also requires to switch dividers before changing the
clock source.
The SPI flash code violated those two rules, fix this to make the code
more robust.
Signed-off-by: Andre Przywara <osp@andrep.de>
Shifting signed types to the left is dodgy, especially by 31 bits, since
it depends on the result type whether the result is undefined or not.
Do not take any chances here, and mark those shift bases as unsigned where
we can or will hit bit 31, to avoid undefined behaviour.
Signed-off-by: Andre Przywara <osp@andrep.de>
As Icenowy rightfully assumed, the V831 SPI support covers the H6 as
well. The only difference was a slight deviation in the pinmux setup:
the H6 has the SPI0-CS on pin PC5, the V831 on pin PC1.
Just add the right SoC ID and tweak the pinmux setup to enable it.
Tested on a Pine H64.
Signed-off-by: Andre Przywara <osp@andrep.de>
The R40 is closely related to the A20, but has in fact a newer
generation SPI controller.
Add the R40 SoC ID to the right places to enable SPI support.
Tested on a Bananapi M2 Berry with SPI flash attached to header pins.
Signed-off-by: Andre Przywara <osp@andrep.de>
The Allwinner V831 SoC has similar memory map and CCU with H6.
Add support for it by make the code to dynamically acquire the SPI0
memory base and add clock setup for V831.
These code should work on H6 too, but I am too lazy to test it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
V831 SoC is one of sun8i family (with Cortex-A7 CPUs), and it follows a
similar memory map with H6.
Add support for it. The detection for H6-style memory map is positive on
V831, because it have the same version of GIC at the same address.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Add the JEDEC manufacturer ID for Eon to the list of recognized
vendors, also add the EN25QH series to the list of supported chips.
Those chips are used on some internal boards with V831 from Sipeed now,
but the chips themselves are widely available on the market. Tag the
struct definition with the member names on the way to improve readability
of the SPI flash chip description.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
The Allwinner V3s SoC have the same SPI0 pinmux configuration, SPI clock
configuration and SPI controller (base address and the controller) with
H3.
Add spiflash support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Every addition of a new feature to the SPL header currently requires us
to update the FEL tool, to teach it about the new supported maximum
value. Many times the FEL tool doesn't really care, but complains
anyway - and refuses to load.
Let's introduce semantic versioning [1] for this field, where backwards
compatible additions just increase a minor number, but incompatible
changes require bumping the major version.
We have 8 bits for the SPL header version, let's split this to have 3 bits
for the major and 5 bit for the minor version number.
[1] https://semver.org
Signed-off-by: Andre Przywara <osp@andrep.de>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
In the first case:
pio.c: In function ‘main’:
pio.c:355:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
usage(0);
^~~~~~~~
pio.c:356:3: note: here
case 'm':
^~~~
The fallthrough is not intended because `usage()` never returns (it calls
`exit` unconditionally). Annotate as `noreturn` so the compiler realises this.
In the second case:
fexc.c: In function ‘main’:
fexc.c:312:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
filename[1] = argv[optind+1]; /* out */
~~~~~~~~~~~~^~~~~~~~~~~~~~~~
fexc.c:313:2: note: here
case 1:
^~~~
The fallthrough appears to be intended (the two argument case is a superset of
the one argument case). Annotate with a comment which tells the compiler this
is intended.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Add the JEDEC manufacturer ID for Macronix to the list of recognized
vendors, also add the MX25L series to the list of supported chips.
Those chips are used on the OrangePi PC 2 boards, for instance.
Tag the struct definition with the member names on the way to improve
readability of the SPI flash chip description.
Signed-off-by: Andre Przywara <osp@andrep.de>
Using the new AAPCS function remote execution support, add support to
read from and write to SPI flash connected to a device.
This allows flashing boot code to a device.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
[Andre: adjust to upstream changes]
Signed-off-by: Andre Przywara <osp@andrep.de>
