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 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>
Some bits are not meaningful both in ARMv5 and ARMv7/8, however they're
read as 0 in ARMv5 but 1 in ARMv7/8.
Ignore them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
So far sunxi-fel expects a legacy U-Boot image after the SPL, when
called with the "uboot" command.
This only works for (current) 32-bit builds, which only need one image
to load (U-Boot proper).
64-bit builds also include at least a Trusted Firmware binary, and also
might contain a firmware image for the ARISC management processor. So
we use the more capable FIT image, which can contain multiple images
to load.
Introduce support for that, by adding code to parse a FIT image, find
the image files included, and load them to their respective load
addresses. On the way we keep track of the entry point, that only one of
those images provides, and also note the architecture of this image
(ARMv7 or AArch64).
On top of that we detect which of the images is the actual U-Boot proper
image, and append the chosen DTB to the end of it.
This all mimics the code U-Boot's SPL uses to achieve the same goal when
running from MMC or SPI flash, compare the implementation of
spl_load_simple_fit() in U-Boot's common/spl/spl_fit.c:
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/common/spl/spl_fit.c
This requires the libfdt library for parsing the FIT image (which is in
fact a devicetree blob).
Signed-off-by: Andre Przywara <osp@andrep.de>
In preparation for proper FIT image support, detect a FIT image by
checking its first four byte against the DTB magic.
Report this as not-yet-supported to the user, for now.
Signed-off-by: Andre Przywara <osp@andrep.de>
A while ago the SPL header was extended to hold the name of the DTB file
that shall be used for the board a firmware image is made for.
Add some code to extract that name from the SPL header. This will be
used in later patches to load the proper DTB file.
Signed-off-by: Andre Przywara <osp@andrep.de>
So far FEL was limited to 32-bit payloads only, but this will change.
To accomodate 64-bit entry points, introduce a corresponding flag and
use either the normal FEL execute call or the RMR request to kick off
execution.
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 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>
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>
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>
This patch adds a wrapper script, which can automatically compile
and wrap a small C function, taking care of all the necessary
function arguments marshalling.
The functions 'aw_fel_remotefunc_prepare/aw_fel_remotefunc_execute'
allow using such functions in the sunxi-fel tool to get this code
executed remotely on the device.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
[Andre: adjust to match upstream changes]
Signed-off-by: Andre Przywara <osp@andrep.de>
A U-Boot image has two CRCs, one to cover the data and that we already
check, and one to cover the header.
Since we're not checking the latter, let's make sure it's the case.
Tested-by: Frank Kunz <mailinglists@kunz-im-inter.net>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The current code checks that the transferred size is matching the size
reported in the image header.
Unfortunately, the transferred image might be padded, which doesn't change
anything at the functional level, but will make that check trigger since
the actual image will be smaller than the transferred data.
Change that logic to first check that the transferred size isn't less that
the header image size, which will still be an error, and then check for the
CRC of the image itself. This will prove to be an more robust integrity
check than what we have right now anyway.
The CRC used in the image header is the CRC32 algorithm, that is
implemented in the zlib, which is installed on most devices on the planet,
so we can just use that implementation instead of rolling our own.
Tested-by: Frank Kunz <mailinglists@kunz-im-inter.net>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The U-Boot image parsing code so far has been relying on hardcoded offsets
directly into the image's buffer.
While that works, it's a bit obscure and isn't practical to understand and
modify.
Let's add the structure definition, and convert the code to use it.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The version 2 of SPL added the possibility to add a device tree name in
the header, with adding some pad and using a reserved word.
As FEL boot currently doesn't need the device tree name, directly raise
the maximum supported version number to 2.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
If an SoC has the "secure boot" fuse burned, it will enter FEL mode in
non-secure state, so with the SCR.NS bit set. Since in this mode the
secure/non-secure state restrictions are actually observed, we suffer
from several restrictions:
- No access to the SID information (both via memory mapped and "register").
- No access to secure SRAM (SRAM A2 on H3/A64/H5).
- No access to the secure side of the GIC, so it can't be configured to
be accessible from non-secure world.
- No RMR trigger on ARMv8 cores to bring the core into AArch64.
Those limitations make a board pretty useless for many applications.
However it has been found out that a simple "smc" call will immediately
return from monitor mode, but with the NS bit cleared, so access to all
secure peripherals is suddenly possible.
Add all the necessary support code for doing a runtime check and
activating this workaround. Affected SoCs need to have the "smc"
workaround enabled in their soc_info struct.
Signed-off-by: Andre Przywara <osp@andrep.de>
["sunxi-fel smc" command changed to automatic detection by Siarhei]
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
The patch also introduces a "sid-register" command for diagnostic
purposes. It allows to use/enforce the workaround method for other
SoCs, to check if there are any inconsistencies with the values
read from memory.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
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>
For unknown option-style arguments (starting with '-'), exit after
printing an error message.
This avoids situations where sunxi-fel would not report incorrect
options (with no FEL device attached/detected) and fail with
"Allwinner USB FEL device not found" instead, which is undesirable.
TODO: Might have to eventually migrate this to some better argument
parsing, e.g. getopt(3) or something similar.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
fel:
- Minor review of ARM scratch code
- POSIX conformance: Use nanosleep() instead of deprecated usleep()
README:
- revert Unicode dash to standard ASCII
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
"./sunxi-fel --list" enumerates Allwinner USB devices that
are in FEL mode. For each device detected, the SoC name/ID
and - if available - the SID key will be printed to stdout.
The utility then exits with status code 0 (upon success),
or 1 if no devices were found.
The current implementation treats the list feature as an option,
to be able to handle it *before* the first attempt to call
feldev_open() - which could fail (with no FEL devices connected).
However, a "list" alias is available for users who expect this
to be 'command' syntax, so "./sunxi-fel list" works too.
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 feldev_handle struct returned by feldev_open() will now contain
this additional data, so the main application no longer needs to care
about retrieving that.
aw_fel_get_version() has thus become a static (= 'private') function.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
The FEL utility had accumulated enough (mostly USB-related)
"low-level" code to justify moving that to a separate code unit.
This will allow us to keep better focus on the higher level
functionality in fel.c.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
This moves claiming / releasing the interface into the respective
"open" / "close" functions. The USB code in main() is now trimmed
down to:
feldev_init();
handle = open_fel_device(...);
feldev_done(handle);
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
We move USB endpoint detection into the feldev_claim() routine, so
higher level code is no longer involved with that. Also make use of
the "detached" flag within feldev_handle, instead of relying on an
isolated variable.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
This enables us to move forward to a cleaner implementation,
where the "core" fel.c code will become independent of direct
libusb usage. After moving USB code to a separate module,
in the end the libusb handle could become an 'opaque' field of
feldev_handle.
The "device" handle might also be extended later, to provide
(FEL) version data and SoC-specific information (chip ID, SRAM
info, human-readable name).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
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>
These functions solve the problem that large readl/writel
transfers might be limited by insufficient (scratch) buffer
size. To solve this, chunks of no more than LCODE_MAX_WORDS
get transferred individually.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
This patch reduces on FEL protocol overhead for the 'multiple'
readl/writel transfers (functions that do word-aligned memory
access on the SoC). The ARM "scratch" code now takes a word count
and is able to work with buffered data, so the host is no longer
required to transfer single words in a piecemeal fashion.
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>
The previous timeout of 60 seconds was mostly based on scenarios
where large ("write") transfers take place. But it could easily
become annoying if users are awaiting completion of simpler
commands like "read" or "hexdump", and for some reason FEL fails
to respond.
Therefore I've decided to lower the timeout value to 10 seconds,
adjust the maximum chunk size accordingly and - while at it -
improve the source comments documenting their relationship.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
For Windows portable_endian.h relies on and includes <winsock2.h>.
Thus it needs to be requested first, otherwise other includes might
pull in <windows.h> and cause a preprocessor warning / compilation
failure (observed with MinGW).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
