GitLab

A patch to extend the "fel spl" command to properly handle not only the SPL
part of a combined u-boot-sunxi-with-spl.bin boot file, but additionally
also transfer the main u-boot binary (image) contained within the second
part of such files.

This can simplify the boot process / steps required to get a proper FEL
setup - e.g. it avoids having to select u-boot.bin vs. u-boot-dtb.bin,
see e.g. http://lists.denx.de/pipermail/u-boot/2015-June/217476.html



On top of that a new "fel uboot" command is introduced. As per suggestions
on the mailing list, it will take such a combined (SPL + U-Boot) file and
actually start U-Boot execution before the program exits. "uboot" may thus
also be combined with other "write" commands to transfer additional files
required for the boot (e.g. boot script, kernel, initrd).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

This is needed to have feature parity with the normal boot mode,
where the L2EN bit in the CP15 Auxiliary Control Register is set
by the BROM code right from the start. And if L2EN is not set,
then the Linux system ends up booted with the L2 cache disabled.

According to the Cortex-A8 TRM, the L2 cache is only enabled when
both L2EN bit and the C bit from the CP15 Control Register c1 are
set. Because the BROM does not set the C bit, this change should
not affect the functionality of the FEL mode in any way.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

Trying to use oversized initrd files (20 MB or more) can fail
with the "libusb usb_bulk_send error -1" error message.

To address this problem, we can split the transfer into smaller
chunks and the problem disappears. Effectively, this is a revert
of the older "fel: Increase timeout to 60 seconds instead of
splitting bulk transfers" commmit.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

By adjusting the MMU translation table before restoring it
and by enabling the I-cache with branch prediction, we can
improve performance. The DRAM area (0x40000000-0xC0000000)
becomes write-combine mapped and the BROM code becomes mapped
as cacheable memory. This is expected to be safe and should
not cause any coherency problems.

Transfer speed improvements:

A10  : ~330 KB/s -> ~600 KB/s
A13  : ~330 KB/s -> ~600 KB/s
A20  : ~320 KB/s -> ~960 KB/s
A31s : ~250 KB/s -> ~510 KB/s
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

The FEL BROM code has the MMU enabled for some reason (while
I-cache and D-cache are disabled). Most likely the intention was
to get a somewhat better performance. Everything is mapped as
TEXCB=00000 (strongly ordered), except for the 0x00000000 (SRAM)
and 0xFFF00000 (BROM) sections, which are mapped as TEXCB=00100
(normal uncached memory).

This becomes a problem for the A13 SoC, because it has less SRAM
than the other chips. A13 stores the MMU addresses translation
table at 0x8000 and uses up 16 KiB of the SRAM space there (while
the A10, A20 and A31s keep the MMU table in the secure SRAM at
0x20000). And because the 'spl' command needs space for backing
up the FEL stacks, it was clashing with the MMU table.

The solution is simple. We just backup the addresses translation
table and disable the MMU before running the SPL. And then restore
it back to the original state. This fixes problems on A13.

Re-enabling the MMU in the end is only necessary to avoid performance
losses. For example, the transfer speed of the 'fel write' command
on A20 would drop from ~320 KB/s to ~260 KB/s without MMU.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

This allows to measure the USB data transfer speed for performance
tuning purposes.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.

The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:

    fel spl u-boot-sunxi-with-spl.bin

Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.

There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.

This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.

So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

Now aw_fel_get_version() can get the SoC ID for internal usage
from the other functions. And aw_fel_print_version() is used
to print the formatted string to stdout.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>

FEL mode on the A80 changed the bulk transfer endpoint.

Let the fel utility look for the endpoint addresses instead
of hard-coding them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Henrik Nordstrom <henrik@henriknordstrom.net>

Signed-off-by: Chen-Yu Tsai <wens@csie.org>

_BSD_SOURCE doesn't work on NetBSD, so explicitly request the full native namespace.

* Split into 64KB bulk requests
* Smaller requests are sent as-is

libusb doesn't set errno, so we get ": Success" on errors