| Age | Commit message (Collapse) | Author |
|---|
|
The BootROM in Rockchip SoCs will enter maskrom mode when boot firmware
cannot be found in nand/spi/mmc storage.
In maskrom mode the USB OTG port can accept one of two custom commands.
Initially a 0x471 command to load TPL into SRAM. After TPL has been
executed and it has returned back-to-BROM, a 0x472 command to load SPL
into start of DRAM.
Add two binman images that can be used to RAM boot from maskrom mode:
- u-boot-rockchip-usb471.bin that contains TPL to init DRAM.
- u-boot-rockchip-usb472.bin that contains SPL and the normal FIT
payload with i.e. U-Boot proper, TF-A and FDT.
A config fragment rockchip-ramboot.config can be used to enable building
of these two binman images, e.g.:
make generic-rk3588_defconfig rockchip-ramboot.config
These binman images can be used with the proprietary rkbin boot_merger
tool to create a special loader image that can be used with tools such
as rkdeveloptool or rockusb tools to RAM boot from maskrom, e.g.:
Create loader image:
$ ../rkbin/tools/boot_merger ./RK3588MINIALL.ini
Boot from maskrom:
$ rkdeveloptool db u-boot-rockchip-rk3588-loader.bin
or
$ rockusb download-boot u-boot-rockchip-rk3588-loader.bin
Another option that does not require use of proprietary tools is using
open source tools such as rkflashtool or rkusbboot that can load the
binman images directly without any need to first create a special loader
image to RAM boot from maskrom, e.g.:
$ rkflashtool l < u-boot-rockchip-usb471.bin
$ rkflashtool L < u-boot-rockchip-usb472.bin
or
$ rkusbboot u-boot-rockchip-usb471.bin u-boot-rockchip-usb472.bin
Signed-off-by: Jonas Karlman <[email protected]>
Tested-by: Arnaud Patard <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Drop SoC specific TEXT_BASE and use a common TEXT_BASE for all SoCs.
Move the common TEXT_BASE to 8 MiB offset from start of DRAM to help
support RAM boot from maskrom introduced in next patch.
RAM boot from maskrom mode will expect the FIT payload to be located at
2 MiB offset from start or DRAM.
Signed-off-by: Jonas Karlman <[email protected]>
Tested-by: Arnaud Patard <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
While this change was intended to fix a mistake in the code, of calling
the ERR_PTR macro but not making use of the result, it seems that
functionally platforms depend on the loop not existing here. The TI K3
families of platforms for example were broken by this commit.
This reverts commit fe780310cfa8bf5a093894b5cd7fe85c6b02fd91.
Reported-by: Nishanth Menon <[email protected]>
Reviewed-by: Andrew Goodbody <[email protected]>
Reviewed-by: Nishanth Menon <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Previously, few Amlogic devices supported EFI capsule updates.
Generally only the Libre Computer ones with SPI flash supported it,
thanks to board-specific code.
This commit commonises capsule update support across supported
Amlogic boards. Similar to Qualcomm's support for it, the dfu string
and firmware name is automatically generated at runtime depending on
which device we are booted from. Right now this supports flashing to
the eMMC/SD and SPI flash.
As usual, the capsule UUID is automatically generated. You can get it
by enabling CONFIG_CMD_EFIDEBUG and running:
=> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=796180D4-AAB2-50F1-B16A-53DFF9CA89B2
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
========================================
Reviewed-by: Evgeny Bachinin <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Some processor families use a generic device tree, and rely on u-boot
fixups to massage that for lower core count personalities (i.e. NXP
LX2* family). For example, the LX2160A device tree will be used and
then modified to offline non-existent cores when running on an 8-core
LX2080A.
However, the cooling maps still contain references to the non-existent
core phandles, resulting in:
OF: /thermal-zones/cluster6-7-thermal/cooling-maps/map0:
could not find phandle 15
Rebuild the cooling maps as non-existent cores are deleted.
Signed-off-by: Anthony Pighin <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add binman configuration to meson-gx-u-boot.dtsi to automate building
bootable images using amlimage.
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Add a common GXBB DTSI, similar to the meson-gxl-u-boot.dtsi file,
which GXBB devicetrees can include.
Signed-off-by: Ferass El Hafidi <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Supports both GXBB and GXL SoCs.
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Add initial boilerplate for U-Boot SPL support on Amlogic.
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Add a minimal non-DM MMC driver for use in size-constrained
environments.
Signed-off-by: Ferass El Hafidi <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Remove bootph properties no longer needed. These are now handled
in upstream Linux device trees.
While at it, drop the vtt-supply which is a leftover from the
very initial prototype of this board.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
Remove bootph properties no longer needed. These are now handled
in upstream Linux device trees.
Signed-off-by: Wadim Egorov <[email protected]>
|
|
The objcopy man-page teaches:
--target=bfdname
Use bfdname as the object format for
both the input and the output file
This implies for --target=efi-app-x86_64 that the input file would have
to be an EFI app.
Objcopy in binutils 2.45 checks this more strictly than previous versions
and refuses to accept an ELF file as input with --target=efi-app-x86_64.
Replace --target by --output-target for building sandbox and x86 EFI
binaries.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Update DRAM chip type and density comment for 512 MiB DRAM settings for
DH STM32MP13xx DHCOR DHSBC to match the chip on the SoM. No functional
change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
Tested-by: Patrice Chotard <[email protected]>
|
|
into next
CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/28674
- riscv: Implement private GCC library
- mpfs: Add MPFS CPU Implementation
- andes: Stop disabling device tree relocation and some minor fixes
- sifive: Stop disabling device tree relocation
- starfive: Cleanup size types and typos
|
|
Prepare v2026.01-rc4
|
|
The following functions are provided:
Count leading zero bits
* int __clzsi2 (unsigned int a)
* int __clzdi2 (unsigned long a)
* int __clzti2 (unsigned long long a)
Count trailing zero bits
* int __ctzsi2 (unsigned int a)
* int __ctzdi2 (unsigned long a)
* int __ctzti2 (unsigned long long a)
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
There are multiple boards that use the PolarFire SoC, so extract
the Kconfig sections that are determined at a CPU level from the board
Kconfigs now that we have a CPU Kconfig.
Signed-off-by: Conor Dooley <[email protected]>
|
|
PolarFire SoC needs a custom implementation of top_of_ram(), so stop
using the generic CPU & create a custom CPU instead.
Signed-off-by: Conor Dooley <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
Updated DTS and configuration files to set the default baud rate from 38400 to 115200.
Signed-off-by: Che-Wei Chuang <[email protected]>
|
|
Add '\n' to the end of the warning message.
Besides, if we enable console record utility,
missing the '\n' causes the console_record_readline
fail to recognize the end of string.
Signed-off-by: Leo Yu-Chi Liang <[email protected]>
|
|
Enable standard boot for the phyCORE-i.MX93 board and use it as a new
default. Add required standard boot variables to the environment, while
removing old boot scripts and now unnecessary environment variables.
Adjust variables according to the requirements of PHYTEC ampliphy-boot
distro-boot. Last but not least, order environment vars by alphabet and
run 'make savedefconfig' to resync defconfig.
Signed-off-by: Primoz Fiser <[email protected]>
Reviewed-by: Wadim Egorov <[email protected]>
|
|
For silicon revision A1, the USB instance number for USB1 is 3 and for
USB2 it is 4. This changed for revision B0 where the USB instance number
for USB1 is 0 and for USB2 it is 1, which is the intended instance
number. Select the correct numbering according to the selected SoC
(IMX95) and its revision.
This patch is based on the information provided by:
"AN14750 Migration Guide from i.MX 95 A1 to B0; Rev. 1.0" .
Reviewed-by: Alice Guo <[email protected]>
Signed-off-by: Fedor Ross <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
Similar to the imx95, use the nxp-imx9image etype for the binman node to
facilitate further modifications.
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <[email protected]>
|
|
No functional changes, only cosmetic adjustments to prepare for the next
commit.
Signed-off-by: Jérémie Dautheribes (Schneider Electric) <[email protected]>
|
|
While adding CPSW device support to enable Ethernet boot for J722S,
dev-data and clk-data for eMMC was removed by mistake, which leads to eMMC
boot failure. Update the dev-data and clk-data to fix that.
Fixes: a02009f3a816 ("arm: mach-k3: j722s: Update SoC autogenerated data to enable Ethernet boot")
Reported-by: Michael Walle <[email protected]>
Signed-off-by: Chintan Vankar <[email protected]>
Tested-by: Michael Walle <[email protected]>
Reviewed-by: Udit Kumar <[email protected]>
|
|
ARM GCC tool check is not up to date,
while issues are reported such as file truncated linker errors.
Using ARM official cross tools shows that 10.0.1 is a safe
version to support latest kbuild bump properly.
Signed-off-by: Brian Sune <[email protected]>
|
|
Andrew Goodbody <[email protected]> says:
Smatch reported an error where a value calculated by ERR_PTR was not
used. Fixing this to return the generated value led to a test failure
which meant updating the sandbox clock code so that it would still cause
the tests to pass with the above correction.
Debugging this problem led to a SIGSEGV which is addressed in 1/3.
Possible memory leaks noticed are addressed in 3/3.
Link: https://lore.kernel.org/r/[email protected]
|
|
In clk_set_default_get_by_id ret is passed to ERR_PTR but nothing is
done with the value that this calculates which is obviously not the
intention of the code. This is confirmed by the code around where this
function is called.
Instead return the value from ERR_PTR.
Then fixup the sandbox code so that the test dm_test_clk does not fail
as it relied on the broken behaviour.
Finally disable part of the test that does not work correctly with
CLK_AUTO_ID
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
To the exception of red_led_on in the arm-specific assembly code, all
code interacting with the red status LED was guarded by the
CONFIG_LED_STATUS_RED symbol, which is enabled in none of the upstream
defconfigs.
Since the last board which overrode the weak red_led_on function got
migrated to the new LED mechanism, there's also no user of the
arm-specific assembly code anymore, therefore it can be removed along
the other unreachable code sections.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
red_led_on is either called from the legacy LED shell command (which is
disabled for corvus) or from arm-specific assembly code right before
jumping into board_init_r() in U-Boot proper.
Let's migrate to use the more modern LED subsystem by migrating to DM.
The default-state is set to on to mimic red_led_on() from the
arm-specific assembly code as a missing default-state FDT property
currently means the LED is not probed except if explicitly done via the
led shell command. Note though that this is running much later in the
boot process, once DM is started.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
No PPC upstream defconfig actually enables CONFIG_LED_STATUS and we're
trying to get rid of the legacy LED API, so let's remove one of its last
users.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Commit 76386d6195a1 ("arm: Remove cm_t35 board") removed support for the
board that was built when TARGET_CM_T35 is selected, but removal of the
symbol was forgotten, so let's fix this oversight.
While at it, update the README for omap3 to remove the last mention of
cm_t35.
Fixes: 76386d6195a1 ("arm: Remove cm_t35 board")
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The last user of coloured_LED_init has been recently removed, so we can
remove all places it's called and defined as it does nothing now.
Nobody makes use of the yellow and blue status LEDs from the legacy API,
so let's remove all references to it.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Remove obsolete property "u-boot, u-boot-led" from
stm32mp257f-ev1-u-boot.dtsi.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove obsolete property "u-boot, u-boot-led" from
stm32mp235f-dk-u-boot.dtsi.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157cf-ed1-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
stm32mp157c-ed1-scmi-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157c-ed1-scmi-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp135f-dk-u-boot.dtsi.
Remove led-red which is now available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
stm32mp157a-dk1-scmi-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157a-dk1-scmi-u-boot.dtsi.
Remove led-red node which is now available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp135f-dk-u-boot.dtsi.
Remove also led-red node which is now part of kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Update DRAM chip type and density comment for 512 MiB DRAM settings for
DH STM32MP13xx DHCOR DHSBC to match the chip on the SoM. No functional
change.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
Tested-by: Patrice Chotard <[email protected]>
|
|
cmd doc"
Quentin Schulz <[email protected]> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/[email protected]/
and
https://lore.kernel.org/u-boot/[email protected]/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Link: https://lore.kernel.org/r/[email protected]
|
|
This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.
Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.
As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.
Note that this is not tested as I do not own this device.
Cc: Alexander Dahl <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Tested-by: Alexander Dahl <[email protected]>
|
|
There's no code to make use of it.
Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.
So let's simply remove this unused property to not mislead users.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Signed-off-by: Quentin Schulz <[email protected]>
|
|
There's no code to make use of it.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years (if ever), let's just remove
it.
Signed-off-by: Quentin Schulz <[email protected]>
|
