Commit dc3765ede5 ("doc: Switch from setenv to env set") was
too eager to switch "setenv" to "env set" and also incorrectly
rewrote "gpt setenv" to "gpt env set". Undo this error.
Fixes: dc3765ede5 ("doc: Switch from setenv to env set")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's either "as with" or "like" but not "as", as reported by Simon.
Let's fix this oversight.
Fixes: 06f0143945 ("doc: CONTRIBUTE: tell people reviewing *is* contributing")
Reported-by: Simon Glass <sjg@chromium.org>
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The attribute mnemonic table did not cover EFI_MEMORY_ISA_VALID and the
EFI_MEMORY_ISA_MASK field, and attribute bits without a mnemonic were
silently dropped, so a memory map carrying ISA-specific, invalid or not
yet known attributes displayed incomplete information without any hint
that something was missing.
Add a mnemonic for EFI_MEMORY_ISA_VALID and print the ISA-specific
field as ISA=<value> when it is valid, instead of decoding bits whose
meaning U-Boot cannot know. Any remaining bits that match neither the
mnemonic table nor the ISA field are printed as a hexadecimal value.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
The efi and efidebug commands each carried their own code for printing
the EFI memory map, with separate tables of memory type and attribute
names. The copies had drifted: efidebug knew EFI_PERSISTENT_MEMORY_TYPE
while 'efi mem' printed it as '<invalid>', neither table knew
EFI_UNACCEPTED_MEMORY_TYPE, and the 'efi mem' printer had misaligned
column headers, a broken '<gap>' line and a superfluous Virtual column:
the map is identity mapped before SetVirtualAddressMap() is called, so
the field carries no information at the time the command can run.
Move the printing loop of 'efidebug memmap' into efi_common.c as
efi_show_memmap(), which is linked into both commands, and use it from
both. The second copy in 'efi mem' is deleted together with
efi_print_mem_table() and the private sorting and merging code,
including the 'all' argument.
The memory type names follow the UEFI specification with the leading
'Efi' and the trailing 'Type' stripped, for example ConventionalMemory
for EfiConventionalMemory, and the missing name for unaccepted memory
is added. The type column is widened to fit the longest name,
MemoryMappedIOPortSpace.
The shared function iterates the map with the descriptor size reported
by the firmware instead of assuming sizeof(struct efi_mem_desc). This
matters for 'efi mem' under EDK II based firmware, which reports a
descriptor size of 0x30. The memory map key, which was printed
uninitialized on the payload path, is now initialized. The command
documentation is updated with output captured from the app running
under OVMF, and documents why virtual addresses are not shown.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
The current documentation doesn't work as-is for extracting the DDR
training binary from the vendor bootloader. There are some seemingly
undocumented alignment requirements that we need to meet by padding the
binary file. Add some instructions on how to do this with objcopy. Also
fix a minor spelling mistake while we're here.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <stefan.roese@mailbox.org>
[sr: fix title underline length]
u-boot-dfu-20260728
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-dfu/-/pipelines/769
Android:
* avb: Update libavb to AOSP 1.3.0
* avb: Fix memory leak on mmc_part
* bootmeth_android: Fix memory leaks for AvbOps and verify-data
* bootmeth_android: Fix out-of-bounds access in bootconfig parsing
USB Gadget:
* cmd: ums: Set serial# on iSerial device descriptor
* dwc2: Set maxpacket_limit and endpoint capabilities to prepare for
udc core migration
* ci_udc: Fix ep type in ep_enable()
* ci_udc: Set usb request status to handle complete callback
* ci_udc: Ensure dtds are inactive before completing request
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-imx/-/pipelines/749
- Support authenticating signed Mcore container image on i.MX9.
- Support booting CM70, CM71 and CM33 sync cores on i.MX9.
- Add i.MX SNVS RTC driver.
- Detect RAM sizes on Toradex smarc and aquila i.MX95 boards.
- Add support for the Librem5 devkit.
- Subtract half a cycle instead of three quarters of a cycle after DQS
gating calibration on i.MX6.
- Several tqma6 improvements.
- Add product ID support for new Toradex boards.
- Switched to use upstream pinctrl header include,
- Dropped SDHCI DT properties in U-Boot-specific DT for NanoPi R5 as
most are present upstream and those which aren't are breaking devices,
- Fixed ECC strength mismatch between reading and writing on non-0
NAND chips configured as boot medium (nand-is-boot-medium),
- Moved Simon to reviewer for ARM ROCKCHIP,
- Fixed build issue related to GPT capsule support accessing a struct
member only present when CONFIG_PARTITION_TYPE_GUID is set,
- Added support for new devices:
- Anbernic RG-DS
- ROC-RK3588S-PC
Vincent Jardin <vjardin@free.fr> says:
3 commits providing documentation of impacts and testing the dispatch
for null_dev_desc_ok fstypes (semihosting, ubifs, sandbox) in the
generic `load <iface> ...` command.
The test does not cover ubifs, I could not make it work with
qemu. Since the code logic is there and testing with semihost
is done, it should cover the needed cases.
Link: https://lore.kernel.org/r/20260715165735.3207801-1-vjardin@free.fr
Document the usage of remoteproc on R-Car Gen5 RSIP U-Boot port
and clarify how to start Cortex-R52 cores from U-Boot on RSIP.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The "env" command is the recommended environment management command,
its "print" subcommand is the equivalent replacement for legacy "printenv"
command. Update the documentation to use the contemporary "env print"
command instead of legacy "printenv" command.
Note that the "printenv" command is unlikely to be removed from U-Boot
in the near future due to it being integral part of the command line
ABI.
Implemented using:
$ sed -i 's@\<printenv\>@env print@g' $(git grep -li '\<printenv\>' doc/) README
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The "env" command is the recommended environment management command,
its "set" subcommand is the equivalent replacement for legacy "setenv"
command. Update the documentation to use the contemporary "env set"
command instead of legacy "setenv" command.
Note that the "setenv" command is unlikely to be removed from U-Boot
in the near future due to it being integral part of the command line
ABI.
Implemented using:
$ sed -i 's@\<setenv\>@env set@g' $(git grep -li '\<setenv\>' doc/) README
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add that the "BOOT" button must be used
to switch the board to fastboot mode.
Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Reviewed-by: Yao Zi <me@ziyao.cc>
Document the dispatch path added by the former commit
fs: dispatch null_dev_desc_ok filesystems before lookup
Add a null-block-device interfaces section that:
* lists the three fstypes that can benefit of it (semihosting, ubifs,
sandbox) and the CONFIG option that builds each
* explains the '-' convention for the unused <dev[:part]> field
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Although it has similar naming the Librem 5 Devkit is a completely
different design from the Librem 5 phone. It uses an imx8mq SOM from
Emcraft, a separate HDMI port instead of DisplayPort, different USB-C
chip, panel, etc.
This is based on a Emcraft's SOM documentation, Purism's downstream fork
and the available schematics of the devkit.
Link: https://developer.puri.sm/Librem5/Development_Environment/Boards/imx8.html
Link: https://source.puri.sm/Librem5/dvk-mx8m-bsb
Co-authored-by: Angus Ainslie <angus@akkea.ca>
Co-authored-by: Manuel Traut <manut@mecka.net>
Signed-off-by: Manuel Traut <manut@mecka.net>
Tested-by: Manuel Traut <manut@mecka.net>
Signed-off-by: Guido Günther <agx@sigxcpu.org>
[fabio: Removed the arch/arm/dts/Makefile entry that does not apply and
it is not needed as the board uses OF_UPSTREAM]
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Note that verification is performed by the libavb copy vendored under
lib/libavb/ (AVB version 1.3.0) and which parts are U-Boot-specific, and
pin the README reference to the exact upstream commit the vendored copy
corresponds to instead of a moving master branch.
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
With CONFIG_FIT_BEST_MATCH, fit_conf_find_compat() selects the
configuration matching the most specific U-Boot compatible string; on
equal matches the first listed configuration wins and the configurations
node 'default' property is never consulted.
A FIT whose configurations all share the same base devicetree compatible
(e.g. one manifest carrying a base tree plus overlay combinations for a
single board) therefore always boots the first configuration, silently
ignoring the default chosen by the manifest author.
Break score ties in favour of the default configuration. A strictly
better compatible match still wins over it, and FITs without a default
keep the current first-listed behaviour.
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Rasmus Villemoes <rv@rasmusvillemoes.dk> says:
This started by me wanting something like what patch 8 does. That
wasn't too hard, except we had no strcasestr(), and also our regex
engine (which I didn't really want to pull into the mix anyway)
doesn't have a flag that requests case-insensitive matching. So I
wanted to add strcasestr(), but then I stumbled on a bunch of stuff
that should be cleaned up in str-land.
Link: https://lore.kernel.org/r/20260708203711.849489-1-rv@rasmusvillemoes.dk
Add a little documentation for the config command and its new ability
to filter the output.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
The K1 SPL patchset requires DDR firmware integration and FSBL signing
steps that are not covered by existing documentation. Add a SoC-level
guide so reviewers and developers can build and test on hardware.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Tested-by: Songsong Zhang <sszhang@vsit.ai>
Restructure K1 SoC support to handle multiple boards through a single
configuration:
1. Rename bananapi-f3_defconfig to spacemit_k1_defconfig.
2. Move all K1 board files to board/spacemit/k1/.
3. Replace TARGET_BANANAPI_F3 with TARGET_SPACEMIT_K1 and rename the
board's <board>.h header to k1.h.
Eliminates the need for board-specific defconfigs while maintaining
hardware compatibility.
Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Link: https://patch.msgid.link/20260519-b4-k1-spl-bring-up-v4-0-3915a2a904c1@riscstar.com
Tested-by: Songsong Zhang <sszhang@vsit.ai>
As part of moving our git forge to a new location, update all references
in tree to point to git.u-boot-project.org now.
Signed-off-by: Tom Rini <trini@konsulko.com>
The U-Boot Mailing-list is moving to the lists.u-boot-project.org
domain, so update all references of list.denx.de to the new
domain in the documentation.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
We don't have too many people looking at those at the moment, so having
people getting into the project by adding tests or documentation is I
believe a good thing so let's encourage those specific contributions.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
We are "a bit" struggling with reviewing things and it's most of the
time maintainers or long time contributors reviewing patches on the
mailing list.
Hint that reviewing is also contributing to the project and that even if
you don't feel you're an expert, your review is still welcome and can
help us catch bugs before they are merged.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
This way we don't need to make sure this link still points to something
that exists, as Sphinx will enforce it at build time. It also has the
added benefit that if someone builds the docs they will point at their
docs (though that is debatable whether that's useful, but at least you
stay on the same website).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The list-table layout does not allow grouping columns together,
convert the table into grid-table layout instead and rework it
such that SoC families, generations, architectures and SoCs are
grouped together. Include SoC column to group SoCs together, and
Core column which is useful on SoC like the R-Car X5H where U-Boot
can run on multiple cores in the SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Update the Build section and note that it is only applicable
in case the table above does not contain any board specific
instructions. Include information that the Architecture column
now contains toolchain setup instruction links.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen5 X5H Ironhide board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Retronix R-Car Gen4 V4H Sparrow Hawk board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 D3 Draak board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 E3 Ebisu board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 M3Le Geist board.
Include Renesas R-Car Gen3 SPI NOR installation procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board.
Include generic and HyperFlash Renesas R-Car Gen3 installation
procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add documents which briefly outline how to set up the SH4/Aarch32/Aarch64
toolchains, for future use in Renesas documentation. Reference all these
documents in the renesas list of boards "Arch" column.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add U-Boot's PMBus 1.x layer: the decoder/transport library, the
pmbus CLI command and a generic DT binding.
The subsequent commits provide the UCLASS_REGULATOR adapter and per-chip
drivers.
U-Boot's PMBus support is not a hwmon clone of Linux's
drivers/hwmon/pmbus/. Linux owns the runtime side (polling, sysfs,
alert IRQs, fan loops). U-Boot owns the boot-time side in order to,
- identify the PMBus regulators a board carries: MFR_ID/
MFR_MODEL/MFR_REVISION + sanity checks.
- print telemetry (VIN/VOUT/IIN/IOUT/POUT/TEMP) so an
operator can confirm rail voltages and faults before the kernel
- decode any chip alerts (STATUS_VOUT/STATUS_IOUT/STATUS_INPUT/
STATUS_TEMPERATURE/STATUS_CML) so a boot log shows why the
previous boot failed or the board had been power cycled because
of an outage (typically over temperature or under current).
Out of scope by design: no periodic polling, no sysfs, no fan-speed
control loop, no PMBUS_VIRT_* sensor virtualisation, no caching.
If a use case needs any of those, the answer should be "wait until
Linux comes up". It shall remain a thin layer.
The constants and structural shape (command codes, status bit names,
sensor-class enum, format enum, struct pmbus_driver_info) are
mirrored from Linux drivers/hwmon/pmbus/pmbus.h verbatim. The
decoders/encoders are reimplemented from the PMBus 1.3
specification because the surrounding hwmon context (struct
pmbus_data, sysfs caching, hwmon publication) does not apply.
The main benefits:
- One framework + CLI for any board carrying PMBus regulators:
no per-board PMBus implementation required anymore.
- Boards call pmbus_print_telemetry() / pmbus_print_status_word()
directly from boot init for a snapshot, sharing all decode +
format-dispatch with the CLI.
- Linux-compatible constants and DT binding so porting an existing
drivers/hwmon/pmbus/ chip is mechanical.
- Boot-time AVS/VID rail trim reuses the same decoders and
encoders as the CLI and the regulator path: no duplicate math.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
