The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Add mvebu_espressobin_ultra-88f3720_defconfig (Benjamin)
- Update DTS for Thecus N2350 board (Tony)
- Add "old" Marvell DDR3 training for Armada 38x and Turris Omnia
(Marek)
- Misc turris_omnia changes (Marek)
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/21504
- Fixes for i.MX8M and i.MX93 clk-composite.
- Set CAN oscillator frequency based on model on verdin-imx8mm.
- Enable CAAM for phycore-imx8mp_defconfig.
- Miscellaneous improvements for Gateworks i.MX8M boards.
- Fix initramfs boot on msc_sm2s_imx8mp.
- Fixe EQoS on imx8mp-beacon-kit.
- Fix error message in fsl_esdhc_imx.
Currently, Armada 8k config header is setting boot devices and including
<config_distro_bootcmd.h> regardless of the CONFIG_DISTRO_DEFAULTS being
enabled or not, thus populating the environment for distro boot even on
devices that have no need for it.
So, lets simply respect the value of CONFIG_DISTRO_DEFAULTS.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Make public the clk_fetch_parent_index and rename it. This allow
us to be reused in driver specialization
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Booting an initramfs with the current initrd_addr address may lead to
initramfs corruption and boot failure.
Fix the initramfs problem by applying the following layout
suggested by Tom Rini:
loadaddr=0x40480000 --> Gets moved to 0x40600000 in run-time:
Uncompressing Kernel Image
Moving Image from 0x40480000 to 0x40600000, end=41e80000
fdt_addr_r= moved loadaddr + 128 MiB = 0x48600000
initrd_addr=fdt_addr_r + 512 KiB = 0x48680000
Signed-off-by: Fabio Estevam <festevam@denx.de>
Tested-by: Stefano Babic <sbabic@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
This patch fixes the I225 hardware default value
at 0x15FD meaning empty flash image
or the NVM configuration loading failed
Signed-off-by: Marjolaine Amate <marjolaine.amate@odyssee-systemes.fr>
This patch adds support for Intel Foxville I226
devices LM,V,I,K in e1000 driver.
Signed-off-by: Marjolaine Amate <marjolaine.amate@odyssee-systemes.fr>
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com>
Various minor fixes and improvements:
* Fix Qualcomm SPMI v5 support
* Move default environment to a file
* Add support for special pins (e.g ufs/mmc reset/data pins)
* IPQ moves to OF_UPSTREAM and receives some cleanup and MAINTAINERS
changes
* Add a reset driver for devices without PSCI
* msm8916 USB clock improvements for mobile devices
Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
environment to a file under board/qualcomm.
This is much cleaner and means we don't need to recompile on changing
the environment.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The Lenovo IdeaPad Yoga 11 is a hybrid laptop/tablet Windows RT-based
computer released in late 2012. The device uses a 1.3 GHz quad-core
Nvidia Tegra 3 chipset with 2 GB of RAM, features a 11.6 inch 1366x768
screen and 32/64 GB of internal memory that can be supplemented with
a microSDXC card slot, full size SD card slot and 2 full size USB 2.0
ports.
Tested-by: Jethro Bull <jethrob@hotmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Surface RT is a hybrid tablet computer developed and manufactured
by Microsoft and shipped with Windows RT. The tablet uses a 1.3 GHz
quad-core Nvidia Tegra 3 chipset with 2 GB of RAM, features 10.8
inch 1366x768 screen and 32/64 GB of internal memory that can be
supplemented with a microSDXC card giving up to 200 GB of
additional storage.
Tested-by: Jethro Bull <jethrob@hotmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
WEXLER Tab 7t is a mini tablet computer developed by WEXLER that
runs the Android operating system. The device features a 7.0-inch
(180 mm) HD display, an Nvidia Tegra 3 quad-core chip, 1 GB of RAM,
8, 16 or 32 GB of storage that can be supplemented with a microSDXC
card giving up to 64 GB of additional storage and a full size USB
port.
Tested-by: Maksim Kurnosenko <asusx2@mail.ru>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
The Asus Eee Pad Transformer family are 2-in-1 detachable/slider
tablets developed by Asus that run the Android operating system.
The Eee Pad Transformers feature a 10.1-inch (260 mm) display,
an Nvidia Tegra 2 dual-core chip, 1 GB of RAM, and 16/32 GB of storage.
Transformers board derives from Nvidia Ventana development board.
This patch brings support for all 3 known T20 Transformers:
- Asus Eee Pad Transformer TF101
- Asus Eee Pad Transformer TF101G
- Asus Eee Pad Slider SL101
Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101
Tested-by: Antoni Aloy Torrens <aaloytorrens@gmail.com> # ASUS TF101
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
This ensures that the device can boot from a USB device prior to MMC. Useful
cases are when installing a new OS from USB while MMC still has a working OS
configuration or if the OS configuration is broken in late boot stages
(kernel boots but the system does not start).
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
Hi all,
This series enabled qemu-xtensa board.
For dc232b CPU it needs to be built with toolchain[1].
This is a side product of me investigating architectures
physical address != virtual address in U-Boot. Now we can
get it covered under CI and regular tests.
VirtIO devices are not working as expected, due to U-Boot's
assumption on VA == PA everywhere, I'm going to get this fixed
later.
My Xtensa knowledge is pretty limited, Xtensa people please
feel free to point out if I got anything wrong.
Thanks
[1]: https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc232b-elf.tar.gz
The dm_root_f field seems to be entirely write-only and hence
redundant, unless 'git grep' fails to find some access generated via
preprocessor token concatenation or similar.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
This series brings our zlib code more up to date. However, it drops an
important performance improvement that is required on some of our
supported platforms in order to boot Linux before the watchdog resets
the system. Furthermore, the "post increment" version of this
performance loop was not tested, so while we can fix it, it would then
require re-testing all platforms. At this point in time, we will revert
updating zlib (which has had a potential security issue since 2016) and
fix this in the v2024.10 release.
This reverts commit 4914263c9a, reversing
changes made to ef8ef5f77c.
Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Tom Rini <trini@konsulko.com>
Documentation:
Update requirements.txt to use current Python module versions
Add a page describing debugging U-Boot with GDB
FIT: describe data-size as a conditionally mandatory property
Correct link to FIT specification in SPL code.
Correct kaslrseed command long text description
UEFI:
Add unit test checking that don't have kaslr-seed when measuring boot
Deduplicate code for measured boot.
Other:
Print size information in fwu command
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmaBU44ACgkQhO4vgnE3
U0s1JRAAgyxfK6mjgS0rGI3wBv9N9twxYm/+2XcBFxqywcazuls31uNs+XO+U14u
pS73qzRn4gempz8FxOEjlEhzN4ycEjlR1zpO39Z21/wq1TSGSVjnRPmGnBx5t19Y
wxtptXr1A8mnaoqv3A3seEepC3/PDNSANjo/euHwHruepVM+f9VdotqVbr4Y4kFM
qYHuIBKawjMWDy8BB0HlbMgGDDanZZKbXjus8h0RVrbHQePUgAiztZ5bQCRSp9A7
uFNVvuIKSl2SUQ3kHIL9pwYhRCOXaNTSCsyiaxwfAMkhK9Em6QP2647ddvNNKAw2
V4EUf52lTUnd527iLqjvEvKcGcrVNCoYWsKtuRS8YHk/2jn7BjPY/bHW8MCiWN3Z
sG48Cqbq+fVG0+Qk2/I68kvGYGh4S4f9AeNihtQRXaxDzrLk1jBESakzUXI52ub3
YK+aZ83t232n9pyXZe855Qxpcp5HLfg6ZtdjnB/Oqp7NpSpuPeo8FmFwZ2Nz/+5u
qk29LwA5U8gO3N3qbwjIt7FpjlYuYyo8A3kiZttOy9epSM+0YrHx7V+dx8RJPKrD
a1NT1dONWL2QhoYC5788o/L+WPJprEy38aY3LYrbdtxlbqoTV1RRg5/RVfD6D6vk
lVR+RP/l/5iCa6nw5Cls6DZcMgV7DyCtyp0uMTJDVe7L62qhBFk=
=7g5n
-----END PGP SIGNATURE-----
Merge tag 'efi-2024-10-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request efi-2024-10-rc1
Documentation:
Update requirements.txt to use current Python module versions
Add a page describing debugging U-Boot with GDB
FIT: describe data-size as a conditionally mandatory property
Correct link to FIT specification in SPL code.
Correct kaslrseed command long text description
UEFI:
Add unit test checking that don't have kaslr-seed when measuring boot
Deduplicate code for measured boot.
Other:
Print size information in fwu command
Simon reports that after enabling all algorithms on the TPM some boards
fail since they don't have enough storage to accommodate the ~5KB growth.
The choice of hash algorithms is determined by the platform and the TPM
configuration. Failing to cap a PCR in a bank which the platform left
active is a security vulnerability. It might allow unsealing of secrets
if an attacker can replay a good set of measurements into an unused bank.
If MEASURED_BOOT or EFI_TCG2_PROTOCOL is enabled our Kconfig will enable
all supported hashing algorithms. We still want to allow users to add a
TPM and not enable measured boot via EFI or bootm though and at the same
time, control the compiled algorithms for size reasons.
So let's add a function tpm2_allow_extend() which checks the TPM active
PCRs banks against the one U-Boot was compiled with. We only allow
extending PCRs if the algorithms selected during build match the TPM
configuration.
It's worth noting that this is only added for TPM2.0, since TPM1.2 is
lacking a lot of code at the moment to read the available PCR banks.
We unconditionally enable SHA1 when a TPM is selected, which is the only
hashing algorithm v1.2 supports.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-link
This function was used on measured boot to retrieve the number of active
PCR banks and was designed to work with the TCG protocols.
Since we now have the need to retrieve the active PCRs outside the
measured boot context -- e.g use the in the command line, decouple the
function.
Create one that will only adheres to TCG TSS2.0 [0] specification called
tpm2_get_pcr_info() which can be used by the TPM2.0 APIs and a new one that
is called from the measured boot context called tcg2_get_pcr_info()
[0] https://trustedcomputinggroup.org/wp-content/uploads/TSS_Overview_Common_Structures_Version-0.9_Revision-03_Review_030918.pdf
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The previous patch is moving the TPM TCG headers in their own file for
a cleaner API. Move the functions in their own file as well.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
commit 97707f12fd ("tpm: Support boot measurements") moved out code
from the EFI subsystem into the TPM one to support measurements when
booting with !EFI.
Those were moved directly into the TPM subsystem and in the tpm-v2.c
library. In hindsight, it would have been better to move it in new
files since the TCG2 is governed by its own spec, it's overeall cleaner
and also easier to enable certain parts of the TPM functionality.
So let's start moving the headers in a new file containing the TCG
specific bits.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
commit 97707f12fd ("tpm: Support boot measurements") moved some of the
EFI TCG code to the TPM subsystem. Those definitions are now in tpm-v2.h.
Let's remove the stale entries
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tim Harvey <tharvey@gateworks.com> says:
This series will automatically add /chosen/kaslr-seed to the dt if
DM_RNG is enabled
during the boot process.
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to overwrite
the node if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Akash Gajjar <gajjar04akash@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Devarsh Thakkar <devarsht@ti.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Drop redundant header imports with dts/upstream already providing
updated headers which have been checked to be backwards compatibility.
The imx headers which aren't present in dts/upstream are as follows:
- include/dt-bindings/clock/imxrt1020-clock.h
- include/dt-bindings/clock/imx8qm-clock.h
- include/dt-bindings/clock/imxrt1170-clock.h
- include/dt-bindings/clock/imx8qxp-clock.h
- include/dt-bindings/memory/imxrt-sdram.h
- include/dt-bindings/pinctrl/pads-imx8qxp.h
- include/dt-bindings/pinctrl/pads-imx8qm.h
- include/dt-bindings/soc/imx8_pd.h
- include/dt-bindings/soc/imx_rsrc.h
hence these aren't dropped yet but there was an unused header:
- include/dt-bindings/pinctrl/pins-imx8mq.h
which has been dropped as well. There shouldn't be any funtional impact
with this change but it rather allows iMX platforms to use upstream
dt-bindings headers in a backwards compatible manner.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Quentin Schulz <foss+uboot@0leil.net> says:
bootflow menu currently crashes U-Boot with a NULL pointer dereference
because bootflow->dev is NULL for global bootmeths (such as EFI BOOTMGR).
Therefore, let's check if the bootflow is associated with a global
bootmeth before trying to make it part of the menu.
While this makes U-Boot not crash anymore, bootflow menu doesn't work
for me (I have never had a happy path with it, but I haven't actually
tried it before today :) ) and this was basically just implemented
following Simon's suggestion sent over IRC. No clue if this is enough or
just a quick band-aid patch.
This also fixes typos in multiple places.
The global bootmeths don't set the dev in bootflow struct which means
the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and
crash U-Boot.
So before trying to handle a bootflow, check that the associated
bootmeth isn't global, otherwise skip it.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Code is pretty much supports only DT properties and completely ignore
information coming from sysinfo driver.
Code is calling smbios_add_prop() which calls with
smbios_add_prop_si(SYSINFO_ID_NONE). But SYSINFO_ID_NONE can't
differentiate different entries from sysinfo driver.
That's why introduce separate SYSINFO macros which can be used in sysinfo
driver and passed to smbios structure.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Jayesh Choudhary <j-choudhary@ti.com> says:
Hello there,
This series add the U-Boot support for our new platform of K3-SOC
family - J722S-EVM which is a superset of AM62P. It shares the same
memory map and thus the nodes are being reused from AM62P includes
instead of duplicating the definitions.
Some highlights of J722S SoC (in addition to AM62P SoC features) are:
- Two Cortex-R5F for Functional Safety or general-purpose usage and
two C7x floating point vector DSP with Matrix Multiply Accelerator
for deep learning.
- Vision Processing Accelerator (VPAC) with image signal processor
and Depth and Motion Processing Accelerator (DMPAC).
- 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
4xCSI-RX for Camera, 1 PCIe Gen3 controller, USB3.0 eCAP/eQEP,
ePWM, among other peripherals.
TRM: <https://www.ti.com/lit/zip/sprujb3>
Schematics: <https://www.ti.com/lit/zip/sprr495>
Boot test log:
<https://gist.github.com/Jayesh2000/0313e58fde377f877a9a8f1acc2579ef>
Introduce the initial configs needed to support the J722S SoC family.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Include the clock and lpsc tree files needed for the wkup spl to
initialize the proper PLLs and power domains to boot the SoC.
Reviewed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM69
SK.
TODO: possibly make the struct's sk specific.
TODO: add doc commit (and make sure doc is sk/NOR specific, and add OSIP
boot mode)
TODO: update doc to show sk defconfig when building
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
BeagleBoneAI64.
Note this involved creating BeagleBoneAI64's own beagleboneai64.h board
header file instead of reusing j721e_evm's.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM62px
SK.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM62x
SK.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
BeaglePlay.
Note this involved creating BeaglePlay's own beagleplay.h board header file
instead of reusing am62_evm's.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the
SK-TDA4VM.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Define the firmware components updatable via EFI capsule update, including
defining capsule GUIDs for the various firmware components for the AM64x
SK.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
