Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization is not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
This patch also removes CONFIG_LMB_XXX dependency on CONFIG_LMB as these
defines are used in API file lmb.h and not only in library file.
Fixes: 5e2548c1d6 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard <marklmi@yahoo.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Michal Simek <michal.simek@amd.com>
On mpc832x, SPI can be either handled by CPU or QE.
In order to work in CPU mode, bit 17 of SPMODE has to
be set to 1, that bit is called OP.
Also, data is located at a different place than the one expected
by the driver today. In 8 bits mode with REV set, data to be
transmitted is located in the most significant byte while
received data is located in second byte. So perform the
necessary shifts.
In order to differentiate with other CPUs, a new compatible is
added for mpc832x: fsl,mpc832x-spi
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
The mpc832x has GPIOs handled by the QUICC Engine.
The registers are different from the one for the
non QE mpc83xx GPIOs.
Implement a GPIO driver for those.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
gd->arch.sdhc_clk only exists when CONFIG_FSL_ESDHC is set,
so enclose it inside ifdefs.
gd->arch.qe_clk and gd->arch.brg_clk must be populated when
CONFIG_QE is set.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
At startup, some RAM is needed (for instance for stack) before
DRAM is initialised.
One way to offer such RAM, used by mpc83xx, is to lock some entries
in the cache. To do that, MMU needs to be activated.
On mpc83xx having a QUICC Engine an alternative is to user some
part of from the Multi User RAM, like done on mpc8xx for instance.
For that, the MMU is not needed.
Activating the MMU is problematic because exception vectors are not
setup yet so in case of ISI or DSI that CPU will crash and reboot.
At the time being, MMU is activated regardless.
Only activate it when locking cache entries to provide initial RAM.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
There are helpers included in soc.h
Declare them static inline so that soc.h can be
included in several places.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
According to the reference manual, the Reset Configuration
Word Low Register bits 2-3 must be set to 0b10.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Introduce a new compatible "fsl,pq2pro-wdt"
On mpc83xx, the prescaling factor is 0x10000.
Don't write the watchdog configuration register in
start.S as it can be written only once.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
mpc8xx, mpc83xx and mpc86xx have similar watchdog with almost same
memory registers.
Refactor the driver to get the register addresses from the
device tree and use the compatible to know the prescale factor.
Calculate the watchdog setup value from the provided timeout.
Don't declare it anymore as an HW_WATCHDOG, u-boot will start
servicing the watchdog early enough.
On mpc8xx the watchdog configuration register is also used for
configuring the bus monitor. So add it as an option to the watchdog
when it is mpc8xx. When watchdog is not selected, leave the
configuration of the initial SYPCR from Kconfig.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
To quote the author:
Block maps are a way of looking at various sources of data through the
lens of a regular block device. It lets you treat devices that are not
block devices, like RAM, as if they were. It also lets you export a
slice of an existing block device, which does not have to correspond to
a partition boundary, as a new block device.
This is primarily useful because U-Boot's filesystem drivers only
operate on block devices, so a block map lets you access filesystems
wherever they might be located.
The implementation is loosely modeled on Linux's "Device Mapper"
subsystem, see the kernel documentation [1] for more information.
The primary use-cases are to access filesystem images stored in RAM, and
within FIT images stored on disk. See doc/usage/blkmap.rst for more
details.
The architecture is pluggable, so adding other types of mappings should
be quite easy.
[1]: https://docs.kernel.org/admin-guide/device-mapper/index.html
mpc8xx, mpc83xx and mpc86xx have similar watchdog with almost same
memory registers.
Rename it mpc8xxx which is the generic name used for drivers supporting
several mpc families.
The driver will be made more generic in following patch.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
8xx has CONFIG_8xx_GCLK_FREQ which is similar to
CONFIG_SYS_CLK_FREQ, and doesn't set CONFIG_SYS_CLK_FREQ.
Due to that, get_board_sys_clk() returns 0.
Remove CONFIG_8xx_GCLK_FREQ and use CONFIG_SYS_CLK_FREQ instead.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Create a distinct EFI device path for each blkmap device.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Explain block maps by going through two common use-cases.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Verify that:
- Block maps can be created and destroyed
- Mappings aren't allowed to overlap
- Multiple mappings can be attached and be read/written from/to
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a frontend for the blkmap subsystem. In addition to the common
block device operations, this allows users to create and destroy
devices, and map in memory and slices of other block devices.
With that we support two primary use-cases:
- Being able to "distro boot" from a RAM disk. I.e., from an image
where the kernel is stored in /boot of some filesystem supported
by U-Boot.
- Accessing filesystems not located on exact partition boundaries,
e.g. when a filesystem image is wrapped in an FIT image and stored
in a disk partition.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Allow a slice of an existing block device to be mapped to a
blkmap. This means that filesystems that are not stored at exact
partition boundaries can be accessed by remapping a slice of the
existing device to a blkmap device.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Allow a slice of RAM to be mapped to a blkmap. This means that RAM can
now be accessed as if it was a block device, meaning that existing
filesystem drivers can now be used to access ramdisks.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
blkmaps are loosely modeled on Linux's device mapper subsystem. The
basic idea is that you can create virtual block devices whose blocks
can be backed by a plethora of sources that are user configurable.
This change just adds the basic infrastructure for creating and
removing blkmap devices. Subsequent changes will extend this to add
support for actual mappings.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Ensure that the memory destination/source addresses of block
read/write operations are mapped in before access. Currently, this is
only needed on sandbox builds.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update the script loading code to recognize when script data is stored
externally from the FIT metadata (i.e., built with `mkimage -E`).
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
mkbootimg tool is part of the Android project and it is
used to pack Android boot images such as boot image
and vendor_boot image.
Use the following command to run mkbootimg:
$ python3 -m mkbootimg
Add mkbootimg to the docker file
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
test_abootimg is extended to include the testing of boot images
version 4. For this, boot.img and vendor_boot.img have been
generated using mkbootimg tool with setting the header
version to 4.
This tests:
- Getting the header version using abootimg
- Extracting the load address of the dtb
- Extracting the dtb start address in RAM
Running test:
$ ./test/py/test.py --bd sandbox --build -k test_abootimg
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Update the Android documentation to describe version 3 and 4 of boot
image header.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Enable the support for boot image header version 3 and 4
using abootimg command.
In order to use version 3 or 4:
1- Vendor boot image address should be given to abootimg cmd.
abootimg addr $1 $vendor_boot_load_addr
2- "ramdisk_addr_r" env variable (ramdisk address) should be set to host
the ramdisk : generic ramdisk + vendor ramdisk
Replace "struct andr_boot_img_hdr_v0*" by "void *" in
some functions since v3 and v4 are now supported as well.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
With vendor boot image introduced in version 3 and 4 of boot
image header, boot information is located in both boot image
and vendor boot image.
Flashing zImage is not supported for version 3 and 4 since this
requires updating vendor boot image and/or generating a new image.
Print an error message when the boot image header version is
greater than 2.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Add support for boot image version 3 and 4 in
android_image_get_dtb_img_addr().
Since the dtb is now included in vendor_boot image
instead of boot image, extract the dtb address from
vendor_boot image when a v3 or v4 is used.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
In version 3 and 4 of boot image header, the vendor specific
command line are located in vendor boot image. Thus, use
extra command line to add those cmd to bootargs.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Version 3 and 4 of boot image header introduced
vendor boot ramdisk: Please check include/android_image.h
for details.
The ramdisk is now split into a generic ramdisk in boot image
and a vendor ramdisk in vendor boot image.
Support the new vendor ramdisk.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Since boot image header version 3 and 4 introduced vendor boot image,
use the following functions to fill the generic android
structure : andr_image_data:
- android_boot_image_v3_v4_parse_hdr()
- android_vendor_boot_image_v3_v4_parse_hdr()
Update android_image_get_data() to support v3 and v4
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Introduce vendor boot image for version 3 and 4 of boot image header.
The vendor boot image will hold extra information about kernel, dtb
and ramdisk.
This is done to prepare for boot image version 3 and 4 support.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
android_image_get_dtbo() is used to get recovery DTBO via abootimg cmd.
This is not supported in boot image header v3 and v4. Thus, print an
error message when v1,v2 header version are not used.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Content print is not supported for version 3 and 4 of boot image header.
Thus, only print that content when v2 is used.
Update android_print_contents() to print an error message
when trying to print boot image header version 3 or 4 content.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Move from andr_boot_img_hdr_v0 to andr_image_data
structure to prepare for boot image header
version 3 and 4.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
andr_image_data structure is used as a global representation of
boot image header structure. Introduce this new structure to
support all boot header versions : v0,v1.v2.v3.v4 and to support
v3 and v4 while maitaining support for v0,v1,v2.
The need of using andr_image_data comes from the change of header
structure in both version 3 and 4.
Rework android_image_get_kcomp() to support this new struct.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
With the new vendor boot image introduced in versions 3 and 4
of boot image header, the header check must be done for both boot
image and vendor boot image. Thus, replace android_image_check_header()
by is_android_boot_image_header() to only refer to boot image header check.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Vendor boot image is introduced in boot image header
version 3 and 4. Please check [1] for more details.
To prepare for boot image v3/v4 support, allow the abootimg command
to store the vendor_boot image address.
Full support for this new format will be done in a future patch.
Link:[1] https://source.android.com/docs/core/architecture/bootloader/partitions/vendor-boot-partitions
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Android introduced boot header version 3 or 4.
The header structure change with version 3 and 4 to support
the new updates such as:
- Introducing Vendor boot image: with a vendor ramdisk
- Bootconfig feature (v4)
Change andr_img_hdr struct name to maintain support for version v0,
v1 and v2 while introducing version 3 and 4.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
- Update our CI to use clang-16 for tests. This also changes slightly
how we do linker lists so that we don't rely on undefined behavior
that lead to clang-15 and later failing to work (and in some cases
seemingly, earlier versions of clang would sometimes fail).
As this is now the stable release, move to using that now for our tests.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Per the GCC bug listed below, the way we do linker lists is relying on
undefined behavior that seems to work in gcc, but doesn't always work in
clang. Andrew suggests rewriting our start/end macros in a different way
(as implemented here, from what he said in comment 1) to avoid these
problems.
Reported-by: AdityaK <appujee@google.com>
Suggested-by: Andrew Pinski <apinski@marvell.com>
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andrew Pinski <apinski@marvell.com>
In order to prepare for slight size growth due to reworking linker list
support, enable LTO here to save more space again.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Given the number of jobs in CI we have which use python and pip install
packages, we should do this once in the Dockerfile, in order to populate
the cache. We let each job continue to create and use the virtual
environments they need to facilitate making updates to these
environments easier.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to better make use of pip caches, and also for better overall
consistency, we should use the same versions of packages in each of our
python requirements files. Update pytest to use the newer versions of
packages we use in sphinx builds.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
