BootROMs on pre-A38x SoCs enabled its output on UART by default, but A38x'
BootROM has its output on UART disabled by default.
To enable BootROM output on A38x SoC, it is required to set DEBUG flag
(which only enables BootROM output and nothing more) in kwbimage. For UART
images this DEBUG flag is ignored by BootROM.
Enable kwbimage DEBUG flag for all A38x boards.
With this change BootROM prints the following (success) information on UART
before booting U-Boot kwbimage:
BootROM - 1.73
Booting from SPI flash
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
U-Boot SPL for mvebu platform is not compiled as position independent.
Therefore it is required to instruct BootROM to load U-Boot SPL at the
correct address. Loading of kwbimage binary code at specific address can be
now achieved by the new LOAD_ADDRESS token as part of BINARY command in
kwbimage config file.
Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into
LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in.
It is required to update regex for sed to find replacement tokens at any
position on a line in kwbimage config file and not only at the beginning of
the line. This is because LOAD_ADDRESS is specified at the end of line
containing the BINARY command.
It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value
0x40004030 or 0x40000030. Why this value? It is because main kwbimage
header is at address 0x40004030 or 0x40000000 and it is 32 bytes long.
After the main header there is the binary header, which consist of 1 byte
for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved
bytes and then 4 bytes for each argument. After these arguments comes the
executable code.
So arguments start at address 0x40004028 or 0x40000028. Before commit
e6571f38c9 ("arm: mvebu: Remove dummy BIN header arguments for SPL
binary") there were two (dummy) arguments, which resulted in load address
of 0x40004030 or 0x40000030, always. After that commit (which removed dummy
arguments), load address stayed same due to the 128-bit alignment done by
mkimage.
This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE),
load address and dummy kwbimage arguments, and allows the user to adjust
$(CONFIG_SPL_TEXT_BASE) config option to some other value.
For unsupported values, when mkimage/kwbimage cannot set chosen load address
as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails,
instead of silently generating non-working kwbimage.
Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS
can only be done by compiling U-Boot SPL as position independent. But this
currently is not possible for 32-bit ARM version of U-Boot SPL.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
U-Boot SPL binary does not read BIN header arguments, so passing some dummy
values 0000005b and 00000068 has no effect for U-Boot SPL code.
Probably these two values comes from old Marvell DDR training code which
was separated from U-Boot and used it for some configuration.
Seems that two 32-bit values were specified here to ensure SPL code
alignment to 128-bit boundary as it is required e.g. for A370 or AXP
processors. Main kwbimage header is 64-byte long which is aligned to
128-bit boundary. Optional kwbheader is 32-bit long, number of BIN header
arguments is stored in 32-bit number. So for alignment to 128-bit boundary
is needed 64-bit padding which exactly these two 32-bit dummy arguments
provided.
Now when mkimage correctly aligns start of executable code in BIN header to
128-bit boundary, there is no requirement to put dummy argument values into
kwbimage. So remove them.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Move the gdsys Controlcenter DC specific build time kwbimage.cfg
generation code into the mach-mvebu/ directory to be shared by all 32bit
mvebu platforms.
Remove board specific kwbimage.cfg files, and use the generated one
instead. These files are all identical, with two exceptions. Clearfog
and Helios4 use the sdio boot device, whereas all others use spi. Update
the defconfigs for the exceptional boards to generate the same
kwbimage.cfg as before.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
2018-08-06 14:07:23 +02:00
Renamed from board/gdsys/a38x/kwbimage.cfg.in (Browse further)
