echo -n does not give the intended effect when invoked in macOS through
/bin/sh, which is the shell make uses by default, see
"https://stackoverflow.com/questions/11675070/makefile-echo-n-not-working"
for a detailed explanation. In this case, it resulted in "-n" being
written to env.txt and env.in even though they should be empty, which
caused compilation to fail with "Your board uses a text-file
environment, so must not define CONFIG_EXTRA_ENV_SETTINGS".
This patch prevents the error by replacing echo -n's with touch, as they
are used to create empty files in these cases.
Very few boards remain to be migrated:
am57xx_hs_evm_usb
controlcenterdc
highbank
ls1021atsn_qspi
ls1021atsn_sdcard
ls1021atwr_sdcard_ifc_SECURE_BOOT
ls1046ardb_sdcard_SECURE_BOOT
ls1088ardb_sdcard_qspi_SECURE_BOOT
omap5_uevm
pg_wcom_expu1
pg_wcom_seli8
sandbox
sandbox64
sandbox_flattree
sandbox_noinst
sandbox_spl
tools-only
Addd a migration deadline for a year out.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Skip running arch/arm/mach-imx flash.bin generation in case BINMAN is
enabled, otherwise the target in arch/arm/mach-imx/Makefile regenerates
the flash.bin again and produces corrupted result.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Peng Fan <peng.fan@oss.nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current Makefile rule requires there to be a 'Module' line in the
pylint output, like this:
************* Module binman.fip_util
This line only appears if pylint has some comments about the module. We
cannot rely on it for naming.
Update the code to instead use the filename as the identifier for each
score, so rather than:
multiplexed_log 7.49
we output:
test_multiplexed_log.py 7.20
It is still easy to see which file the score relates to. In fact the new
naming is nicer since the full subdirectories are shown.
The avoids the problem where a module name is not produced, and the output
gets out of sync.
Regenerate pylint.base so we can start from the current baseline.
Signed-off-by: Simon Glass <sjg@chromium.org>
This probably should have been done a while back since it is a core
system. Very few boards remain to be migrated.
Addd a migration deadline for a year out.
Signed-off-by: Simon Glass <sjg@chromium.org>
This behaviour is necessary with boards where the binman description
requires processing external blobs, since these may be missing.
Enable it by default, so that CI is happy. Warnings indicate that a valid
image is not produced, as with the --allow-missing option.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the Python code in U-Boot is somewhat inconsistent, with some
files passing pylint quite cleanly and others not.
Add a way to track progress on this clean-up, by checking that no module
has got any worse as a result of changes.
This can be used with 'make pylint'.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Re-generate pylint.base]
Some boards still use the old timer mechanism. Set a deadline for them to
update to driver model. Point to some examples as well.
This needs a bit of a strange rule to avoid an error on some boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
When building for i.mx8m boards with binman, a few more additional
files are created which should be removed when running 'make clean'
Signed-off-by: Adam Ford <aford173@gmail.com>
While converting to binman for an imx8mq board, it has been found that
building in the u-boot CI fails. This is because an imx8mq requires an
external binary (signed_hdmi_imx8m.bin). If this file cannot be found
mkimage fails.
To be able to build this board in the u-boot CI a binman option
(--fake-ext-blobs) is introduced that can be switched on via the u-boot
makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are
created.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
U-Boot always needs some sort of a device tree in the build. Some boards
never actually use this, at least in production systems, since a prior
firmware stage sets one up and passes it to U-Boot. At present the only
mechanism to do that is with custom function (OF_BOARD), but future work
will include a standard way of doing this ('standard passage').
It can be confusing to see a device tree emitted from the U-Boot build in
this situation. Add an option to drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Boards which define OF_HAS_PRIOR_STAGE must define OF_BOARD at present,
since a custom function is the only way to obtain the devicetree at
runtime.
Add a build error when this requirement is not met, to avoid accepting
any patches which break this requirement.
Add an allowlist for boards which use it, currently none. This allowlist
can be updated for local development, if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: change of_whitelist to of_allowlist]
Signed-off-by: Tom Rini <trini@konsulko.com>
This was added as a hack to work around not having an in-tree devicetree.
Now that this is fixed it is not needed.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present it is necessary to symlink files containing external blobs into
the U-Boot tree in order for binman to find them. This is not very
convenient.
Add two new environment/Makefile variables to help with this. Add
documentation as well, fixing a related nit.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.
Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board/<vendor>
directory, typically called <board>.env and controlled by the
CONFIG_ENV_SOURCE_FILE option.
The environment variables should be of the form "var=value". Values can
extend to multiple lines. See the README under 'Environment Variables:'
for more information and an example.
In many cases environment variables need access to the U-Boot CONFIG
variables to select different options. Enable this so that the environment
scripts can be as useful as the ones currently in the board config files.
This uses the C preprocessor, means that comments can be included in the
environment using /* ... */
Also support += to allow variables to be appended to. This is needed when
using the preprocessor.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Marek Behún <marek.behun@nic.cz>
Correct an error in the tpl-dtb parameter to binman. At present the TPL
rule follows SPL but this is not correct, if TPL uses of-platdata, for
example.
Fixes: f99cbe4e86 ("fdt: Update Makefile rules with the new OF_REAL Kconfig")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Quite a lot of the code in common/relates to booting and images. Before
adding more it seems like a good time to move the code into its own
directory.
Most files with 'boot' or 'image' in them are moved, except:
- autoboot.c which relates to U-Boot automatically running a script
- bootstage.c which relates to U-Boot timing
Drop the removal of boot* files from the output directory, since this
interfers with the symlinks created by tools and there does not appear
to be any such file from my brief testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Artem Lapkin <email2tema@gmail.com>
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.
For now, avoid mentioning the documentation for the 64-bit app, since it
does not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For the EFI app, we must embed the devicetree in the ELF file since that
is the only thing that is run by UEFI. Drop the warning to avoid
confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When linking the final u-boot binary with LLD, the following link errors
are seen:
ld.lld: error: can't create dynamic relocation R_386_32 against local
symbol in readonly segment; recompile object files with
-fPIC or pass '-Wl,-z,notext' to allow text relocations
in the output
>>> defined in arch/x86/cpu/start.o
>>> referenced by arch/x86/cpu/start.o:(.text.start+0x32)
[...]
>>> defined in arch/x86/cpu/start16.o
>>> referenced by arch/x86/cpu/start16.o:(.start16+0x1C)
According to Nick Desaulniers:
"This is a known difference between GNU and LLVM linkers; the GNU
linkers permit relocations in readonly segments (making them not read
only), LLVM does not (by default)."
Since U-Boot apparently seems to use relocations in readonly segments,
change the global linker flags to permit them when linking with LLD by
specifying '-z notext'.
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
OF_HOSTFILE is used on sandbox configs only. Although it's pretty
unique and not causing any confusions, we are better of having simpler
config options for the DTB.
So let's replace that with the existing OF_BOARD. U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
While we intentionally set -std=gnu11 for building host tools, and have
for quite some time, we never dropped -std=gnu99 from tools/Makefile.
This resulted in passing -std=gnu11 ... -std=gnu99 when building, and
gnu99 would win. This in turn would result now in warnings such as:
tools/mkeficapsule.c:25:15: warning: redefinition of typedef 'u32' is a C11 feature [-Wtypedef-redefinition]
typedef __u32 u32;
^
Signed-off-by: Tom Rini <trini@konsulko.com>
At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined, even
when DTC is provided. The built dtc is not actually used, so this is a
waste of time.
Update the Makefile logic to build dtc only if one is not provided to the
build with the DTC variable. Add documentation to explain this.
This saves about 3.5 seconds of elapsed time on a clean build of
sandbox_spl for me.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since derivatives are moving to binman from usage of the FIT generator
script, and considering the warning introduced in f4a43d2925
("Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR"), usage of FIT
generator is discouraged.
Current FIT generator also generates broken output, since commit
3f04db891a ("image: Check for unit addresses in FITs") prohibits using
'@' for unit addresses but the generator script still emits the old
sematics.
Remove the generator script and corresponding call in Makefile, all
derivatives should be migrated to binman in order to provide binary
images.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
OEM_REVISION is 32-bit unsigned number. It should be increased only when
changing software version. Therefore it should not depend on build time.
Change calculation to use U-Boot version numbers and set this revision
to date number.
Prior this change OEM_REVISION was calculated from build date and stored in
the same format.
After this change macro U_BOOT_BUILD_DATE is not used in other files so
remove it from global autogenerated files and also from Makefile.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmFR2fMRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreaAnAf/ZKPy3CRphbgAmbLhNQhQGpLosLcFp343
cv53gfsv1DakLRrhqMSnOQSVoTg9P22uHbooDDR9WHfZyEL6tvGZ+dgN2/wlDhDj
wbvvsM7FB+uvLVfMF3MURQBvy4dPO+FyCm/uHmry2V2uqWPw4ss+aVhxeQ5s4/oI
LpS6yaiM8UAj2GTUZSqJ1+/W7YG9N6tL73n0PDyCvSrdCkyPWqpww1rtST88SfFI
bBEWc6ksna/29haOwHQ2xopEbVxtHv2byULfqUtnsbtE4Ozw8o0fx66tdwPHTQlM
7eSuRiEbqjlJuUZFIbMat7nb7inZkaWupZ/Sr1HUUiDdKMygrRsQhg==
=x8Uf
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-next-27sep21' of https://source.denx.de/u-boot/custodians/u-boot-dm into next
Various of-platdata improvements, including CONFIG_OF_REAL
The code under drivers/net is related to ethernet networking drivers, in
some fashion or another. Drop these from the top-level Makefile and
also move the phy rule into drivers/net/Makefile which is where it
belongs. Make the new rule for drivers/net check for the build-stage
relevant ETH symbol.
Fix up some Kconfig dependencies while we're here to mirror how the
Makefile logic now works.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Introduce ETH, Kconfig dependency changes, am43xx fix]
Signed-off-by: Tom Rini <trini@konsulko.com>
