To help guide developers down the right path, begin a document that
lists some best practices to follow when creating a new board port.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To make it consistent with the instructions from other NXP imx8m boards,
such as imx8mm-evk and imx8mn-evk, use U-Boot in-tree build in the
examples.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Originally, exporting the ATF_LOAD_ADDR was required, but since binman has
been used to generate the flash.bin, it is no longer needed to do
such manual export.
The ATF address is now passed via binman in imx8mp-u-boot.dtsi:
atf {
description = "ARM Trusted Firmware";
type = "firmware";
arch = "arm64";
compression = "none";
load = <0x970000>;
entry = <0x970000>;
atf_blob: atf-blob {
filename = "bl31.bin";
type = "atf-bl31";
};
};
Remove the unneeded export ATF_LOAD_ADDR line.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Describe the current situation wrt the handling of USB devices on AM33xx
based boards, taking the example of a common board (the Beagle Bone
Black) and explaining how the different USB gadgets can be used.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Fix the Verdin module output which was missing white space for correct
rendering.
While at it also leave product links, add section author also for the
Verdin iMX8M Mini and Plus, and add a missing CROSS_COMPILE export for
the Verdin iMX8M Mini.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Nishanth Menon <nm@ti.com> #verdin-am62
Reviewed-by: Tom Rini <trini@konsulko.com>
Bootloader debug usually tends to be a bit dicey prior to DDR and
serial port getting active in the system. JTAG typically remains the
only practical debug option during the initial bringup.
OpenOCD is one of the most popular environment for providing debug
capability via a GDB compatible interface for developers to work with.
Debugging U-Boot and bootloaders on K3 platform does have a bit of
tribal knowledge that is better documented in our common platform
documentation.
Signed-off-by: Jason Kacines <j-kacines@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
A Sandbox test is provided for the armffa command.
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT
V1.0A module and subsequent V1.1 launch configuration SKUs. They are
strapped to boot from their on-module eMMC. U-Boot supports booting
from the on-module eMMC only, DFU support is disabled for now due to
missing AM62x USB support.
The device trees were taken straight from Linux v6.5-rc1.
Boot sequence is:
SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE
---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img)
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Enhance the description of QEMU block devices
* Describe how to attach a virtio-blk device.
* Sort the command lines for MMC to match the other devices.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add Licensing to svg images to clarify the terms.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add more detail to the description of U-Boot boot phases:
* describe which steps are optional
* mentions alternative boot flows
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This brings PCI xHCI support to QEMU RISC-V and uses a usb keyboard
as one of the input devices.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Rick Chen <rick@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Radxa E25 is a network application carrier board for the Radxa CM3I SoM
with a RK3568 SoC. It features dual 2.5G ethernet, mini PCIe, M.2 B Key,
USB3, eMMC, SD, nano SIM card slot and a 26-pin GPIO header.
Features tested on a Radxa E25 v1.4:
- SD-card boot
- eMMC boot
- USB host
- PCIe/Ethernet adapters is detected
- SATA
Device tree is imported from linux next-20230728.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
ROCK 5A is a Rockchip RK3588S based SBC (Single Board Computer) by Radxa.
There are tree variants depending on the DRAM size : 4G, 8G and 16G.
Specifications:
Rockchip Rk3588S SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
4/8/16GB memory LPDDR4x
Mali G610MC4 GPU
MIPI CSI 2 multiple lanes connector
4-lane MIPI DSI connector
Audio – 3.5mm earphone jack
eMMC module connector
uSD slot (up to 128GB)
2x USB 2.0, 2x USB 3.0
2x micro HDMI 2.1 ports, one up to 8Kp60, the other up to 4Kp60
Gigabit Ethernet RJ45 with optional PoE support
40-pin IO header including UART, SPI, I2C and 5V DC power in
USB PD over USB Type-C
Size: 85mm x 56mm (Raspberry Pi 4 form factor)
Kernel commits:
d1824cf95799 ("arm64: dts: rockchip: Add rock-5a board")
991f136c9f8d ("arm64: dts: rockchip: Update sdhci alias for rock-5a")
304c8a759953 ("arm64: dts: rockchip: Remove empty line from rock-5a")
cda0c2ea65a0 ("arm64: dts: rockchip: Fix RX delay for ethernet phy on rk3588s-rock5a")
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Update documentation on how to write a bootable u-boot-rockchip-spi.bin
image into SPI flash. This removes the reference to a hardcoded and now
obsolete 0x60000 payload offset.
Also remove an obsolete reference to pad_cat.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <foss+u-boot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Pine64 SOQuartz compute module is mostly pin-compatible with the RPi
CM4 form factor. Therefore, it can slot into the official Raspberry Pi
CM4 IO carrier board. Add this configuration to U-Boot.
Features tested with a SOQuartz 4GB v1.1 2022-07-11:
- SD-card boot
- eMMC boot
- USB host
Device tree is imported from linux v6.4.
Co-developed-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Pine64 SOQuartz Blade board is a carrier board for the SOQuartz
CM4-compatible compute module. It features PoE, an M.2 slot, an SD card
slot, HDMI, USB, serial and ethernet.
Features tested with a SOQuartz 4GB v1.1 2022-07-11:
- SD-card boot
- eMMC boot
- PCIe/NVMe
- USB host
Device tree is imported from linux v6.4.
Co-developed-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Pine64 SOQuartz Model A board is a carrier board for the SOQuartz
CM4-compatible compute module. It exposes PCIe, ethernet, USB, HDMI,
CSI, DSI, eDP and a 40 pin GPIO header, and is powered by 12V DC.
Features tested with a SOQuartz 4GB v1.1 2022-07-11:
- SD-card boot
- eMMC boot
- PCIe/NVMe/AHCI
- USB host
Device tree is imported from linux v6.4.
Co-developed-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Pine64 Quartz64 Model B is a credit-card sized single-board
computer based on the Rockchip RK3566 SoC. The board features an M.2
PCIe slot, USB3, USB2, eMMC, SD, ethernet, HDMI, analog audio out, a
40 pin GPIO header and a DSI and CSI port, as well as on-board Wi-Fi.
Features tested on a Quartz64-B 4GB v1.4 2022-06-06:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe
- USB host
Device tree is imported from linux v6.4.
Co-developed-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Pine64 Quartz64 Model A is a single-board computer based on the
Rockchip RK3566 SoC. The board features USB3, SATA, PCIe, HDMI, USB2.0,
CSI, DSI, eDP, eMMC, SD, and an e-paper parallel port, as well as a
20 pin GPIO header.
Features tested on a Quartz64-A 8GB v2.0 2021-04-27:
- SD-card boot
- eMMC boot
- PCIe/NVMe/AHCI
- USB host
Device tree is imported from linux v6.4.
Co-developed-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
- Resync some of the K3 DTS files with the kernel, and pull in some
required related updates to keep drivers in sync with the dts files
now. Bring in some incremental fixes on top of one of the series I
applied recently as well as updating the iot2050 platform. Also do a
few small updates to the K2 platforms.
ATF is now called BL31, and OP-TEE since 3.21 suggests to use
tee-raw.bin instead of (the still identical) tee-pager_v2.bin.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.
Suggested-by: Andrew Davis <afd@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC,
a slightly modified version of the RK3568 SoC.
Features tested on a ODROID-M1 8GB v1.0 2022-06-13:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe/AHCI
- SATA port
- USB host
Device tree is imported from linux v6.4.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add board-specific devicetree/config for the RK3399T-based Radxa ROCK 4SE
board. This board offers similar peripherals in a similar form-factor to
the existing ROCK Pi 4B but uses the cost-optimised RK3399T processor
(which has different OPP table than the RK3399) and other minimal hardware
changes.
Kernel tag: next-20230719
Kernel commits:
- 86a0e14a82ea ("arm64: dts: rockchip: Add Radxa ROCK 4SE")
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Neural Compute Module 6B(Neu6B) is a 96boards SoM-CB compute module
based on Rockchip RK3588J from Edgeble AI.
Add support for this SoM and IO board.
Signed-off-by: Jagan Teki <jagan@edgeble.ai>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Update the Anbernic RGxx3 documentation to note that panel detection
has been added and how it works.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Introduce common variables to define a generic build instruction that is
then used in specific board specific description.
Labels are introduced in the evm.rst files to be then reused in variant
board documentation as well.
While at this, drop using ARCH=arm when building u-boot sources. This
practice has been discouraged for some time and can potentially create
problems with Kconfig rules related to aarch64. It's best to avoid
this approach.
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram instead of the ascii version
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram instead of the ascii version
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram and reuse across the platforms as they
are common.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
We have duplication of sources which makes it hard to sustain across the
board, but at the same time, we'd like to ensure readers get specific
information without having to cross refer to different documentation to
get piecemeal information that they need to put together.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Now that we are using binman in all cases on these platforms, reword
things to be clearer that for filesystem booting we need to use a
specific name for each component.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
* Add a new page about the emulation of block devices
* Add semihosting to the emulation index page
* Set toc maxdepth to 1 to improve readability
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
%s/device_compat\/.h/device_compat.h/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update the following requirements to their latest version:
* Pygments - syntax highlighting
* pytz - world timezone definitions
* certifi - Mozilla's CA bundle
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This reverts commit d927d1a808, reversing
changes made to c07ad9520c.
These changes do not pass CI currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
- Actually merge the assorted K3 platform improvements that were
supposed to be in commit 247aa5a191 ("Merge branch
'2023-07-21-assorted-TI-platform-updates'")
Apply the trailing space changes in the guide document.
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Having saved environments usually causes inconsistencies while in
development workflow. The saved environments conflict with the
default ones that U-boot should be updating during development
but that doesn't happen and the saved environments need to be
reset during bootups to test the changes causing extra debugs.
Remove the saved environments as a default. Environments can always
be re-enabled locally if one does like them or needs them for
some production environment. Optionally, Uenv.txt can also be used on
some of the boot media.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Earlier documentation specified builds for generating bootloader images
using an external TI repository k3-image-gen and core-secdev-k3. Modify
this to using the binman flow so that user understands how to build the
final boot images.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
To understand usage of DDR in A53 SPL stage, add a table showing region
and space used by major components of SPL.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some devices keep 2 copies of the bootloader_message in the misc
partition and write each in sequence when updating. This ensures that
there is always one valid copy of the bootloader_message. Teach u-boot
to optionally try a backup bootloader_message from a specified offset if
the primary one fails its CRC check.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Some files have an associated address. Show this with the 'qfw list'
command so that it is possible to dump the data.
Note that the reference to 'md' is for the md.rst file, not a
markdown file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some devices have multiple partition types available on the same media.
It is sometimes useful to see these to check that everything is working
correctly.
Provide a way to manually set the partition-table type, avoiding the
auto-detection process.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sometimes a previous bootloader has written ACPI tables. It is useful to
be able to find and list these. Add an 'acpi set' command to set the
address for these tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add documention for the x86 'mtrr' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Some Linux parameters can be set automatically by U-Boot, if it knows the
device being used. For example, since U-Boot knows the serial console
being used, it can add parameters for earlycon and console.
Add support for this.
Note that this is an experimental feature and we will see how useful it
turns out to be. It is very handy for ChromeOS, since otherwise it is very
difficult to manually determine the UART address or port number,
particularly in a script.
Provide an example of how this is used with ChromeOS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a bootflow command to update the command line more easily. This allows
changing a particular parameter rather than editing a very long strings.
It is also easier to handle with scripting.
The new 'bootflow cmdline' command allows getting and setting single
parameters.
Fix up the example output while we are here, since there are a few new
items.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some operating systems have a command line which can be adjusted before
booting. Store this in the bootflow so it can be controlled within
U-Boot.
Fix up the example output while we are here, since there are a few new
items.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To enforce anti-rollback to any older version, dtb must be
always update manually. This should be described in the
documentation.
This commit also adds the recommendation that secure system should not
enable the fdt command because lowest-supported-version
property in device tree can be changed by fdt command.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
The new opt-out setting, CONFIG_ENV_MMC_PARTITION, statically sets
the MMC environment partition name. Prior to this patch, the only way
to declare this partition name was by creating a
'u-boot,mmc-env-partition' parameter in the device-tree's /config node.
This setting provides additional flexibility, particularly in cases
where accessing the device-tree is not straightforward (e.g. QEMU).
If undeclared, the device-tree's setting will be used.
Signed-off-by: Emmanuel Di Fede <emmanuel.difede@cysec.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add a new 'cedit' command which allows editing configuration using an
expo. The configuration items appear as menus on the display.
This is extremely basic, only supporting menus and not providing any way
to load or save the configuration.
Signed-off-by: Simon Glass <sjg@chromium.org>
The only way to create an expo at present is by calling the functions to
create each object. It is useful to have more data-driven approach, where
the objects can be specified in a suitable file format and created from
that. This makes testing easier as well.
Add support for describing an expo in a devicetree node. This allows more
complex tests to be set up, as well as providing an easier format for
users. It also provides a better basis for the upcoming configuration
editor.
Signed-off-by: Simon Glass <sjg@chromium.org>
It looks better if menus have a bit of an inset, rather than be drawn hard
up against the background. Also, menu items look better if they have a bit
of spacing between them.
Add theme options for these and implement the required changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
In 'popup' mode, the expo allows moving around the objects in a scene.
When 'enter' is pressed on a menu, it opens and the user can move around
the items in the menu.
Implement this using keypress handles and actions.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to manually set the fonts of all objects to be consistent.
Some spacing settings are also better set globally than by manually
positioning each object.
Add a 'theme' to the expo, to hold this information. For now it includes
only the font size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a way to set the full dimensions of objects, i.e. including the
width and height.
For menus, calculate the bounding box of all objects in the menu. Set all
labels to be the same size, so that highlighting works correct, once
implemented.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a way to set this value so that it is easy to separate the
statically allocated IDs (generated by the caller) from those
generated dynamically by expo itself.
Signed-off-by: Simon Glass <sjg@chromium.org>
The csf_spl.txt and csf_fit.txt templates contain file paths which must
be edited for the location of your NXP CST generated key files.
Streamline the process of signing an image by assigning unique var names
to these which can be expended from env variables in the csf.sh script.
The following vars are used:
SRK_TABLE - full path to SRK_1_2_3_4_table.bin
CSF_KEY - full path to the CSF Key CSF1_1_sha256_4096_65537_v3_usr_crt.pem
IMG_KEY - full path to the IMG Key IMG1_1_sha256_4096_65537_v3_usr_crt.pem
Additionally provide an example of running the csf.sh script.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
According to Documentation/devicetree/bindings/spi/spi-gpio.yaml
from Linux, the recommended spio-gpio properties are:
sck-gpios, miso-gpios and mosi-gpios.
gpio-sck, gpio-mosi and gpio-miso are considered deprecated.
Update the bindings to suggest the recommeded properties.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The defconfig file name for StarFive VisionFive2 has been changed, and
the documentation description has also changed.
Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
