GitLab

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>

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

This commit renames the function pointer of type progress_cb_t
for file_upload(). That might help to avoid potential confusion
with other routines that use a boolean "progress" parameter to
indicate whether progress information is desired (at all).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Until now, the function would always pass `true` as the "progress"
parameter to aw_write_buffer(). This has the potential drawback
of limiting the maximum USB transfer size.

By selectively passing `false` instead (with no progress function
active), we hint that aw_write_buffer() and subsequent routines
don't have to care about callbacks; so that usb_bulk_send() is
free to select a transfer size of AW_USB_MAX_BULK_SEND.
Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>

This way we don't have to introduce new options for retrieving
version info. For those programs that do not output their usage
by default (e.g. because they would process stdin), you may pass
a "-?" option to get help - and thus version information.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

* fel: Add the ability to pass uEnv-style data via FEL

The corresponding format is recognized by having the environment
data (= text) start with a special "#=uEnv" marker. Upon transfer
of such a file, sunxi-fel will detect this condition, and set a
field in the SPL header accordingly - which in turn also requests
U-Boot to auto-import it (i.e. merge with the default environment).

(Note that this requires a U-Boot version that knows about the
new meaning of this field, namely v2016.09 or later. Older U-Boot
versions will fail to import the uEnv-style data.)
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

This commit adds a new "reset64 <addr>" command "rmr32" that could
be helpful with new 64-bit SoCs. It takes an entry point (address)
parameter, stores it via RVBAR and then issues a RMR write to
request a warm boot into AArch64 mode.

For now, this is useful with the boot process of A64, where we might
wish to transfer control to a 64-bit binary (for ATF or U-Boot).
See e.g. http://linux-sunxi.org/Pine64#Boot_sequence

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

The SCTLR bits are somewhat different because the V bit is set
to 0 on A64 (Low exception vectors, base address 0x00000000) and
the UNK bit (Reads of this bit return an UNKNOWN value) is also not
the same as on the other SoCs. So the SCTLR check can be relaxed.

Changes in v2:
 - Because the SRAM A and SRAM C reside back-to-back in the address
   space, it is possible to use 40 KiB of SRAM by the SPL for its
   code+data+stack. So the FEL backup storage is moved from 0x18000
   to 0x1A000 to support this.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

This allows the SRAM section A2 to be exclusively used by
the OpenRISC core.

There are no substantial differences between H3 and A10/A13/A20.
It just has 64 KiB of SRAM starting at the address 0x0 instead
of 48 KiB.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

This allows the SRAM section A2 to be exclusively used by
the OpenRISC core.

Regarding the potential U-Boot SPL size. The SRAM section A1
only has 32 KiB. But at least the stack can be set at the end
of the SRAM section B. Or runtime UCL or LZO decompression can
be used to unpack the SPL code to 0x24000-0x2FFFF and have
48 KiB of available space there.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>

That would be a more appropriate name. And A31 is going to
implement this in a different way and give the SRAM back to
OpenRISC.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Previously the backup area was allocated at the address 0x8000.
This is not very good because it means that the U-Boot SPL can
only safely use memory at addresses 0x0000-0x7FFF (32 KiB). But
if we move the backup area to the end of the SRAM A4, this can
allow U-Boot SPL to use memory 0x0000-0x9FFF (40 KiB). The BROM
can't load such large SPLs from the SD card. But the SPL still
can move its stack up to the 40 KiB boundary or do UCL or LZO
decompression at runtime to squeeze more code into it.

This patch makes the sunxi-fel tool compatible with 40 KiB SPLs,
even though the current U-Boot releases do not use them yet.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Bernhard Nortmann <bernhard.nortmann@web.de>