Increase rng-seed size to make Linux happy and initialize rng pool instantly.
Linux 5.19+ requires 32 bytes of entropy to initialize random pool, but u-boot
currently provides only 8 bytes.
Linux 5.18 and probably some versions before it used to require 64 bytes.
Bump min value to 64 bytes to be on a safe side.
Boot with 8 byte rng-seed (Linux 6.11):
# dmesg | grep crng
[ 12.089286] random: crng init done
Boot with 32 byte rng-seed (Linux 6.11):
# dmesg | grep crng
[ 0.000000] random: crng init done
Linux source references:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.19#n551https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.18#n236
Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Fixes: d2048bafae40 ("rockchip: board: Add board_rng_seed() for all Rockchip devices")
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/22989
- Remove unneeded USB board code and fix reset on mx6ul_14x14_evk.
- Update fastboot buffer size/address for verdin-imx8m{m|p}.
- Fix imxrt1050-evk boot and convert it to standard boot.
- Fix imx8qxp-mek and imx8qm-mek boot.
- Add support for the i.MX93 9X9 QSB board.
- Make livetree API to work on i.MX.
- Set sane default value for i.MX8M SPL_LOAD_FIT_ADDRESS.
- Deduplicate DH i.MX8MP/i.MX6 DHSOM defconfigs.
- Select default TEXT_BASE for i.MX6/i.MX7.
- Several updates for DH i.MX8MP DRC02.
U-Boot has a fairly rigid memory map which is normally not visible
unless debugging is enabled in board_f.c
Update the 'meminfo' command to show it. This command does not cover
arch-specific pieces but gives a good overview of where things are.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Hardkernel ODROID-M1S is a single-board computer based on Rockchip
RK3566 SoC. It features e.g. 4/8 GB LPDDR4 RAM, 64 GB eMMC, SD-card,
GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0.
Features tested on a ODROID-M1S 8GB rev1.0 20230906:
- SD-card boot
- eMMC boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Hardkernel ODROID-M2 is a single-board computer based on Rockchip
RK3588S2 SoC. It features e.g. 8/16 GB LPDDR5 RAM, 64 GB eMMC, SD-card,
GbE LAN, HDMI 2.0, M.2 NVMe and USB 2.0/3.0/Type-C.
Features tested on a ODROID-M2 16GB rev1.0 20240611:
- SD-card boot
- eMMC boot
- Ethernet
- PCIe/NVMe
- USB gadget
- USB host
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
To enhance code organization, it is beneficial to consolidate all A/B
BCB management routines into a single super-command.
The 'bcb' command is an excellent candidate for this purpose.
This patch integrates the separate 'ab_select' command into the 'bcb'
group as the 'ab_select' subcommand, maintaining the same parameter list
for consistency.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-3-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
WATCHDOG_RESET is no more. Replace the reference by schedule().
While here, rearrange the sentence a bit so that "cyclic_run()"
becomes the object and "the main function responsible for calling all
registered cyclic functions" a parenthetical rather than the other way
around, which at least to me makes it more readable.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Some I2C slave devices are read-only and don't even answer with NACK.
For example FD65x segment LED controllers.
Make them usable with i2c-gpio,sda-output-only that are already supported
by Linux 6.3+.
Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
At present menu items are stored according to their sequence number in
the menu. In some cases we may want to have holes in that sequence, or
not use a sequence at all.
Add a new 'value' property for menu items. This will be used for
reading and writing, if present. If there is no 'value' property, then
the normal sequence number will be used instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Set aside some expo IDs for 'save' and 'discard' buttons. This avoids
needing to store the IDs for these. Adjust the documentation and expo
tool for the new EXPOID_BASE_ID value.
Ignore these objects when saving and loading the cedit, since they do
not contain real data.
Adjust 'cedit run' to return failure when the user exits the expo
without saving. Update the test for this change as well.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present a fixed position is used for menu items, 200 pixels to the
right of the left side of the labels. This means that a menu item with
a very long label may overlap the items.
It seems better to calculate the maximum label width and then place the
items to the right of all of them.
To implement this, add a new struct to containing arrangement
information. Calculate it before doing the actual arrangement. Add a
new style item which sets the amount of space from the right side of
the labels to left side of the items.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a short description of how tests work, why they are so critical
and how to resolve gaps in Binman's test coverage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
It is useful to obtain the results of MSR queries as well as to update
MSR registers, so add a command these tasks.
Signed-off-by: Simon Glass <sjg@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQFNBAABCgA3FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmcSLuYZHGV1Z2VuLmhy
aXN0ZXZAbGluYXJvLm9yZwAKCRAesx4CDqwvyBeeB/9xoXcp4T1eVgKFfxLbaKqJ
6PQmvmp6D1aHE6+cW3KigZBeM6o80o24VfOMmseKmEACQJ2q9lkGHo2QoQV/LYVX
1x9AfjA7vMp3pCapulJJ6OGFeyLhq0guBfkJDR0Gb45V1+Zu0TS6IYGLytAzqYpj
22ysXajF0p2nhc7HjAnf9jWEHfD/QqEzTfNzSo0eMPQM5KgrR6QmrIZM/A0A+Jhi
hyEtaJV0YB3xKIN0MYZ2O49Pe6oscFznDN/v0w5v06rDW8X5vt/gim6ddUf2DmaR
hmnOP9oObY5VnLj5x4RdZ9M3pDRWSvBjrpx8EZSP5T3pWMqwPCibREblRm4R7loq
=JgV7
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-fixes-2025.01-a' of https://source.denx.de/u-boot/custodians/u-boot-at91
First set of u-boot-at91 fixes for the 2025.01 cycle:
This small set includes the maintainer e-mail update and a missing
header that was causing some build issues.
Fixed a variable that was incorrect during the calculation of fileblks.
Signed-off-by: Ken Kurematsu <k.kurematsu@nskint.co.jp>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
- stm32mp: Add script to install U-Boot from SD/eMMC to SPI NOR on DH STM32MP15xx
- stm32mp: Switch to using upstream DT on DH STM32 DHSOM
- stm32mp: Generate u-boot.itb using binman on DH STM32 DHSOM
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE56Yx6b9SnloYCWtD4rK92eCqk3UFAmcQ1JUACgkQ4rK92eCq
k3W+xQf+K0oBb8yTpVKSXW8quotu6r8XwrzvcWOpZVIIGpPpFoRa61feNcI5+Zrl
lvD3rBrD31PvvHC1wWPRsN3c+oJlnq7GQDPChix54rclgGJNd04zCnJ9QaST309F
yqr7w6Cx/AL6Fbcvxbv8FvQxyjgGrbchbJ4sHeD9AYABhV3Z0DuBaUttZorG6ZIO
23pxvK9X/dUJGmbmvKkMID3Ifxzum3HEaPf7n3HkFg1/bzICXSSjRUEAFBLWlQp5
7oiWLvHZDIefpC8zupewXYvRscsG9HOjSWhRUc8+zu4rK1bele/v4nig46nfrRSN
3RpimkKVvnJ2svV1cCLS2Mhq2V6SlQ==
=XS+7
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20241017' of https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/22732
- stm32mp: fix boot issue with OP-TEE
- stm32mp: Add script to install U-Boot from SD/eMMC to SPI NOR on DH STM32MP15xx
- stm32mp: Switch to using upstream DT on DH STM32 DHSOM
- stm32mp: Generate u-boot.itb using binman on DH STM32 DHSOM
This adds TCPM framework in preparation for fusb302 support, which can
handle USB power delivery messages. This is needed to solve issues with
devices, that are running from a USB-C port supporting USB-PD, but not
having a battery.
Such a device currently boots to the kernel without interacting with
the power-supply at all. If there are no USB-PD message replies within
5 seconds, the power-supply assumes the peripheral is not capable of
USB-PD. It usually takes more than 5 seconds for the system to reach
the kernel and probe the I2C based fusb302 chip driver. Thus the
system always runs into this state. The power-supply's solution to
fix this error state is a hard reset, which involves removing the
power from VBUS. Boards without a battery (or huge capacitors) will
reset at this point resulting in a boot loop.
This imports the TCPM framework from the kernel. The porting has
originally been done by Rockchip using hardware timers and the Linux
kernel's TCPM code from some years ago.
I had a look at upgrading to the latest TCPM kernel code, but that
beast became a lot more complex due to adding more USB-C features.
I believe these features are not needed in U-Boot and with multiple
kthreads and hrtimers being involved it is non-trivial to port them.
Instead I worked on stripping down features from the Rockchip port
to an even more basic level. Also the TCPM code has been reworked
to avoid complete use of any timers (Rockchip used SoC specific
hardware timers + IRQ to implement delayed work mechanism). Instead
the delayed state changes are handled directly from the poll loop.
Note, that (in contrast to the original Rockchip port) the state
machine has the same hard reset quirk, that the kernel has - i.e.
it avoids disabling the CC pin resistors for devices that are not
self-powered. Without that quirk, the Radxa Rock 5B will not just
end up doing a machine reset when a hard reset is triggered, but will
not even recover, because the CPU will loose power and the FUSB302
will keep this state because of leak voltage arriving through the RX
serial pin (assuming a serial adapter is connected).
This also includes a 'tcpm' command, which can be used to get
information about the current state and the negotiated voltage
and current.
Co-developed-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Clarify the usage of SCMI specific device tree to use with
stm32mp15_defconfig and with OP-TEE.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
:hile we had hoped to be able to remove these options finally, it was
missed that zynq still requires these currently.
This reverts commit 5b9261fb0b1ed087387f2036d279fd3f4bb20a61 and
commit 099b6df556c95f5d06864612e9199eab7ba50ed3.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR
support as there are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
We have previously added logic to allow a "fallback" option to be
specified in the extlinux configuration. Provide a command that allows
us to set this as the preferred default option when booting.
Combined with the bootcount functionality, this allows the "altbootcmd"
to provide a means of falling back to a previously known good state
after a failed update. For example, if "bootcmd" is set to:
bootflow scan -lb
We would set "altbootcmd" to:
bootmeth set extlinux fallback 1; bootflow scan -lb
Causing the boot process to boot from the fallback option.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
When configured correctly, we can detect when boot fails after the boot
process has been handed over to the kernel through the use of U-Boot's
bootcount support. In some instances, such as when we are performing
atomic updates via a system such as OSTree, it is desirable to provide a
fallback option so that we can return to a previous (hopefully working)
state.
Add a "fallback" option to the supported extlinux configuration options
that points to a label like "default" so that we can utilise this in
later commits.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for the Libre Computer aml-s905d3-cc "Solitude" board:
https://libre.computer/products/aml-s905d3-cc/
The Solitude board has a Credit Card form factor, similar to the
the previous "Le Potato" card, but with the Amlogic A311D SoC,
MIPI DSI and CSI connectors. PoE header and a single USB2 Type-C
connector replacing the microUSB one for power and USB 2.0.
The board has an embedded SPI NOR flash, and EFI Capsule support
is added.
The GUID is dynamically generated for the board, to get it:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=4302C3CB-2502-5EFE-87E0-894A8A322893
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
On the host (with the aml_encrypt_g12a result binary):
$ eficapsule --guid 4302C3CB-2502-5EFE-87E0-894A8A322893 -i 1 u-boot.bin u-boot.cap
On the board (from USB disk containing u-boot.cap at root):
=> load usb 0:1 $kernel_addr_r u-boot.cap
=> efidebug capsule update $kernel_addr_r
The binary will then be flashed on the SPI.
Link: https://lore.kernel.org/r/20240920-u-boot-topic-libre-computer-solitude-alta-v1-2-8915b108840b@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Add support for the Libre Computer aml-a311d-cc "Alta" board:
https://libre.computer/products/aml-a311d-cc/
The Alta board has a Credit Card form factor, similar to the
the prvevious "Le Potato" card, but with the Amlogic A311D SoC,
MIPI DSI and CSI connectors. PoE header and a single USB2 Type-C
connector replacing the microUSB one for power and USB 2.0.
The board has an embedded SPI NOR flash, and EFI Capsule support
is added.
The GUID is dynamically generated for the board, to get it:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=17E07D9D-4D91-53F4-8780-1D91F279C1A5
ESRT: fw_type=unknown
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================
On the host (with the aml_encrypt_g12a result binary):
$ eficapsule --guid 17E07D9D-4D91-53F4-8780-1D91F279C1A5 -i 1 u-boot.bin u-boot.cap
On the board (from USB disk containing u-boot.cap at root):
=> load usb 0:1 $kernel_addr_r u-boot.cap
=> efidebug capsule update $kernel_addr_r
The binary will then be flashed on the SPI.
Link: https://lore.kernel.org/r/20240920-u-boot-topic-libre-computer-solitude-alta-v1-1-8915b108840b@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Assorted Tegra enhancements. Merged with the recent XPL_BUILD changes,
resolve some whitespace issues and fix the name of the new apalis-tk1
env file by Tom.
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Complete this rename for all directories outside arch/ board/ drivers/
and include/
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the various references to SPL in this document. Make sure to
refer to 'phases' instead of 'stages', which is not a U-Boot term.
Fix a few U-boot typos and try to improve grammar a little while we are
here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Christian Marangi <ansuelsmth@gmail.com> says:
This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function
This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.
One thing that many device need is a way to communicate to the
user that the device is actually doing something.
This is especially useful for recovery steps where an
user (for example) insert an USB drive, keep a button pressed
and the device autorecover.
There is currently no way to signal the user externally that
the bootloader is processing/recoverying aside from setting
a LED on.
A solid LED on is not enough and won't actually signal any
kind of progress.
Solution is the good old blinking LED but uboot doesn't
suggest (and support) interrupts and almost all the LED
are usually GPIO LED that doesn't support HW blink.
Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.
A documentation for old and these new LED API is created.
Introduce simple led.rst documentation to document all the additional
Kconfig and the current limitation of LED_BLINK and GPIO software blink.
Also add missing definition for sw_blink in led_uc_plat struct.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is not actually a command so the name is confusing. Use
BOOTEFI_HELLO_COMPILE instead. Put it in the efi_loader directory
with the other such config options.
The link rule (for $(obj)/%_efi.so) in scripts/Makefile.lib handles
pulling in efi_crt0.o and efi_reloc.o so drop the 'extra' rules.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
