The suniv SoCs has a SPI controller like the one in H3, but with base
address like sun4i and no SPI module clock in CCU.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Andre Przywara <osp@andrep.de>
The original fel-remotefunc-spi-data-transfer.h contains code only
suitable for ARMv7+. The F1C100s family is ARM9 (ARMv5TE), so rebuild it:
$ ./fel-remotefunc-compiler.rb fel-remotefunc-spi-data-transfer.{c,h}
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner also has ARM926EJ-S (ARMv5TE) based SoCs.
Consider them when set -march parameter. Also switch to -Os, since we
are more interested in compact code - performance is secondary when doing
mostly MMIO anyway.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
Allwinner F1C100s is one of the new ARM9 SoCs produced by Allwinner.
Add support for it in FEL.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
Some bits are not meaningful both in ARMv5 and ARMv7/8, however they're
read as 0 in ARMv5 but 1 in ARMv7/8.
Ignore them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
Almost all thunks are already ARMv5 safe, so we can just require this
architecture on the gas command line, to enforce compatibility with the
F1Cx00 series. This prevents accidental changes in the future.
The RMR thunk uses the ARMv7 only DSB/ISB instructions, but this runs on
ARMv8 cores only anyway, so we just force ARMv7 for this file, and avoid
code changes.
Signed-off-by: Andre Przywara <osp@andrep.de>
Currently the thunk we upload into the SRAM is using DSB and ISB
instructions, which were introduced in ARMv7. Also it relies on
movw/movt pairs, which became available in ARMv6T2.
The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they
do not know these instructions.
Change the code to be ARMv5TE compliant, so it can run on all relevant
Allwinner ARM cores:
- One movw is just used to compare two bits, replace that with a
tst/tsteq sequence to skip the load.
- The other movw/movt pairs get replaced with ldr's, that load from
literal storage at the end of the code (from Icenowy).
- The DSB and ISB get replaced with their CP15 MCR counterparts. Those
are deprecated in ARMv7, but still work, when the CP15BEN bit is set
in SCTLR. We check for this in fel.c (from Icenowy). ISB is not
implemented on the ARM926, so make this conditional. A simple branch
takes care of the desired pipeline flush for the old SoC.
Also remove the rather pointless Ruby prolog that generates the header
file. We have a less awkward version of this in the Makefile, and need
that for the other thunks there anyway, so it's just duplicated code.
Embedding a header generator in Ruby in an assembly file is a cute
gimmick, but serves no purpose anymore.
This is based on work by Icenowy, who put a similar solution in a
separate file.
Originally-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Andre Przywara <osp@andrep.de>
It seems like travis-ci.org is gone, replaced by travis-ci.com, but
apparently that's not truly free anymore: it requires a registered account
plus credit card, and is only granted a one-time free credit allowance,
with the option to get this extended by explicit request. As a result
the current CI stopped working a while ago, and was broken anyway (it
failed building already, and make check on its own doesn't pass on
master anymore).
Github itself seems to offer an alternative, so let's add a control file
for that to get some basic CI back.
This builds the host and misc tools on a standard Ubuntu system, and
runs make check.
Signed-off-by: Andre Przywara <osp@andrep.de>
"make check" uses the .fex files in the sunxi-boards repository to
verify the validity of our FEX compiler.
To overcome an existing issue, there was one patch file applied to the
mainline repository content. However this was merged into mainline
sunxi-boards a while ago, so remove that patch file, as trying to apply
the patch actually fails the current test early.
Also some new files (H6 boards) have been added meanwhile, but they are
apparently buggy:
- pine64_h64.fex contains some apparently bogus characters before the
leading comment, possibly an artefact of its extraction.
- One DRAM TPR6 parameter seems to contain an extra trailing 0, making
the value larger than 32 bit, and not matching the TPR6 values for
other A31 boards. Just remove that, as the compiler rightfully
complains about that.
This allows the "make check" command to pass again.
Signed-off-by: Andre Przywara <osp@andrep.de>
Some .fex files (for instance those for the H6 in sunxi-boards) contain
a trailing semicolon on some lines, after the end quote of a string
value.
This confuses the parser and messes up our "make check" tests, so remove
the semicolon both in the parser, but also in the unify-fex test
conditioning tool, to make the tests pass.
Signed-off-by: Andre Przywara <osp@andrep.de>
These files were all originally by Bernhard in 2016 via these commits:
8445d71 unify-fex: Use int64_t and portable format specifiers for its output
f957f89 fextest: Add a dedicated rule for (CI-)testing sunxi-boards
6ec3876 tests: Improve code coverage by testing corner cases
cd5a0a3 tests: Improve on testing fexc
5cbb0c9 tests: Introduce a basic testing framework
and have not otherwise been touched. The header was added to unify-fex.c when
it was added in cd5a0a3303cb ("tests: Improve on testing fexc") but not to the
other files.
The license in unify-fex.c is the GPLv2+ which corresponds to the content of
LICENSE.md both at the time and now. I think therefore that it is appropriate
to duplicate the header into the other files (changing only the character used
for comments to suit)
Newer fex files like orangepi_oneplus.fex from the sunxi-boards repo fail
conversion to the binary format:
--------------------------
E: orangepi_oneplus.fex:258: invalid character at 4.
--------------------------
This is because they contain a '-' character in section and key names, and
also '/' characters in some section names, which our compiler denies.
Relax the section and key filter to allow '-' and '/' as well.
Signed-off-by: Andre Przywara <osp@andrep.de>
Some functions are only used internally in fel_lib.c, consequently their
prototypes are not exported in fel_lib.h.
Mark those functions as "static", to make this clear to the reader and
improve the generated code.
Signed-off-by: Andre Przywara <osp@andrep.de>
The aw_usb_read() function is meant to *fill* the buffer given to it, so
marking the pointer as "const" in the parameters list is wrong.
Some compilers (for instance GCC 11) spot this and issue a warning:
----------------------------------
fel_lib.c: In function ‘aw_read_fel_status’:
fel_lib.c:190:9: warning: ‘buf’ may be used uninitialized [-Wmaybe-uninitialize]
190 | aw_usb_read(dev, buf, sizeof(buf));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fel_lib.c:168:13: note: by argument 2 of type ‘const void *’ to ‘aw_usb_read’ declared here
168 | static void aw_usb_read(feldev_handle *dev, const void *data, size_t len)
| ^~~~~~~~~~~
fel_lib.c:189:14: note: ‘buf’ declared here
189 | char buf[8];
| ^~~
----------------------------------
Drop the 'const' specifier, and use the right USB bulk transfer wrapper
to make this work. The usb_bulk_send() function just happened to work
before because the actual libusb bulk transfer function is bidirectional.
Signed-off-by: Andre Przywara <osp@andrep.de>
So far the output of "sunxi-fel -h" was the only source of information
about sunxi-fel's command line parameters, and the description was
rather terse.
Add a manpage that describes the purpose of sunxi-fel and its options it
a bit more detail.
Amend the Makefile to install the manpage into the usual location.
Signed-off-by: Andre Przywara <osp@andrep.de>
In cross-build situations this allows for `«triplet»-pkg-config` to be passed
in so that target libraries are used instead of host ones.
Unless `PKG_CONFIG` is overridden by the person doing the build then there is
no semantic change.
Signed-off-by: Ian Campbell <ijc@debian.org>
A helper function in fit_image.c was using our self defined portable
endianess conversion function, but was not including our endian header.
This lead to broken builds on some setups:
==========================
fit_image.c: In function 'fdt_getprop_u32':
fit_image.c:86:9: warning: implicit declaration of function 'be32toh'
[-Wimplicit-function-declaration]
86 | return be32toh(*(uint32_t *)prop->data);
| ^~~~~~~
/usr/bin/ld: /tmp/cczFroQN.o: in function `fdt_getprop_u32':
fit_image.c:(.text+0x1e0): undefined reference to `be32toh'
collect2: error: ld returned 1 exit status
==========================
Fix this by using the libfdt provided endianess conversion function,
and using an easier way to get the property on the way.
Signed-off-by: Andre Przywara <osp@andrep.de>
Reported-by: kaidokert
More recent versions of GCC warns about the usage of strncpy in
nandpart.c: we actually only (need to) copy the stub string part of the
magic string, without the terminating NUL character. This is fine in
our particular case, but raises the compiler's eyebrows:
===================
nand-part.c: In function '_get_mbr':
nand-part.c:93:4: warning: 'strncpy' output truncated before terminating
nul copying 8 bytes from a string of the same length
[-Wstringop-truncation]
93 | strncpy((char *)mbr->magic, MBR_MAGIC, 8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===================
Switch to the more fitting memcpy() here to avoid the warning.
Signed-off-by: Andre Przywara <osp@andrep.de>
Reported-by: slange-dev
There are two more dependencies in addition to libusb and pkgconfig, which
are libz and libfdt. Tell about them and give an example command to install
the packages through apt.
Signed-off-by: Nazım Gediz Aydındoğmuş <gedizaydindogmus@gmail.com>
Allwinner R329 has some different base addresses. Fortunately the base
addresses that our SoC detection code relies keep the same with H6, so
its support can be added.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Allwinner R329 has no SRAM A1, but a huge SRAM A2 that is partly
utilized as boot time SRAM.
Add basical support for it. The spl subcommand is tested with modified
uart0-helloworld-sdboot and extracted original boot0.
Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
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>
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>
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>
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>
Our FEL code does not deal very well with the upload size being 0.
Check for that before calling any USB routines, and skip the call
entirely. Mark the buffer as "const" on the way, since we have no
business other than reading from it.
That helps to properly skip dummy images later.
Signed-off-by: Andre Przywara <osp@andrep.de>
The A64 and H5 have a rather generous SRAM C directly adjacent to
SRAM A1, so we can make use of the larger continuous SRAM area to
increase the maximum SPL size.
Move the location of the FEL stack backup buffer up, towards the end of
SRAM C. We restrict ourselves to the slightly tighter requirements of
the H5, to be able to still share the joint swap_buffers data structure.
Signed-off-by: Andre Przywara <osp@andrep.de>
The H6 has quite a large chunk of continuous SRAM, and also the BROM
allows to load eGON images far bigger than 32KB.
Move the FEL stack backup buffers and the thunk address towards the end
of SRAM C, so that we have a larger chunk of continuous SRAM available
for the SPL.
Signed-off-by: Andre Przywara <osp@andrep.de>
The H616 has quite a large chunk of continuous SRAM, and also the BROM
allows to load eGON images far bigger than 32KB. U-Boot's SPL is
actually relying on this, as we need more code for the PMIC and DRAM
driver.
Move the FEL stack backup buffers and the thunk address towards the end
of SRAM C, so that we have a larger chunk of continuous SRAM available
for the SPL.
Signed-off-by: Andre Przywara <osp@andrep.de>
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>
At the moment we assume the SPL load size to be limited to 32KB, even
though many SoCs have more SRAM A1 or a large SRAM C directly after SRAM
A1.
To later allow to extend the SPL load size, let's introduce a SoC
specific variable to hold the SRAM size after the SPL load address. This
could either cover the whole of SRAM A1, or even SRAM C, if that is
contiguous to SRAM A1.
Eventually this variable is meant to hold the *usable* SRAM size, so not
including regions that are used by the BROM code. However this value is
very SoC specific and not documented, and the SPL size is limited by the
thunk and stack buffers anyway at the moment, so the values used here
right now are just taken from the respective manuals.
Signed-off-by: Andre Przywara <osp@andrep.de>
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 H616 SPI is very similar to the H6, only differs in the GPIOs
(again).
Add the SoC-ID at the right places and add the GPIOs according to the
manual.
Tested on OrangePi Zero 2.
Signed-off-by: Andre Przywara <osp@andrep.de>
