We can determine which of these we need given CPU_BIG_ENDIAN being
enabled or not, so move that logic to Kconfig from config.mk.
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS
CONFIG_SYS_FSL_OTHER_DDR_NUM_CTRLS
And we remove the entries from the README for a number of already
converted items.
Signed-off-by: Tom Rini <trini@konsulko.com>
To reduce code duplication, let the stm32 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
To reduce code duplication, let the imx8 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
To reduce code duplication, let the imx6 based DH boards use the common
code for setting up their MAC addresses.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
This is a starting point for unifying duplicate code in the DH board
files. The functions for setting up MAC addresses are very similar for
the i.MX6, i.MX8 and stm32mp1 based boards.
All pre-existing implementations follow the same logic:
(1) Check if ethaddr is already set in the environment
(2) If not, try to get it from a board specific location (e.g. fuse)
(3) If not, try to get it from eeprom
After this commit, (1) and (3) are implemented as common functions,
ready to be used by board specific files.
Furthermore there is an implementation of (2) for imx based boards.
Signed-off-by: Philip Oberfichtner <pro@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
As per https://github.com/actions/runner-images/issues/6002 the Ubuntu
18.04 image is deprecated and will be removed by December 1, 2022.
Move to the Ubuntu 22.04 image as our base for launching our containers
from.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To quote Simon:
This adds the concept of a VBE method to U-Boot, along with an
implementation of the 'VBE simple' method, basically a simple way of
updating firmware in MMC from userspace and monitoring it from U-Boot.
VBE simple is implemented in fwupd. U-Boot's role is to set up the
device tree with the required firmware-update properties and provide the
developer with information about the current VBE state. To that end this
series includes a new 'vbe' command that allows VBE methods to be listed
and examined.
As part of this work, support for doing FDT fixups via the event interface
is provided, along with the ability to write to the device tree via the
ofnode interface.
Another (significant) change is that bootmeths now have a 'global' flag,
to allow the implementation of EFI bootmgr (and VBE) to be cleaned up.
The 'system' bootdev is no-longer needed and these bootmeths are scanned
first.
Further work is needed to pull everything together, but this is a step
along the way.
Use the sandbox_flattree build to check that everything works correctly
with BOOTMETH_GLOBAL disabled.
Update the tests as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update sandbox to include the VBE bootmeth. Update a few existing tests to
take account of this change, specifically that the new bootmeth now
appears when scanning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for VBE simple, which permits firmware update of a single
image stored in MMC or another block device.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is a confusing array of functions that handle the
device tree fix-ups needed for booting an OS. We should be able to switch
to using events to clean this up.
As a first step, create a new event type and call it from the standard
place.
Note that this event uses the ofnode interface only, since this can
support live tree which is more efficient when making lots of updates.
Signed-off-by: Simon Glass <sjg@chromium.org>
This creates static records at present, but it causes a problem with clang
and LTO: the linker list records are sometimes dropped from the image.
Fix this by making the records global.
Update to use __used while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This was a work-around for the fact that global bootmeths such as EFI
bootmgr and VBE don't use a particular bootdev, or at least select it
themselves so that we don't need to scan all bootdevs when using that
bootmeth.
Drop the system bootdev entirely.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that we can separate this out from the normal bootmeths, update the
code to create it always.
We cannot rely on the device tree to create this, since the EFI project
is quite opposed to having anything in the device tree that helps U-Boot
with its processing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Typically we want to find and use global bootmeths first, since they have
the best idea of how the system should boot. We then use normal bootmeths
as a fallback.
Add the logic for this, putting global bootmeths at the end of the
ordering. We can then easily scan the global bootmeths first, then drop
them from the list for subsequent bootdev-centric scans.
This changes the ordering of global bootmeths, so update the
bootflow_system() accordingly.
Drop the comment from bootmeth_setup_iter_order() since this is an
exported function and it should be in the header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this function is not called, so tests miss out on any devices
created by it. Add it in so that tests can rely on these extra devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for handling this concept in bootflows. Update the 'bootflow'
command to allow only the normal bootmeths to be used. This alllows
skipping EFI bootmgr and VBE, for example.
Signed-off-by: Simon Glass <sjg@chromium.org>
With global bootmeths we want to scan without a bootdev. Update the logic
to allow this.
Change the bootflow command to show the bootdev only when valid.
Signed-off-by: Simon Glass <sjg@chromium.org>
For most testing we don't want this bootmeth to actually do anything. For
the one test where we do, add a test hook to obtain the correct behaviour.
This will allow us to bind the device always, rather than just doing it
for this test.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current way of handling things like EFI bootmgr is a bit odd, since
that bootmeth handles selection of the bootdev itself. VBE needs to work
the same way, so we should support it properly.
Add a flag that indicates that the bootmeth is global, rather than being
invoked on each bootdev. Provide a helper to read a bootflow from the
bootmeth.
Signed-off-by: Simon Glass <sjg@chromium.org>
Avoid using 'count' to mean either a count or an error, since this is
confusing. In fact, the called function never return 0, since that is an
error.
Use 'ret' instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some bootmeths can provide information about what is available to boot.
For example, VBE simple provides access to the firmware state.
Add a new method for this, along with a sandbox test.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the ordering produces no entries, this is an error. Report it, so that
the caller doesn't try to continue with a NULL bootmeth.
This fixes a crash in the bootflow_iter test when running with the sandbox
'default' device tree, instead of the required 'test' one.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some tests go as far as booting a distribution. In this case a menu is
presented to the user, with a two-second timeout. This adds a total of
12 seconds to the test runs at present.
Avoid this by inserting a response using the console-recording feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
In generally it is not permitted to implement an ofnode function only for
flat tree or live tree. Both must be supported. Also the code for
live tree access should be in of_access.c rather than ofnode.c which is
really just for holding the API-conversion code.
Update ofnode_write_prop() accordingly and fix the test so it can work
with flat tree too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some documentation and a new flag so that we can safely enabled using
the ofnode interface to write to the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this test to use the livetree flag so that special check can be
avoided. Also drop a few blank lines.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present ofnode only works with a single device tree, for the most part.
This is the control FDT used by U-Boot.
When booting an OS we may obtain a different device tree and want to
modify it. Add some initial support for this into the ofnode API.
Note that we don't permit aliases in this other device tree, since the
of_access implementation maintains a list of aliases collected at
start-up. Also, we don't need aliases to do fixups in the other FDT. So
make sure that flat tree and live tree processing are consistent in this
area.
Signed-off-by: Simon Glass <sjg@chromium.org>
The unflattening algorithm results in a single block of memory being
allocated for the whole tree. When writing new properties, these are
allocated new memory outside that block. When the block is freed, the
allocated properties remain.
Document how this works and the potential memory leak, as well as
mentioning that updating the livetree is actually supported now.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is used by a lot of files, but ofnode.h needs to include a lot of
header files. This can create dependency cycles, particularly with
global_data.h which must include various declarations.
Split the core delcarations into a separate file to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rename these to VESA, itself an abbreviation, to avoid a conflict with
Verified Boot for Embedded.
Rename this to avoid referencing VBE.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to use VBE to mean Verfiied Boot for Embedded in U-Boot. Rename
the existing VBE (Vesa BIOS extensions) to allow this.
Verified Boot for Embedded is documented doc/develop/vbe.rst
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a few links to documents about Verified Boot for Embedded (VBE).
These will be expanded as development proceeds.
Signed-off-by: Simon Glass <sjg@chromium.org>
