Janne Grunau <j@jannau.net> says:
The Linux device trees for Apple silicon devices cover now most of the
hardware as u-boot's internal device trees for M1 devices. Linux has in
addition device trees M2 and M1 and M2 Pro/Max/Ultra devices which were
never added in u-boot.
The most common use case for u-boot on Apple silicon devices does not
use DTBs from u-boot but passes runtime modified device trees from an
earlier boot loader (m1n1).
This change regresses support for the SPI on M1 and M1 Pro/Max notebooks
as SPI keyboard support is not in upstream Linux. This regression is in
my opinion acceptable due to the limited use of u-boot's DTBs for these
targets.
Link: https://lore.kernel.org/r/20260507-apple-dt-upstream-v2-0-35181f2b0509@jannau.net
The device tree on Apple silicon devices is passed from a previous
bootloader stage. The bootloader fills in dynamic information so
u-boot can not use its own device tree.
As documented in doc/board/apple/m1.rst it is possible to build boot
bundles (bootloader + device tree + gzipped u-boot binary). These are
useful for testing.
Instead of using u-boot's own device trees for M1 (t8103) devices use
upstream device trees from dts/upstream/src/arm64/apple. The u-boot
device trees have not seen updates since 2022. The upstream linux device
trees have feature parity for the M1 devices. In addition linux has
device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices.
Keep t8103-j274 as default device tree to avoid further updates.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
These SoCs are supported since 2022/2023 but were never added to the
documentation. The devices very similar to the equivalent M1 devices.
The biggest difference is that the M2 and M2 Pro/Max based laptops no
longer use SPI for the keyboard.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
Add fTPM support documentation including an overview, configuration
steps for RPMB provisioning, OP-TEE TA build instructions, and
verification procedure.
Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
Add build steps for building U-Boot in secure state with
TF-A and OP-TEE. It includes the full steps for building
OP-TEE and TF-A to use with U-Boot. Also a short description
how to invoke QEMU with enabled EL3 and EL2. EL3 (machine
option secure=on) is required to run TF-A.
Signed-off-by: Johannes Krottmayer <krotti83@proton.me>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
signed_hdmi_imx8m.bin is already signed and has a IVT header. It should not
be put in u-boot-spl-mkimage.signed.bin. Move it to head of flash.bin
following NXP imx-mkimage. Keeping it in u-boot-spl-mkimage.signed.bin also
consumes a lot of TCM space which is not expected.
While moving it to head of flash.bin, other changes are required,
u-boot.itb is put at sector 768 per defconfig, so u-boot.itb binman
offset should be updated and it should be moved out from binman section.
Also binman symbol address are updated, so need to subtract u-boot-spl
image_pos + CONFIG_SPL_TEXT_BASE to find the correct location of ddr phy
firmware.
Because there is 1KB padding in HDMI firmware, use 32KB when burning
flash.bin to sd card.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When the J784S4-EVM is configured for PCIe Boot, the Bootloaders are to
be written to the address specified by particular BARs. The existing
documentation hard-codes the address corresponding to the BAR under the
assumption that the Root-Complex transferring the Bootloaders is also
a J784S4-EVM. The Root-Complex assigns addresses to the BARs depending
on the currently available set of free system addresses. Since the free
system addresses vary with the Root-Complex being used, instead of
hard-coding the BARs, automate the process of identifying the appropriate
BAR in the form of a command to be run by the user on the Root-Complex.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Add a paragraph to explain how to get the address of the goldfish
tty and use it as the debug uart. I think the address is actually
fixed right now but it might change in the future.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
As the PHYTEC phyCORE-i.MX91 [1] is just another variant of the existing
PHYTEC phyCORE-i.MX93 SoM but with i.MX91 SoC populated instead, add it
to the existing board-code "phycore_imx93", and rename that board to
"phycore_imx91_93" to reflect the dual SoCs support. While at it, also
rename and change common files accordingly. This way i.MX91 and i.MX93
SoC variants of the phyCORE SoM share most of the code and documentation
without duplication, while maintaining own device-tree and defconfigs
for each CPU variant.
Supported features:
- 1GB LPDDR4 RAM
- Debug UART
- EEPROM
- eMMC
- Ethernet
- SD-card
- USB
Product page SoM:
[1] https://www.phytec.eu/en/produkte/system-on-modules/phycore-imx-91-93/
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
CFG_WITH_SOFTWARE_PRNG=y was added as an OPTEE argument to workaround
some bugs related to TRNG which have been fixed now[1]. Therefore this
patch drops the redundant argument from the documentation.
[1]: e313f4765f
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> # Toradex Verdin AM62
Commit 488445cefa ("doc: Move FIT into its own directory") moved the
documentation in doc/uImage.FIT to doc/usage/fit, subsequently all
documents and example sources have been converted to reStructuredText.
Fix (almost) all of the remaining occurrences of the old path and
filenames across the tree.
The exception is doc/uImage.FIT/command_syntax_extensions.txt which
apparently has been removed entirely, or at least I was unable to
locate where that document is now.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
U-Boot produces flash.bin as the final boot image when building for
the i.MX95 EVK, but the documentation refers to imx-boot-imx95.bin.
Update the instructions to use flash.bin when copying the image to
the SD card.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
The imx-oei and imx-sm build systems defaults to:
TC_VERSION ?= 14.2.rel1
but the documentation still instructs users to download the 13.3 toolchain.
This causes the build to fail because the expected directory name does
not exist.
Update the documentation to reference the 14.2 toolchain to match the build
system default.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Describe build with OpenSBI fw_dynamic.bin path as OPENSBI=<path> on the
same line instead of as an export. Also remedy a typo which had the wrong
directory path before the filename.
Fixes: 8304f32267 ("doc: board: starfive: update jh7110 common description")
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Describe build with output directory as O=<dir> environment variable
and not unrelated -O <output sync> command line argument.
Fixes: 8304f32267 ("doc: board: starfive: update jh7110 common description")
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
OrangePi RV is a board that uses the same EEPROM product serial identifier
as the StarFive VisionFive 2 1.3b.
In fact it is not completely compatible with the StarFive VisionFive 2
1.3b for use with Linux Kernel however it is good enough for use with
U-Boot SPL and U-Boot Main. Describe how to set the devicetree search path
and, for advanced users, suggest that it is possible to update the EEPROM
data with an invented "XOPIRV" identifier for automatic board detection.
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Neha Malcom Francis <n-francis@ti.com> says:
Typically we do not enable these configs by default but would still like to
have the option to start building them in our default build flow for
testing. Also there is the added advantage of users being able to see what
is needed in case they choose to enable these features.
Link: https://lore.kernel.org/r/20260226122508.2269682-1-n-francis@ti.com
Add sections dedicated to explaining how BIST and inline ECC can be
enabled via the config fragments.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
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 <jonas@kwiboo.se>
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
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 <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add Kconfig option OF_SYSTEM_SETUP=y to support booting 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: 10 00 00 (otp)
ip-state: 30 9e 04 (policy)
remove cpu-map cluster1
rename cpu-map cluster2
fail gpu
fail rkvdec1
fail rkvenc1
fail cpu cpu@400
fail cpu cpu@500
and on a Radxa E52C:
cpu-code: 35 82
ip-state: 00 04 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 <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Flashing U-Boot for Exynos 7870 requires creating a stub device tree,
where certain properties and nodes are defined which are populated by
the previous bootloader in the phones.
Since these properties are now available in the U-Boot device tree, it's
now possible to use the same blob generated by U-Boot in place of the
stub, when creating boot images. Update the build documentation to
reflect the same.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
U-Boot for this board is programmed to use the external DTB if an
internal device tree is not available. This makes it safe to build boot
images using the non-DTB U-Boot binary, while taking up less space.
Reflect this change in documentation.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Since there is only one internal device tree allowed in U-Boot, the
DEVICE_TREE flag is required for building images for various devices.
Document it in the build guide.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Rasmus Villemoes <ravi@prevas.dk> 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/20260129105433.2624686-1-ravi@prevas.dk
Document how one can use the CONFIG_SPL_AM33XX_MMCSD_MULTIPLE option
to implement a scheme for failsafe updating of the whole bootloader on
the am335x.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Select remoteproc related configs for i.MX95 EVK to support manage CM7
using 'rproc' cmd.
Update doc to show details on starting CM7 using rproc cmd.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Kuan-Wei Chiu <visitorckw@gmail.com> 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/20260107201838.3448806-1-visitorckw@gmail.com
[trini: Re-sort MAINTAINERS entries]
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <visitorckw@gmail.com>
Tested-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Updates to the JH7110 common description:
- add detailed overview of JH-7110 SoC and boot process
- revise descriptions of deprecated StarFive loader modes
- refresh build directions grouped with SPL debug advice
- reduce usage instructions into common methods shared by supported boards
- cite starfive_visionfive2 board maintainer description of StarFive loader
- cite published datasheets for ambient operating temperature data
Redundant/deprecated sections of each board doc are dropped accordingly:
- deepcomputing fml13v01
- milk-v mars
- pine64 star64 (also add inclusion of JH7110 common description)
- visionfive2
Signed-off-by: E Shattow <e@freeshell.de>
Add a chapter about networking to the QEMU board documentation.
Describe both different types of networking as well as different emulated
NICs.
Suggested-by: Manjae Cho <manjae.cho@samsung.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
