Add an entry type for a firmware blob for a System Control Processor,
given by an entry arg. This firmware is a raw binary blob.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
If neither CONFIG_SPL_FIT_SOURCE nor CONFIG_USE_SPL_FIT_GENERATOR is
enabled, U_BOOT_ITS will be undefined, and attempting to make u-boot.itb
will pass invalid arguments to mkimage, causing it to print its help
message.
Remove the rule in that case, so it is more obvious that u-boot.itb is
not something that can be made. This will reduce confusion as platforms
move away from CONFIG_USE_SPL_FIT_GENERATOR, as u-boot.itb was
previously a valid goal for those platforms.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Generate 'u-boot-splx4.sfp' which consist of 4 SPL images required
for booting up Cyclone5/Arria10.
By default, this 'u-boot-splx4.sfp' is generated without extra
padding after each SPL image.
For Cyclone5, 'u-boot-splx4.sfp' contains:
4 x SPL(64KB) = 256KB
For Arria10, 'u-boot-splx4.sfp' contains:
4 x SPL(256KB) = 1024KB
For Cyclone5 using NAND flash image layout for 128 KB memory blocks,
user can 'make' the following target to generate 4 SPL images with
padding:
make u-boot-spl-padx4.sfp
'u-boot-spl-padx4.sfp' contains four 128KB SPL images (each 64KB SPL is
followed by 64KB of zero-padding).
4 x (SPL(64KB) + zero-padding(64KB)) = 512KB
Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Add a new entry argument to the fit entry which allows selection of the
default configuration to use. This is the 'default' property in the
'configurations' node.
Update the Makefile to pass in the value of DEVICE_TREE or
CONFIG_DEFAULT_DEVICE_TREE to provide this information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Michal Simek <michal.simek@xilinx.com>
At present 64-bit sunxi boards use the Makefile to create a FIT, using
USE_SPL_FIT_GENERATOR. This is deprecated.
Update sunxi to use binman instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
At present binman warns about missing external blobs only when the
BUILD_ROM is defined. Enable this behaviour always, since many boards
are starting to use these (e.g. ARM Trusted Firmware's BL31).
Signed-off-by: Simon Glass <sjg@chromium.org>
HTML documentation is generated in doc/output/. This directory shall be
deleted by 'make mrproper'
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
every compilation shows this error
Hack for sunxi which doesn't have a proper binman definition for
64-bit boards
not only for sunxi-boards/arm64
fix this by changing to real comments
Fixes: 9f55ee259d0c ("Makefile: sunxi: Don't use binman to build ATF image")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
At present with sunxi 64-bit, the Makefile builds
u-boot-sunxi-with-spl.bin and then binman overwrites it with its own
version. But the binman definition lacks some parts, in particular
BL31.
For now, work around this with a hack.
Tested-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 42b18df80f ("x86: Makefile: Drop explicit targets built by binman")
This option is used to run arch-specific shell scripts which produce .its
files which are used to produce FIT images. We already have binman which
is designed to produce firmware images. It is more powerful and has tests.
So this option should be deprecated and not used. Existing uses should be
migrated.
Mentions of this in code reviews over the last year or so do not seem to
have resulted in action, and things are getting worse.
So let's add a warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present we use the empty string to indicate that there is no FIT
generator, but this doesn't allow an individual board to undefine it.
Create a separate bool instead.
Update the config of the boards which currently have an empty string.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this is checked before the config has been loaded by the
Makefile, so it doesn't work.
Move the check to later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
On mediatek various files that need to be created by binman. It does not
make sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Also update the binman definition so that idbloader.img is only needed
when SPL is actually being used.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
On tegra various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
On sunxi various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
This Kconfig is not needed anymore since U-Boot will build the ROM if the
required binary blobs exist.
The BUILD_ROM environment variable used to request that the ROM be built.
Now this always happens if the required binary blobs are available. Update
it to mean that U-Boot should fail if the ROM cannot be built. This
behaviour should be compatible with how it used to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
On x86 various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
Update the Makefile to have a separate, final step which runs binman,
once all input dependencies are present.
This avoid sprinkling the Makefile with arch-specific code.
Signed-off-by: Simon Glass <sjg@chromium.org>
When binman is in use, most of the targets built by the Makefile are
inputs to binman. We then need a final rule to run binman to produce the
final outputs.
Rename the variable to indicate this, and add a new 'inputs' target.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some non-x86 devices can use SPI flash to boot and need to produce images
of a fixed size to program the flash.
Add a way to handle this for non-x86 boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most x86 boards build a u-boot.rom which is programmed into SPI flash. But
this is not unique to x86. For example some rockchip boards can also boot
from SPI flash.
Also, at least on x86, binary blobs are sadly quite common. It is not
possible to build a functional image without them, and U-Boot needs to
know this at build time.
Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is
built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary
blobs are also needed. If they are not needed, it is safe to build the ROM
always. Otherwise we still require the BUILD_ROM environment variable.
For now this affects only x86, but future patches will enable this for
rockchip too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Borrowing from Linux commit 78a5255ffb6a ("Stop the ad-hoc games with -Wno-maybe-initialized")
move to have maybe-initialized warnings be handled with building with
W=2 instead of playing more guessing games with newer compilers.
Signed-off-by: Tom Rini <trini@konsulko.com>
- Makefile: add rule to build an endian-swapped U-Boot image
used by MIPS Malta EL variants
- CI: add Qemu tests for MIPS Malta
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiQkHUH+J02LLC9InKPlOlyTyXBgFAl76U4wACgkQKPlOlyTy
XBhKeg/6Au6lPC5QLnjEO5gpuhI/eF555jRoABXUNoM8FUjkcqA207Sgd3iTH9lS
imOGHkzwipYno5pY1UoiXr7RKJgAkJfKYWRrZ46qgITrEkgQ8Xyp46xIqhoHvpuH
Qs1YeDllHeRViBt2ZP6UJsYfUIA9xnU/o9tLh4lx2SiCPWbNDns7cB0Ajazh47Cx
8UT2ZwbATaaFfN9m4Lg65O6Fe1G/cHAw5H/xsDajpVOpskHk0RZxRxzob6XLQete
sVkZdjYmH7zG+7THLkPriu2y/qlc5t2re3OeAr/5YwYJODnj3aN7iI20Sl9xMwDP
eDcSt19HMs+Ng60+yqwHxoU+AQ2BjswYHssb2vdY8OQhlRpoFke6nT+oQtCQCYhZ
At/b2O8kh9IM9alsc8xltMABLgrOhREfxC6VQg7bsCH01+qcojGX8dhVQrYsWkKQ
GrCs6SAl8zR78j8s3OGSsvTczMkTrBTglYWIYrlvA5fFhVg5Yz38S+ioTqPc4QDc
ZJ9bDDO00CY4hJC8sx4TQcsn0OmSJeN394dy6CUoxL6fEXBdRmNRLBUnmuTmPmYT
suLB9qaG+Q6cEttXjfNN1VotSG+61COUZ0uoed47cGUo8AxLMTEe62twUc0aDPNS
NMUoMwHqVbivaGUBfG16mu8bnVfaCqFyR/LLGa6J3yQSQ8qeu30=
=dnTK
-----END PGP SIGNATURE-----
Merge tag 'mips-pull-2020-06-29' of https://gitlab.denx.de/u-boot/custodians/u-boot-mips into next
- net: pcnet: cleanup and add DM support
- Makefile: add rule to build an endian-swapped U-Boot image
used by MIPS Malta EL variants
- CI: add Qemu tests for MIPS Malta
This rule generates an u-boot binary file where the byte endianness
is swapped. This will be used by the MIPS Malta Little-Endian variants
to be able to boot with Qemu. The Qemu Malta Machine expects the
firmware in Big-Endian order.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
There are two remaining users of the CONFIG_SECURE_BOOT symbol that have
not been migrated to another symbol. In this case, they should be using
CONFIG_NXP_ESBC as their guard.
Cc: Vladimir Oltean <olteanv@gmail.com>
Fixes: 5536c3c9d0 ("freescale/layerscape: Rename the config CONFIG_SECURE_BOOT name")
Signed-off-by: Tom Rini <trini@konsulko.com>
On rockchip platforms, SPI boot image creation is not
straightforward like MMC boot image creation where former
requires to specify tpl, spl in multimage format in mkimage,
and later simply do a concatenate mkimaged-tpl with spl.
On this note, let drop rkspi image type creation via kbuild
and let inform via rockchip.rst
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
File 'defconfig' is a build artifact of 'make savedefconfig'.
Remove it when cleaning.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This code dates back to 2006, commit 483a0cf804 ("Fixes for gcc 3.4
based m68k toolchain,").
GCC 3.4 is so old. We do not support it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Coreboot runs in 32-bit mode and cannot run a 64-bit U-Boot. To get around
this we can build a combined image with 32-bit SPL and 64-bit U-Boot. Add
a build rule and binman definition for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Minor buildman fixes for new features
Make libfdt code more similar to upsteam
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl6mTJMRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreZRmAf/TeHuh9nWXr7jRAyl8YEaXfBablceBYF/
l/bHpIyPy1NH5wRMB1kwGIZUydSM44/FIVnvlo1iVI0DVuO1cSIY98WM2waMP0Tk
WiDg3XR7eMpTMNjG13KP6TrFG5ybfOopRYdpuUfjPTBm8RQyuFMziaQwOrDQdoXt
9yQ8rzM6hB7Gj3LgORond04KZYRUcYC+uhcuDo8WPUjrqS8vSpeAG34n6lT4z9KG
BdmhQuIybvCngdi/t9ovyTfq5UfIsXp0ngUN6My/j0IjykZT4nu6qllge8gcukCM
3iqrqhcjkO9psPdk6NXf2akTdxDH4Mf8PqFbvqmABNQbDSEVinVnrA==
=H2KE
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-27apr20' of git://git.denx.de/u-boot-dm
Move Python tools to use absolute paths
Minor buildman fixes for new features
Make libfdt code more similar to upsteam
Copy the .its source file selected by CONFIG_SPL_FIT_SOURCE
in builddir and in a file named "u-boot.its".
This patch avoid compilation issue when CONFIG_SPL_FIT_SOURCE is used
and KBUILD_OUTPUT is defined, in buildman for example.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>