- 12 Jan, 2021 1 commit
-
-
Andre Przywara authored
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>
-
- 11 Jan, 2021 3 commits
-
-
Andre Przywara authored
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>
-
Andre Przywara authored
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>
-
Andre Przywara authored
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>
-
- 31 Dec, 2020 1 commit
-
-
Andre Przywara authored
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>
-
- 29 Dec, 2020 3 commits
-
-
Andre Przywara authored
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>
-
Andre Przywara authored
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>
-
Andre Przywara authored
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>
-
- 14 Jun, 2020 1 commit
-
-
Karl Palsson authored
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>
-
- 20 Apr, 2020 1 commit
-
-
Karl Palsson authored
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>
-
- 02 Dec, 2018 1 commit
-
-
Andre Przywara authored
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>
-
- 09 Jul, 2018 2 commits
-
-
Siarhei Siamashka authored
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>
-
Siarhei Siamashka authored
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>
-
- 06 Nov, 2017 3 commits
-
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
- 29 Apr, 2017 1 commit
-
-
Icenowy Zheng authored
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>
-
- 28 Feb, 2017 1 commit
-
-
Andre Przywara authored
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>
-
- 13 Feb, 2017 1 commit
-
-
Bernhard Nortmann authored
Closes #96 Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
- 11 Feb, 2017 1 commit
-
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
- 27 Jan, 2017 1 commit
-
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
- 28 Dec, 2016 4 commits
-
-
Bernhard Nortmann authored
This also obsoletes fel-copy.c - for details see issue #78. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Bernhard Nortmann authored
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>
-
Icenowy Zheng authored
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>
-
Bernhard Nortmann authored
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>
-
- 13 Dec, 2016 1 commit
-
-
Bernhard Nortmann authored
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>
-
- 07 Dec, 2016 2 commits
-
-
Bernhard Nortmann authored
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>
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
- 01 Dec, 2016 2 commits
-
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Bernhard Nortmann authored
"./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>
-
- 29 Nov, 2016 9 commits
-
-
Bernhard Nortmann authored
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>
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Bernhard Nortmann authored
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>
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Bernhard Nortmann authored
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>
-
Bernhard Nortmann authored
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>
-
Bernhard Nortmann authored
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>
-
Bernhard Nortmann authored
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>
-
Chen-Yu Tsai authored
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>
-
- 19 Nov, 2016 1 commit
-
-
Bernhard Nortmann authored
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>
-