| Age | Commit message (Collapse) | Author |
|---|
|
Rasmus Villemoes <[email protected]> says:
Make it possible to update the (whole) bootloader on am335x robustly,
i.e. so that a power failure or random OOM killing of the update
process or other interruptions do not result in a bricked board.
The order the trial bits gets set is somewhat odd, but is clearly what
happens, and somebody else trying to reverse engineer the ROM code has
observed the same thing: See the TracingVectors.ods in
https://github.com/sjgallagher2/am335xbootrom .
Link: https://lore.kernel.org/r/[email protected]
|
|
The am335x knows nothing about eMMC boot partitions, so in order to
implement an update procedure of the bootloader which is robust
against power failure or other interruptions, one must make use of the
fact that ROM code on the am335x looks for a valid first stage
bootloader at several different offsets. Updating that can then be
implemented by (assume we put MLO at offsets 128K and 256K):
(1) At least one of the two slots must contain a valid header, since
we successfully booted. Pick the other one.
(2) Overwrite the first sector of the slot chosen in step (a) with all
zeroes.
(3) Write everything but the first sector to the chosen slot.
(4) Write the first sector (containing the magic signature that the
boot ROM uses to identify a valid image) to the chosen slot.
(5) Repeat steps (2)-(4) for the other slot.
It's not possible to simply write the whole MLO in one go, especially
not when updating the 128K slot, because an interruption after the
first sector is written would make the ROM code believe the image is
valid.
But this only caters for SPL itself; regardless of where SPL was
loaded from, it would go on to load U-Boot proper from
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. So in order to update the whole
bootloader, we need to teach SPL to use a different offset for U-Boot
proper depending on where SPL itself was loaded from (*). With that,
the update procedure is just amended by a step
(3a) Write U-Boot proper to the offset corresponding to the SPL slot
being updated.
We can know (*) because the ROM code sets a new bit in a certain
"trace vector" before each successive attempt.
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Santhosh Kumar K <[email protected]> says:
This series updates the DDR Configurations according to the SysConfig DDR
Configuration tool v0.10.32 for the following devices [1]
- AM64x EVM
- AM62x SK
- AM62x LP SK
- AM62Ax SK
- AM62Px SK
Testing:
memtester - 50% of memory for 10 loops - PASSED
[1] https://dev.ti.com/tirex/content/Processor_DDR_Config_0.10.32.0000/docs/REVISION_HISTORY.html
Link: https://lore.kernel.org/r/[email protected]
|
|
Update the DDR Configurations for AM62Px SK according to the SysConfig
DDR Configuration tool v0.10.32. [1]
[1] https://dev.ti.com/tirex/content/Processor_DDR_Config_0.10.32.0000/docs/REVISION_HISTORY.html
Signed-off-by: Santhosh Kumar K <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Update the DDR Configurations for AM62Ax SK according to the SysConfig
DDR Configuration tool v0.10.32. [1]
[1] https://dev.ti.com/tirex/content/Processor_DDR_Config_0.10.32.0000/docs/REVISION_HISTORY.html
Signed-off-by: Santhosh Kumar K <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Update the DDR Configurations for AM62x LP SK according to the SysConfig
DDR Configuration tool v0.10.32. [1]
[1] https://dev.ti.com/tirex/content/Processor_DDR_Config_0.10.32.0000/docs/REVISION_HISTORY.html
Signed-off-by: Santhosh Kumar K <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Update the DDR Configurations for AM62x SK according to the SysConfig
DDR Configuration tool v0.10.32. [1]
[1] https://dev.ti.com/tirex/content/Processor_DDR_Config_0.10.32.0000/docs/REVISION_HISTORY.html
Signed-off-by: Santhosh Kumar K <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Update the DDR Configurations for AM64x EVM according to the SysConfig
DDR Configuration tool v0.10.32. [1]
[1] https://dev.ti.com/tirex/content/Processor_DDR_Config_0.10.32.0000/docs/REVISION_HISTORY.html
Signed-off-by: Santhosh Kumar K <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Historically, when we have an appended device tree and also our
resulting binary will contain the BSS section, we have ensured that
everything will be where it's expected to be by declaring that the BSS
is overlayed with a symbol matches the end of the port of the ELF binary
that is objcopy'd to the binary we concatenate with. This in turn means
that the logic to generate a "pad" file, which is the size found in the
__bss_size symbol, will be correct and then we can concatenate the
device tree and it will begin at __bss_size at run time.
With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
we removed this overlay as part of trying to ensure that we met both the
requirements of the device tree to be 8 byte aligned as well as that our
logic to generate the -pad file would match what ended up in the
resulting binary. While it was correct to remove an unused section it
did not solve ultimately solve the problem for all cases.
To really fix the problem, we need to do two things. First, our final
section prior to _image_binary_end must be 8 byte aligned (for the case
of having a separate BSS and so our appended DTB exists at this
location). This cannot be '.binman_sym_table' as it may be empty, and in
turn the ELF type would be NOBITS and so not copied with objcopy. The
__u_boot_list section will never be empty, so it is our final section,
and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
our copied data it is safe to declare that the BSS starts here, so use
the OVERLAY keyword to place the BSS here.
Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
Reported-by: Brian Sune <[email protected]>
Reported-by: Phil Phil Sutter <[email protected]>
Tested-by: Brian Sune <[email protected]>
Tested-by: Phil Sutter <[email protected]>
Tested-by: Greg Malysa <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Pull request net-20260209.
net:
- airoha: mdio support for the switch
- phy: mscc: allow RGMII with internal delay for the VSC8541
- dwc_eth_qos: Update tail pointer handling
net-legacy:
- Stop conflating return value with file size in net_loop()
net-lwip:
- wget: rework the '#' printing
- tftp: add support of tsize option to client
|
|
https://source.denx.de/u-boot/custodians/u-boot-at91
First set of u-boot-at91 features for the 2026.04 cycle:
This small fixes set includes fixing 64 bit builds and some warnings for
the at91 serial driver, and some cleanup on the nand driver.
|
|
Fix ti-secure content reference from spl_am62a7_sk_dtb to
spl_am62d2_evm_dtb or AM62d dtb. Also remove redundant k3-binman.dtsi
include.
Fixes: 14dfa6b86187 ("Add initial support for AM62D2-EVM")
Signed-off-by: Paresh Bhagat <[email protected]>
Reviewed-by: Andrew Davis <[email protected]>
|
|
Moving forward, DM firmware will no longer mess with the MAIN_PLL3.
This means MAIN_PLL3 will need to be manually set to 2GHz in order for
the CPSW9G HSDIV to have the correct 250MHz output for RGMII.
Signed-off-by: Bryan Brattlof <[email protected]>
Signed-off-by: Siddharth Vadapalli <[email protected]>
|
|
Suhaas Joshi <[email protected]> says:
This series starts by replacing hard-coded addresses in firewall
templates that are defined in k3-binman.dtsi, by Kconfigs. Using
Kconfigs makes it easier for someone to move ATF and OP-TEE to another
location, since they wouldn't have to fiddle with the firewall
configurations in dtsi files.
The rest of the commits in this series add firewall configs to each
device's dtsi files.
I have only tested this patch series with TI boards. For non-TI Sitara
boards, respective board maintainers are requested to test the relevant
patch and confirm whether it works.
To test this, I used `k3conf <read|write> <address> [<value>]`. Both of
these operations were disallowed, as expected.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure read's and write's in Phycore AM64 SOM.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure reads and writes in AM64x.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure read's and write's in Phycore AM62A SOM.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure reads and writes in AM62A.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure read's and write's in Verdin AM62P board.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure reads and writes in AM62P.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure read's and write's in Verdin AM62 board.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE from non-secure
reads and writes in Phycore AM625 SOM.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Add firewall configurations to protect ATF and OP-TEE memory regions
from non-secure reads and writes in AM62x.
Signed-off-by: Suhaas Joshi <[email protected]>
|
|
Instead of hard-coding ATF and OPTEE addresses in firewall configuration
templates, use K3_*_LOAD_ADDR. Doing so ensures that if someone moves
ATF/OPTEE regions, the change gets picked up by binman without
explicitly having to modify dts files.
Signed-off-by: Suhaas Joshi <[email protected]>
Reviewed-by: Neha Malcom Francis <[email protected]>
|
|
Add include to avoid following build error with imx93_qsb, when
AHAB_BOOT is enabled:
.../arch/arm/mach-imx/ele_ahab.c:262:24: error: 'IMG_CONTAINER_BASE' undeclared (first use in this function); did you mean 'IMG_CONTAINER_END_BASE'?
.../arch/arm/mach-imx/ele_ahab.c:477:20: error: 'FSB_BASE_ADDR' undeclared (first use in this function); did you mean 'WDOG_BASE_ADDR'?
.../arch/arm/mach-imx/ele_ahab.c:543:20: error: 'FSB_BASE_ADDR' undeclared (first use in this function); did you mean 'WDOG_BASE_ADDR'?
Signed-off-by: Niko Mauno <[email protected]>
|
|
Switch to OF_UPSTREAM to make use of the upstream device trees.
Remove the now obsolete device tree files:
- imx8mn-var-som-symphony.dts
- imx8mn-var-som.dtsi
Signed-off-by: Hugo Villeneuve <[email protected]>
|
|
The som-eeprom alias is specific to U-Boot, and not present in upstream
linux imx8mn-var-som device tree.
Add it to the SOM U-Boot specific device tree file in preparation
for migration to OF_UPSTREAM.
Signed-off-by: Hugo Villeneuve <[email protected]>
|
|
Move SOM-specific stuff into a new SOM u-boot.dtsi file.
This way, it can be used by multiple boards.
Signed-off-by: Hugo Villeneuve <[email protected]>
|
|
Add i.MX95 CM7 node for remoteproc usage. The dt-bindings for CM7 was
accepted, by the node has not been upstreamed to Linux device tree.
Put the node here to let the driver probe. After Linux upstream repo
has this node landed, the node in imx95-u-boot.dtsi could be removed.
Signed-off-by: Peng Fan <[email protected]>
|
|
add mdio node to be able see switch port states
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
add mdio node to be able see switch port states
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
This patch refactors the nodes in each board's R5 device-tree to common
SoC level dtsi. No functional change is intended from this patch.
Signed-off-by: Anshul Dalal <[email protected]>
Tested-by: Wadim Egorov <[email protected]>
Reviewed-by: Wadim Egorov <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
Move the arch specific atmel_serial.h header from AT91 to the generic
include/dm/platform_data.
This will be used for support on Microchip LAN969x.
Signed-off-by: Robert Marko <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-nand-flash
CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/29183
This series provides a comprehensive cleanup of the Allwinner (sunxi)
NAND controller drivers and introduces full support for the H6 and H616
SoCs in both the main U-Boot driver and the SPL.
The series successfully deduplicates register maps between sunxi_nand.c
and sunxi_nand_spl.c while migrating to a capability-based architecture.
This approach allows the driver to handle the H616's specific
requirements—such as shifted register offsets for ECC/OOB, the removal
of 512B ECC block support, and mandatory MBUS clock gating—without
breaking compatibility for legacy A10/A23 devices.
|
|
Ozan Durgut <[email protected]> says:
This series introduces updates for Analog Devices SC5xx boards.
It cleans up device trees by renaming GPIO expanders and removing
incorrect SPI flash definitions from the common include file.
For the SC598, this series updates the EZLITE board to the latest
Revision E hardware. It also adds missing GPIO hogs and enables
additional commands for the EZKIT configuration.
Link: https://lore.kernel.org/r/[email protected]
|
|
Update the SC598 SOM EZLITE device tree to use the latest revision of
the System on Module (Rev E).
Signed-off-by: Ozan Durgut <[email protected]>
Reviewed-by: Greg Malysa <[email protected]>
|
|
The current naming convention for GPIO expanders across ADI SC5xx
device trees is inconsistent. This patch updates the node names to
correct indexing and clarify hardware location.
For SC573, SC584, and SC589 evaluation SBCs, switch to zero-based
indexing to align with standard conventions.
For SC594 and SC598 SoM + carrier evaluation kits, rename the nodes to
crr_gpio_expander. This prefix indicates which board the expander is on.
Signed-off-by: Ozan Durgut <[email protected]>
Reviewed-by: Greg Malysa <[email protected]>
|
|
SPI flash devices are not common across all SC5xx boards. They
already defined in the SoM-specific dtsi files. Keeping the
definition in the common dtsi is therefore incorrect.
Fixes: c9e893d ("board: adi: Add support for SC598")
Signed-off-by: Philip Molloy <[email protected]>
Signed-off-by: Ozan Durgut <[email protected]>
Reviewed-by: Greg Malysa <[email protected]>
|
|
Add missing GPIO hogs for UART0 enable, UART0 flow control,
SD Card and eMMC control signals.
Fixes: c9e893d ("board: adi: Add support for SC598")
Signed-off-by: Ozan Durgut <[email protected]>
Reviewed-by: Greg Malysa <[email protected]>
|
|
Ernest Van Hoecke <[email protected]> says:
This is a small, board-specific series for Aquila AM69.
Patch 1 fixes intermittent SPL USB DFU gadget enumeration.
Patch 2 drops a stale MCU_CLKOUT0 enable for ETH_1. V1.1 hardware uses
an external 25 MHz crystal, and support for earlier revisions was
already removed from the DT before upstreaming.
Link: https://lore.kernel.org/r/[email protected]
|
|
Around 1 in 20 times, the current R5 SPL fails to pull up the D+ line to
signal that a new USB device (the USB gadget used for downloading the
next stage) joined the bus.
With these strapping options, this is greatly reduced to 1 in thousands.
Link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1587424/am69-u-boot-spl-usb-dfu-cdns3-occasionally-fails-to-pull-up-d-in-cdns3_gadget_config
Fixes: 3f0528882c0d ("board: toradex: add aquila am69 support")
Signed-off-by: Ernest Van Hoecke <[email protected]>
Reviewed-by: Francesco Dolcini <[email protected]>
|
|
Add missing NAND controller-related clock registers
The NAND controller on H6/H616 uses one clock for its internal logic
(NAND0_CLK) and one clock for ECC engine (NAND1_CLK) in addition to AHB
and MBUS clocks.
As NAND{0,1}_CLKs and MBUS_GATE are missing, add them.
The bit locations are from H616/H6 User Manual.
Signed-off-by: Richard Genoud <[email protected]>
Signed-off-by: Michael Trimarchi <[email protected]>
|
|
The sunxi_ccm_reg is legacy, drop its usage from nand related code
For that, CCU_NAND0_CLK_CFG and CCU_AHB_GATE1 are added to the clock
files when missing.
And clock code in sunxi_nand{,_spl}.c and board.c are changed to use the
new scheme.
Moreover, drop AHB_DIV_1 in favor of the more readable CCM_NAND_CTRL_M/N
Suggested-by: Andre Przywara <[email protected]>
Signed-off-by: Richard Genoud <[email protected]>
Signed-off-by: Michael Trimarchi <[email protected]>
|
|
When compiled with FTRACE=1 U-boot will crash as %rdi is clobbered
in board_init_f_alloc_reserve() and board_init_f_init_reserve() will
memset the .text segment instead of the global_data struct.
According to the System V AMD64 ABI %rdi is not preserved and the
existing code only worked as board_init_f_alloc_reserve() was small
enough to not use %rdi.
Fix that by always passing the correct argument to
board_init_f_init_reserve().
TEST=Can boot on qemu-q35 with FTRACE=1 enabled during build.
Signed-off-by: Patrick Rudolph <[email protected]>
|
|
The else if branch uses the is_zimage boolean which is initialized to 0
and never set before being tested here.
remove the test on is_zimage to make this code reachable.
Signed-off-by: Guillaume Ranquet <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Allow the system to reset the CPU without calling the reset
controller. This patch also removed the default SYSRESET controller
for MT7628, as it is now optional.
Signed-off-by: Shiji Yang <[email protected]>
|
|
Mediatek MT7620 u-boot does not have PINCONF implementation.
Signed-off-by: Shiji Yang <[email protected]>
|
|
Excessive default value causes crash on hardware: x86 baytrail E3845
It is unclear where the data is being populated being 'BLOBLISTT_TCPA_LOG'
is not found elsewhere in the u-boot tree. This leads to confusion about
how much space for TPM log is actually needed.
This was tested on hardware using TPMv1.
Signed-off-by: Eric Schikschneit <[email protected]>
|
|
Kuan-Wei Chiu <[email protected]> says:
Add support for the QEMU 'virt' machine on the m68k architecture. The
QEMU virt machine models a generic system utilizing Goldfish virtual
peripherals and is capable of emulating various classic 68k CPUs.
Currently, U-Boot's m68k architecture support focuses on ColdFire
variants. This series expands support to include the classic M680x0
architecture, implementing the necessary exception vectors, startup
code, and a bootinfo parser compatible with the QEMU interface.
Drivers for Goldfish peripherals (TTY, Timer, RTC) and the QEMU
Virtual System Controller (sysreset) are also added to enable serial
console, timekeeping, and system reset functionality.
The implementation has been verified on QEMU targeting the M68040 CPU,
confirming successful hardware initialization and boot to the U-Boot
command shell. Additionally, the CI configuration was verified locally
using gitlab-ci-local "qemu_m68k_virt test.py", resulting in
PASS qemu_m68k_virt test.py.
Link: https://lore.kernel.org/r/[email protected]
[trini: Re-sort MAINTAINERS entries]
Signed-off-by: Tom Rini <[email protected]>
|
|
Add support for the QEMU 'virt' machine on the m68k architecture. This
board emulates a generic machine based on the Motorola 68040 CPU
equipped with Goldfish virtual peripherals.
Introduce the necessary board configuration and initialization
infrastructure. The implementation includes logic to parse the QEMU
bootinfo interface, enabling dynamic detection of system RAM size to
adapt to the virtual machine's configuration.
Enable the Goldfish TTY driver for serial console output. Additionally,
enable Goldfish RTC and timer drivers to support real-time clock
functionality and nanosecond-resolution delays. Include comprehensive
documentation covering build instructions and usage examples.
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Tested-by: Daniel Palmer <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
