GitLab

Fix portable_endian.h for building on FreeBSD

Nand image builder improvements

--help/-h is not working correctly (it's printing the help context on
stderr instead of stdout).
Adding a valid shortcut for --help solves the problem.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Add explanations on where the options to pass to the tool should be
extracted from, and add two examples to illustrate this explanation.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortmann@web.de>
---
Changes since v3:
- cosmetic changes to the help context

Changes since v2:
- limit line width in the help context

Changes since v1:
- use shorter option names
- rework the help context

Add error messages explaining what is wrong or missing in the arguments
passed by to the sunxi-nand-image-builder tool.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortmann@web.de>
---
Changes since v1:
- Drop uneeded braces

Add NextThing Co. and Free Electrons copyrights and add myself as the
author of the randomizer and image builder implementation.

Remove the lengthy description explaining how the BCH implementation works,
since this is the purpose of this tool is not to expose a BCH library
(which was the case of the original source code I copied from the kernel).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Bernhard Nortmann <bernhard.nortmann@web.de>
---
Changes since v1:
- Add a link to the original bch.c source file

Add new uart0-helloworld-sdboot.sunxi bootable test image

This is a universal bootable image, which just prints a hello
message on UART0. For example, it is useful as a test payload
when debugging the SPI boot functionality:
   https://linux-sunxi.org/Bootable_SPI_flash

Changes in v2:
 - A workaround for https://patchwork.ozlabs.org/patch/622173
 - Also print the type of the used bootable media

Changes in v3:
 - Bernhard Nortmann's workaround for
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63803

More details in https://github.com/linux-sunxi/sunxi-tools/pull/44

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Add a tool to generate raw NAND images

Generating raw NAND images is particularly useful for boot0 images
creation since the mainline driver is not supporting the funky layout
used by Allwinner's ROM code to load the boot0 binary from NAND.

This tools also allows one to generate raw images for 'normal' partitions
so that they can be flashed before soldering on the NAND on the board
(using a regular NAND programmer).

The tool takes care of generating ECC bytes and randomizing data as
expected by the NAND controller, and re-arranging the ECC/data sections
correctly.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>

fel: Implement "rmr" commands to force warm reset into AArch32/AArch64

fexc fixes

fel-sdboot: Fix header corruption workaround

Now that we have a better understanding of what's causing the issue
that prevented entering FEL sometimes, we can adjust the workaround
code to a proper solution, i.e. skip over the problematic location.

Since the code amounts to less than a dozen ARM instructions, I've
decided to rewrite it as assembly code - fel-sdboot.S replaces the
former fel-sdboot.c.

The commit also includes a new binary (bin/fel-sdboot.sunxi) with
these changes.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

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>

Such lines do not conform to any known syntax rules.

With this patch, fexc will assume that they represent a special
case (where bin2fex extracted a malformed indentifier from a .bin
file - likely a remnant from a comment typo), issue a warning and
ignore the line.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

script_bin.c decompiles section entries even if they have invalid
indentifiers. Thus malformed .bin files were observed to result in
a .fex that couldn't be processed successfully with the sunxi-fexc
compiler.

This patch makes bin2fex now issue a warning for this kind of keys,
so that they're easier to notice and correct.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Recent original .bin files showed up with a version[0] of 49152
= 0xC000, which won't pass our current sanity checks. Restrict
version[0] check to lower 14 bits, to make it pass again.

(This might require further investigation in the future, as it's
possible that this particular header field actually isn't related
to version data at all.)

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

Both the error output in function decompile_section() and the
definition of GPIO_BANK_MAX in script.h suffered from an "off
by one" logic. The bank numbering in the .bin is based on 1,
so it should be added to ('A' - 1) for human-readable output,
and the maximum number corresponding to 'N' is 14.

This became apparent when trying to translate a fex2bin-compiled
a80_optimus_board.bin back to its original .fex equivalent.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

A test case for this is "fex2bin a-star_kv49l.fex".

This patch fixes an execution path in script_fex.c that would
allow script_parse_fex() to fail (i.e. return 0) without providing
any feedback to the user.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Make fel-sdboot.sunxi usable on A64 and A80

This also fixes potential problems with older SoCs when using certain (cross-)toolchains. See the discussion of #42

fel: Add fel spl command support for Allwinner A64
Acked-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 small bootable stub, which just passes control to the
FEL code in the BROM, needs to be adjusted to also support
Allwinner A64 and Allwinner A80 because the BROM is located
at a different address there.

The SD card boot has a very low priority on Allwinner A64, but
it at least has a higher priority than the SPI NOR Flash:

    https://linux-sunxi.org/BROM#A64



So this patch may help to simplify the FEL mode activation on
devices, which are booting their firmware from the SPI NOR Flash.

Changes in v2:
 - Use SCTLR.V to detect the exception vectors location as
   suggested by Jens Kuske.
 - Add a padding of 32 NOP instructions in the beginning as
   a workaround for some strange failures.
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>

- Convert C++ style comments for a uniform coding style.
- Some small formatting adjustments.
- Change "sid" command to print ':' separators instead of spaces.

Apart from "sid" output, no functional changes involved.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Add DISCARD directives to the linker scripts and also -marm option
to GCC command line. Without this, certain toolchains may build
Thumb2 code by default. Also junk sections may be present in the
final binary and they need to be removed.

This helps at least when using the following Linaro toolchain:
gcc-linaro-5.1-2015.08-x86_64_arm-linux-gnueabihf.tar.xz
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>

"make binfiles" should allow building ARM binaries more easily.

Factor out common $(ARM_ELF_FLAGS).

Also rewrite some rules using $< and $@, to avoid repeating
filenames. And trim down on the number of rules using patterns
for objcopy (%.elf -> %.bin) and mksunxiboot (%.bin -> %.sunxi).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

fel: Add new readl/writel functionality and a "sid" command

This patch makes use of the new aw_fel_readl_n() function to output
the first four 32-bit values (SID key) from an SoC-specific address.
The corresponding e-fuses may not necessarily start at the SID
"base" address, e.g. on H3/A83T they are at <base+0x200>.

Note: SoC support is currently incomplete. In particular, reading
the SID on A31(s) is unsupported. Accessing it there is complicated
by the fact that Allwinner moved this information from the SoC into
the PMIC/AXP221.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

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

Squashed commit of the following:

commit 95f3614357446c4a35ec541bb2c21503c54d3fac
Author: Bernhard Nortmann <bernhard.nortmann@web.de>
Date:   Fri Apr 8 09:10:17 2016 +0200

    fel: Add support for multiple sequential readl/writel

    There are cases where "long" reads/writes might be used to transfer
    multiple values from/to sequential addresses.

    When doing so, we can avoid having to setup and upload the entire
    scratch buffer (ARM code) every time, by making the underlying
    functions auto-increment the address on each invocation.

    The patch implements this functionality, and maps the existing
    aw_fel_readl() and aw_fel_writel() to special cases (count == 1).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

commit 20ececdfc7f3c4070469a7b74ba77bb74e01f876
Author: Bernhard Nortmann <bernhard.nortmann@web.de>
Date:   Fri Apr 8 09:00:20 2016 +0200

    fel: Modify handling of command line args for "readl"/"writel"

    Most other commands use their decoded argument values directly,
    without storing them to local vars first. Also "writel" needs
    an (argc > 3).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

commit b4216371b97e9f1dd19f7fc2ce720b9cb8e2434e
Author: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Date:   Sat Dec 19 08:22:26 2015 +0200

    fel: Add "readl" and "writel" commands

    The read/write operations done by FEL are not suitable for accessing
    hardware registers. For example, trying to read a SID value using
    the "read" or "hexdump" commands results in the following:

      $ sunxi-fel hexdump 0x01c23800 4
      01c23800: 87 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __

    Apparently, FEL tries to read data one byte at a time and this does
    not always work correctly. Introducing new commands to explicitly
    do 32-bit reads and writes helps:

      $ sunxi-fel readl 0x01c23800
      0x16254187
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Tested-by: Bernhard Nortmann <bernhard.nortmann@web.de>

Doing certain operations may need uploading and executing code
on the device. For example, such operations right now are
reading/writing ARM CP15 coprocessor registers. Uploading the
code to the device is naturally overwriting some part of SRAM
as a side effect. Right now it is not a problem, because the
CP15 coprocessor registers are only accessed as part of uploading
and executing U-Boot SPL. They are nicely timed not to cause
problems and the temporary scratch area gets overwritten by
the SPL code anyway.

But if we decide to provide access to such operations via
command line interface, then any side effects may potentially
cause problems for the users. Consider the following scenario:

  sunxi-fel clear 0x2000 0x100 \
            advanced-command-which-uploads-and-executes-code \
            hexdump 0x2000 0x100

The user may rightfully expect that clearing a buffer in SRAM
to zero and then reading it back should show all zero bytes.
But inserting advanced commands in the middle may cause data
corruption.

In order to resolve this problem, just move the scratch area
away from the 0x2000-0x5BFF addresses range. These particular
addresses are already known to the users as a safe place for
their bare metal expariments in FEL mode. The "sunxi-fel spl"
command is a special case though and it is expected to
overwrite data in this area too.

A possible alternative would be to just backup & restore data
in the scratch area. But this has some disadvantages:
  1. Extra code in the sunxi-fel tool and extra roundtrips over
     USB to do the backup/restore job.
  2. If we allow the OpenRISC core to use the 0x2000-0x5C00
     range in SRAM A1, then this becomes unsafe and racy
     (we can't really backup & restore data without causing
     a temporarily glitch for the currently running code on
     the OpenRISC core).

To sum it up. With this patch we make it so that now the
0x2000-0x5BFF range is freely available for the users of the
sunxi-fel tool. The 0x1000-0x1FFF range is off limits (the
upper part of it is used by the FEL IRQ handler, the lower
part of it is reserved for internal use by the sunxi-fel
tool). The 0x0000-0x0FFF addresses range is reserved for
passing data from the SPL to the main U-Boot binary (via
the SPL header) and is also off limits.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Tested-by: Bernhard Nortmann <bernhard.nortmann@web.de>
Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>

After eliminating all warnings, we can disallow them for future
builds. This is done by passing an additional "-Werror" flag
from the Travis build step. Introducing new warnings will cause
a (CI) build failure from now on.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

This is done by explicitly setting at least one member field
(preferably the one that gets tested for validity later),
instead of just using "{ 0 }".
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>

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