| Age | Commit message (Collapse) | Author |
|---|
|
CONFIG_COUNTER_FREQUENCY is currently 24000000 for all SoCs, meaning it
fits in a 32b type. For 64b SoCs, it's an issue since the registers are
64b.
clang complains that we're trying to fit a 32b value into a 64b
register:
arch/arm/mach-rockchip/rk3528/rk3528.c:98:45: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths]
98 | asm volatile("msr cntfrq_el0, %0" : : "r" (CONFIG_COUNTER_FREQUENCY));
| ^
include/generated/autoconf.h:372:34: note: expanded from macro 'CONFIG_COUNTER_FREQUENCY'
372 | #define CONFIG_COUNTER_FREQUENCY 24000000
| ^
/home/qschulz/work/upstream/u-boot/arch/arm/mach-rockchip/rk3528/rk3528.c:98:32: note: use constraint modifier "w"
98 | asm volatile("msr cntfrq_el0, %0" : : "r" (CONFIG_COUNTER_FREQUENCY));
| ^~
| %w0
Even though cntfrq_el0[1] is only using the 32b LSB of its 64b, use the
'x' operand modifier[2] to force the value to be 64b and fix the
warning.
[1] https://developer.arm.com/documentation/ddi0601/2026-03/AArch64-Registers/CNTFRQ-EL0--Counter-timer-Frequency-Register?lang=en
[2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#AArch64-Operand-Modifiers
Suggested-by: Mark Kettenis <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The commit 55a342176984 ("common: Add an option to relocate on ram top")
changed so that dram_init_banksize() is called before gd->ram_top has
been initialized. This change broke Rockchip DRAM banks configuration
due to gd->ram_top now being 0 when dram_init_banksize() is called.
This makes first DRAM bank size calculation overflow and end up with
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0xffffffffffe00000
instead of the expected (for 2 GiB)
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0x000000007fe00000
or (for 4 GiB)
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0x00000000f7e00000
on e.g. RK3399 boards.
Change to not depend on gd->ram_top having to be pre-calculated before
dram_init_banksize() is called, also move the related method
board_get_usable_ram_top() closer to more easily get an overview of
their interdependence, to restore working DRAM bank initialization.
Fixes: 55a342176984 ("common: Add an option to relocate on ram top")
Signed-off-by: Jonas Karlman <[email protected]>
Reported-by: Ilias Apalodimas <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]> # on Radxa ROCK
|
|
Restyle all Kconfigs for "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Switch rk3229 boards to upstream devicetree.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Switch rk3128 boards to upstream devicetree.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Add the required architecture-specific lookups to enable U-boot SPL to
load images from UFS storage devices on Rockchip RK3576, which has a
boot ROM capable of loading the SPL image from UFS.
Reviewed-by: Jonas Karlman <[email protected]>
Signed-off-by: Alexey Charkov <[email protected]>
|
|
The NanoPi R76S (as "R76S") is an open-sourced mini IoT gateway
device with two 2.5G, designed and developed by FriendlyElec.
Features tested on a NanoPi R76S 2411:
- SD-card boot
- eMMC boot
- LEDs and button
- PCIe/Ethernet
- USB host
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The symbol SPL_SYS_MALLOC_F defaults to y when visible and
TPL_SYS_MALLOC_F defaults to y when visible and SPL_SYS_MALLOC_F is
enabled. Remove the places from Kconfig files that had unneccsary
"default y" for these options.
Signed-off-by: Tom Rini <[email protected]>
|
|
It is not functionally possible to use the code enabled by
PARTITION_TYPE_GUID without having EFI_PARTITION be enabled as well. Not
all users of the former had ensured that the latter was enabled however,
so audit all current users and then as appropriate select or imply
EFI_PARTITION as needed.
Signed-off-by: Tom Rini <[email protected]>
|
|
Rockchip RK356x supports up to 8 GiB DRAM, however U-Boot only includes
the initial 32-bit 0-4 GiB addressable range in its memory map,
something that matches gd->ram_top and current expected memory available
for use in U-Boot.
The vendor DRAM init blobs add following ddr_mem rk atags [1]:
4 GiB: [0x0, 0xf0000000) and [0x1f0000000, 0x200000000)
8 GiB: [0x0, 0x200000000)
Add the remaining 64-bit 4-8 GiB addressable range, that already is
reported to OS, to the U-Boot memory map to more correctly describe all
available and addressable DRAM of RK356x. While at it also add the
missing UL suffix to the PCIe address range for consistency.
[1] https://gist.github.com/Kwiboo/6d983693c79365b43c330eb3191cbace
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Symbol CONFIG_TPL_TINY_FRAMEWORK does not exist.
Don't select it.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Booting into SPL using ramboot can take several seconds on some SoCs due
to the large size of the usb472 payload sent over USB to BootROM.
A large chunk of the usb472 payload, around 1-2 MiB, is padding used to
avoid overlapping when loading e.g. TF-A to 0x40000.
BootROM is likely wasting unnecessary time crc16 validating the padding
of the payload.
Place the FIT payload directly after SPL and memmove it to the expected
memory location, SPL_LOAD_FIT_ADDRESS, to avoid excessive padding and
help speed up ramboot.
Binman symbols are used to get the position and size of the FIT payload
that is initially loaded into DRAM by the BootROM.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The ATAGS set by Rockchip DDR init blob[1] specify DRAM banks above the
first addressable 4GiB which we haven't done in the mem_map for RK3588
yet.
For 4GiB DRAM, the 256MiB missing from the first addressable 4GiB (due
to MMIO) are accessible at the end of the 8GiB address space. For 8GiB,
4-8GiB address space is used for the additional 4GiB and the missing
256MiB are at the end of 12GiB address space. For 12, 4-12GiB and the
missing 256MiB at the end of 20GiB address space. For 16GiB, 4-~16GiB
with two holes (reasons unknown) around 16GiB and the missing 256MiB is
at the end of 20GiB address space. For 32GiB, 4-16~GiB with two holes
and then 16GiB to 32GiB address space (so likely missing 256MiB from
MMIO address space).
[1] https://gist.github.com/Kwiboo/1c020d37e3adbc9d0d79dc003d921977
Suggested-by: Jonas Karlman <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Rockchip RK3506 is a ARM-based SoC with tri-core Cortex-A7.
Add initial arch support for the RK3506 SoC.
Signed-off-by: Jonas Karlman <[email protected]>
Acked-by: Mattijs Korpershoek <[email protected]> # drivers/usb/gadget
Reviewed-by: Kever Yang <[email protected]>
|
|
Multiple newer Rockchip SoCs report 0x81 instead of 0xa when booting
from USB, i.e. on RK3576, RK3528, RK3506 and RV1106.
Move the bootsource_id 0x81 handling currently only used for RK3528 to
the common read_brom_bootsource_id() to reduce the need to override this
function when support for newer SoCs is introduced.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Imply OF_UPSTREAM for rk3288 boards.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The NanoPi Zero2 is a small single board computer developed by
FriendlyElec, based on the Rockchip RK3528A SoC.
Add support for the FriendlyElec NanoPi Zero2 board.
Features tested on a FriendlyElec NanoPi Zero2 2407:
- SD-card boot
- eMMC boot
- Ethernet
- USB host
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Christopher Obbard <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The firewall block access to pmu sram for non-secure masters by default
after reset (0xffffbfff).
Change the pmu lookup configuration to match the default lookup config
for ddr and system sram (0xffff3fff) to allow loading TF-A using DMA.
Mainline TF-A will re-configure the firewall to use an even less
restrictive lookup (0xbffe3ff0), so this change is not expected to have
any real security implication.
Signed-off-by: Jonas Karlman <[email protected]>
Tested-by: Alexey Charkov <[email protected]> # UFS
Reviewed-by: Kever Yang <[email protected]>
|
|
Add Kconfig option OF_SYSTEM_SETUP=y to support booting ROCK 5C Lite
boards with a RK3582 SoC. CPU and GPU cores are failed based on ip-state
and policy.
Tested on a ROCK 5C Lite v1.1:
cpu-code: 35 82
ip-state: 00 80 00 (otp)
ip-state: c0 9e 04 (policy)
remove cpu-map cluster2
fail gpu
fail rkvdec1
fail rkvenc1
fail cpu cpu@600
fail cpu cpu@700
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The RK3582 SoC is a variant of the RK3588S with some IP blocks disabled.
What blocks are disabled/non-working is indicated by ip-state in OTP.
This add initial support for RK3582 by using ft_system_setup() to mark
any cpu, gpu and/or vdec/venc node with status=fail as indicated by
ip-state.
This apply same policy as vendor U-Boot for RK3582, i.e. two big cpu
cores, the gpu and one vdec/venc core is always failed/disabled.
Enable Kconfig option OF_SYSTEM_SETUP in board defconfig to make use of
the required DT fixups for RK3582 board variants.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
RK3588 has two known memory gaps when using 16+ GiB DRAM,
[0x3fc000000, 0x3fc500000) and [0x3fff00000, 0x400000000).
The vendor TPL blob encodes this information in the DDR_MEM tag data
passed to later boot phases. U-Boot proper will normally use this
information to configure the DRAM banks.
When a DDR_MEM tag cannot be found the fallback is to use the entire
range above 4 GiB. Something that will cause issues when OS try to use
memory from the two known memory gaps.
Add a weak dram init banksize fixup function and implement it for RK3588
to fix issues observed when trying to RAM boot RK3588 boards with 16+
GiB DRAM into Linux.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Expands some linker sections to be more readable when adding a second
statement to the section.
- Aligns the final section before _end (for U-Boot) or
_image_binary_end or __bss_end (for xPL phases) by 8-bytes by adding
'. = ALIGN(8);' to the final section before the symbol.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
- Remove now-spurious '. = ALIGN(x);' statements that were intended to
provide the above alignments.
Tested-by: Michal Simek <[email protected]> # Zynq
Reviewed-by: Ilias Apalodimas <[email protected]>
[trini: Also update arch/arm/cpu/armv8/u-boot.lds as Ilas requested]
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
|
|
Add a helper function based on rockchip_sdram_size() that return what
DRAM type is used on current running board.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
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]>
|
|
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]
|
|
There's not a single device making use of that code and it anyway
shouldn't be using the old deprecated u-boot,boot-led /config property
anymore but rather boot-led from /options/u-boot[1] Device Tree node.
Because spl_board_init() is only present to call this now removed
function, we can remove it as well as SPL_BOARD_INIT which is the symbol
guarding calls to spl_board_init() (which is now also removed).
[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]>
|
|
The SCMI shared memory area is no longer automatically marked as
non-cacheable after the commit a5a0134570c8 ("firmware: scmi: Drop
mmu_set_region_dcache_behaviour() misuse").
This change in behavior cause Rockchip RK3588 boards to fail boot with:
SoC: RK3588
DRAM: 8 GiB
scmi-over-smccc scmi: Channel unexpectedly busy
scmi_base_drv scmi-base.0: getting protocol version failed
scmi-over-smccc scmi: failed to probe base protocol
initcall_run_r(): initcall initr_dm() failed
### ERROR ### Please RESET the board ###
Update the memory mapping on RK3588 to mark the SCMI shared memory area
as non-cacheable to fix the SCMI shared memory based transport issue
that prevented RK3588 boards from booting.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Boot devices are being probed when SPL boot order is determined. This
may delay boot slightly and can prevent booting from SPI Flash on boards
that use same pins for SPI Flash and eMMC due to pinctrl being applied
prior to booting.
Instead defer probe of the boot device until SPL try to load image from
the boot device by using uclass_find_device_by_of_offset() instead of
the get variant.
Signed-off-by: Jonas Karlman <[email protected]>
|
|
The free running mode is 0 at bit offset 1. User mode is 1 at bit offset
1. Currently, free running mode is 1 at offset 0, which is already the
case thanks to TIME_EN.
So, this essentially does not change the actual value written to the
register as it is TIME_EN | TIMER_FMODE which currently is 0x1 | BIT(0)
= 0b1, and will become 0x1 | (0 << 1) = 0b1.
I checked PX30, RK3128, RK3188, RK3228, RK3288, RK3308, RK3328, RK3368
RK3506, RK3562 and RK3568 TRMs.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The free running mode is 0 at bit offset 1. User mode is 1 at bit offset
1. Currently, free running mode is 1 at offset 0, which is already the
case thanks to TIME_EN.
So, this essentially does not change the actual value written to the
register as it is TIME_EN | TIMER_FMODE which currently is 0x1 | BIT(0)
= 0b1, and will become 0x1 | (0 << 1) = 0b1.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The only difference with the implementation in spl_common.c is that we
check whether the timer has already been enabled. Considering this is
running in SPL, the first stage on RK3036, I feel like it's guaranteed
to not be enabled by default. No public TRM though and I don't have
access to an RK3036 device so take this as a guess.
Size of SPL binary increases by 8B for evb-rk3036.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Instead of redefining what is essentially the same code in
secure_timer_init, let's simply use rockchip_stimer_init from
spl_common.o instead.
This increases the size of the TPL by 16B, due to the added check of
STIMER already being enabled. Experimentally, STIMER is not already
enabled when in TPL.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The Sige1 is a single board computer developed by ArmSoM, based on the
Rockchip RK3528A SoC.
Add support for the ArmSoM Sige1 board.
Features tested on a ArmSoM Sige1 v1.1:
- SD-card boot
- eMMC boot
- Ethernet
- USB host (with pending DT changes)
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The ROCK 2 Family is a high-performance SBC (Single Board Computer)
developed by Radxa, based on the Rockchip RK3528A.
The Radxa E20C shares some board characteristics with the ROCK 2 family
boards.
Add support for the ROCK 2A and 2F boards. The radxa-e20c-rk3528 target
is also extended to support booting ROCK 2 boards.
Features tested on a ROCK 2A v1.202:
- SD-card boot
- Ethernet
- USB host (with pending DT changes)
Features tested on a ROCK 2F v1.016:
- SD-card boot
- eMMC boot
- USB host (with pending DT changes)
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
FriendlyElec NanoPi M5 with Rockchip RK3576 SoC (4x Cortex-A72,
4x Cortex-A53, Mali-G52 MC3 GPU, 6 TOPS NPU).
Features tested on a NanoPi M5 2411:
- SD-card boot
- SPI flash boot
- Ethernet
- LEDs
- PCIe/NVMe
- USB HOST/OTG
- USER button
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Luckfox Omni3576 Carrier Board with Core3576 Module, powered by the
Rockchip RK3576 SoC with four Cortex-A72 cores, four Cortex-A53 cores,
and a Mali-G52 MC3 GPU.
Features tested with a Core3576 Rev1.1 on a Omni3576 carrier board:
- SD-card boot
- eMMC boot
- LED
- PCIe/NVMe
- USB2.0 HOST
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The Radxa ROCK 4D is a compact single-board computer (SBC) featuring
numerous top-tier functions, features, and expansion options.
Equipped with the Rockchip RK3576 or RK3576J SoC, the ROCK 4D boasts an
octa-core CPU (4x Cortex-A72 + 4x Cortex-A53), Mali-G52 GPU, and a
powerful 6 TOPS NPU, making it ideal for AI and multimedia tasks.
Features tested on a Radxa ROCK 4D v1.112:
- SPI Flash boot
- Ethernet
- PCIe/NVMe
- USB host
ROCK 4D boards with SPI Flash is configured to boot from FSPI0->UFS->USB,
or directly from USB when the MASKROM button is pressed, booting
directly from SD-card is not possible on these boards.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The bootsource ids reported by BootROM of RK3576 for SPI NOR and USB
differs slightly compared to prior SoCs:
- Booting from sfc0 (ROCK 4D) report the normal bootsource id 0x3.
- Booting from sfc1 M1 (NanoPi M5) report a new bootsource id 0x23.
- Booting from sfc1 M0 has not been tested (no board using this config).
- Booting from USB report a new bootsource id 0x81.
Add a RK3576 specific read_brom_bootsource_id() function to help decode
the new bootsource id values and the required boot_devices mapping of
sfc0 and sfc1 to help support booting from SPI flash on RK3576.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The bootsource ids reported by BootROM of RK3528 for e.g. USB differs
compared to prior SoCs:
- Booting from USB report a new bootsource id 0x81.
Add a RK3528 specific read_brom_bootsource_id() function to help decode
this new bootsource id value to help support booting from USB on RK3528.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The bootsource ids reported by BootROM of RK3528 and RK3576 for e.g.
SPI NOR and USB differs slightly compared to prior SoCs:
- Booting from sfc0 (ROCK 4D) report the normal bootsource id 0x3.
- Booting from sfc1 M1 (NanoPi M5) report a new bootsource id 0x23.
- Booting from sfc1 M0 has not been tested (no board using this config).
- Booting from USB report a new bootsource id 0x81 on RK3528 and RK3576.
Add a helper function to read the bootsource id. This helper function
will be used to translate the new values to the common BROM_BOOTSOURCE
enum values on RK3528 and RK3576.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The current spl_board_fixups API allows for modification of spl_image
before the SPL jumps to it. This can be used to modify the DT for the
next boot stage, however the current API only allows either the machine
arch or the board to use it.
This limits the utility of the API as there might be certain fixups that
should be applied to all boards sharing the same machine architecture
with others being board specific.
For TI's K3 specifically, this prevents us from performing architecture
level fixups since a lot of TI boards are already making use of the
spl_board_fixups API.
Therefore this patch splits the API into two to allow both board and the
architecture specific fixups. The order is kept as arch then board to
give board specific fixups the precedence.
Reviewed-by: Dhruva Gole <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
Tested-by: Wadim Egorov <[email protected]>
|
|
Prepare v2025.10-rc4
|
|
The RK3576 SoC comes with USB OTG support using a DWC3 controller with
a USB2 PHY and a USB3 PHY (USBDP PHY).
Some board designs may not use the USBDP PHY for USB3 purpose. For these
board to use USB OTG the input clock source must change to use UTMI clk
instead of PIPE clk.
Change to always disable the USB3OTG0 U3 port early and leave it to the
USBDP PHY driver to re-enable the U3 port when a usb3-phy is described
in the board device tree.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The RK3588 SoC comes with USB OTG support using a DWC3 controller with
a USB2 PHY and a USB3 PHY (USBDP PHY).
Some board designs may not use the USBDP PHY for USB3 purpose. For these
board to use USB OTG the input clock source must change to use UTMI clk
instead of PIPE clk.
Change to always disable the USB3OTG U3 ports early and leave it to the
USBDP PHY driver to re-enable the U3 port when a usb3-phy is described
in the board device tree.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The RK3528 SoC comes with USB OTG support using a DWC3 controller with
a USB2 PHY and a USB3 PHY (COMBPHY).
Some board designs may not use the COMBPHY for USB3 purpose. For these
board to use USB OTG the input clock source must change to use UTMI clk
instead of PIPE clk.
Change to always disable the USB3OTG U3 port early and leave it to the
COMBPHY driver to re-enable the U3 port when a usb3-phy is described in
the board device tree.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
ArmSoM-Sige5 adopts the second-generation 8nm high-performance AIOT
platform Rockchip RK3576, with a 6 TOPS computing power NPU and support
for up to 16GB of large memory. It supports 4K video encoding and
decoding, offers rich interfaces including dual gigabit Ethernet ports,
WiFi 6 & BT5, and various video outputs.
Features tested on a ArmSoM Sige5 v1.1:
- SD-card boot
- eMMC boot
- Ethernet
- PCIe NVMe
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Implement checkboard() to print current SoC model used by a board when
U-Boot proper is running.
U-Boot 2025.04 (Apr 22 2025 - 20:43:17 +0000)
Model: Generic RK3576
SoC: RK3576
DRAM: 8 GiB
Information about the SoC model and variant is read from OTP.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
