GitLab

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 watchdog register isn't in the same place, nor uses the same values
to trigger a reset.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>

The watchdog register isn't in the same place, nor uses the same values
to trigger a reset.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>

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>

Closes #96
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

This also obsoletes fel-copy.c - for details see issue #78.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

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>

Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

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>

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>

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>

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-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>