diff options
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/bootstd/overview.rst | 8 | ||||
| -rw-r--r-- | doc/develop/coccinelle.rst | 10 | ||||
| -rw-r--r-- | doc/develop/distro.rst | 8 | ||||
| -rw-r--r-- | doc/develop/driver-model/fs_firmware_loader.rst | 2 | ||||
| -rw-r--r-- | doc/develop/driver-model/serial-howto.rst | 4 | ||||
| -rw-r--r-- | doc/develop/driver-model/virtio.rst | 2 | ||||
| -rw-r--r-- | doc/develop/index.rst | 1 | ||||
| -rw-r--r-- | doc/develop/pmbus.rst | 637 | ||||
| -rw-r--r-- | doc/develop/process.rst | 2 | ||||
| -rw-r--r-- | doc/develop/pytest/test_fit_verity_sign.rst | 10 | ||||
| -rw-r--r-- | doc/develop/pytest/usage.rst | 2 | ||||
| -rw-r--r-- | doc/develop/release_cycle.rst | 14 | ||||
| -rw-r--r-- | doc/develop/security.rst | 2 | ||||
| -rw-r--r-- | doc/develop/sending_patches.rst | 41 | ||||
| -rw-r--r-- | doc/develop/tests_writing.rst | 4 | ||||
| -rw-r--r-- | doc/develop/uefi/iscsi.rst | 6 | ||||
| -rw-r--r-- | doc/develop/uefi/u-boot_on_efi.rst | 4 | ||||
| -rw-r--r-- | doc/develop/uefi/uefi.rst | 14 |
18 files changed, 704 insertions, 67 deletions
diff --git a/doc/develop/bootstd/overview.rst b/doc/develop/bootstd/overview.rst index 397f6db18b4..cf8ef419d4b 100644 --- a/doc/develop/bootstd/overview.rst +++ b/doc/develop/bootstd/overview.rst @@ -152,7 +152,7 @@ boot_targets This environment variable can be used to control the list of bootdevs searched and their ordering, for example:: - setenv boot_targets "mmc0 mmc1 usb pxe" + env set boot_targets "mmc0 mmc1 usb pxe" Entries may be removed or re-ordered in this list to affect the boot order. If the variable is empty, the default ordering is used, based on the priority of @@ -169,7 +169,7 @@ used by the old distro scripts. This environment variable can be used to control the list of bootmeths used and their ordering for example:: - setenv bootmeths "extlinux efi" + env set bootmeths "extlinux efi" Entries may be removed or re-ordered in this list to affect the order the bootmeths are tried on each bootdev. If the variable is empty, the default @@ -882,7 +882,7 @@ Other ideas: .. _distro_bootcmd: https://github.com/u-boot/u-boot/blob/master/include/config_distro_bootcmd.h -.. _BootLoaderSpec: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ -.. _distro_boot: https://github.com/u-boot/u-boot/blob/master/boot/distro.c +.. _BootLoaderSpec: https://uapi-group.org/specifications/specs/boot_loader_specification/ +.. _distro_boot: https://github.com/u-boot/u-boot/blob/v2023.04/boot/bootmeth_distro.c .. _bootflow_h: https://github.com/u-boot/u-boot/blob/master/include/bootflow.h .. _migrate_patch: https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ diff --git a/doc/develop/coccinelle.rst b/doc/develop/coccinelle.rst index 70274c3f5f5..d0ad803fc7b 100644 --- a/doc/develop/coccinelle.rst +++ b/doc/develop/coccinelle.rst @@ -34,7 +34,7 @@ of many distributions, e.g. : Some distribution packages are obsolete and it is recommended to use the latest version released from the Coccinelle homepage at -http://coccinelle.lip6.fr/ +https://coccinelle.gitlabpages.inria.fr/website/ Or from Github at: @@ -58,15 +58,9 @@ https://github.com/coccinelle/coccinelle/blob/master/install.txt Supplemental documentation -------------------------- -For supplemental documentation refer to the wiki: - -https://bottest.wiki.kernel.org/coccicheck - -The wiki documentation always refers to the linux-next version of the script. - For Semantic Patch Language(SmPL) grammar documentation refer to: -http://coccinelle.lip6.fr/documentation.php +https://coccinelle.gitlabpages.inria.fr/website/documentation.html Using Coccinelle on the Linux kernel ------------------------------------ diff --git a/doc/develop/distro.rst b/doc/develop/distro.rst index 01efce40a29..5e906750119 100644 --- a/doc/develop/distro.rst +++ b/doc/develop/distro.rst @@ -384,22 +384,22 @@ boot_scripts: scan_dev_for_extlinux: If you want to disable extlinux.conf on all disks, set the value to something - innocuous, e.g. setenv scan_dev_for_extlinux true. + innocuous, e.g. env set scan_dev_for_extlinux true. scan_dev_for_scripts: If you want to disable boot.scr on all disks, set the value to something - innocuous, e.g. setenv scan_dev_for_scripts true. + innocuous, e.g. env set scan_dev_for_scripts true. boot_net_usb_start: If you want to prevent USB enumeration by distro boot commands which execute - network operations, set the value to something innocuous, e.g. setenv + network operations, set the value to something innocuous, e.g. env set boot_net_usb_start true. This would be useful if you know your Ethernet device is not attached to USB, and you wish to increase boot speed by avoiding unnecessary actions. boot_net_pci_enum: If you want to prevent PCI enumeration by distro boot commands which execute - network operations, set the value to something innocuous, e.g. setenv + network operations, set the value to something innocuous, e.g. env set boot_net_pci_enum true. This would be useful if you know your Ethernet device is not attached to PCI, and you wish to increase boot speed by avoiding unnecessary actions. diff --git a/doc/develop/driver-model/fs_firmware_loader.rst b/doc/develop/driver-model/fs_firmware_loader.rst index 149b8b436ec..630daf636f1 100644 --- a/doc/develop/driver-model/fs_firmware_loader.rst +++ b/doc/develop/driver-model/fs_firmware_loader.rst @@ -6,7 +6,7 @@ File System Firmware Loader This is file system firmware loader for U-Boot framework, which has very close to some Linux Firmware API. For the details of Linux Firmware API, you can refer -to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html. +to https://docs.kernel.org/driver-api/firmware/index.html. File system firmware loader can be used to load whatever(firmware, image, and binary) from the storage device in file system format into target location diff --git a/doc/develop/driver-model/serial-howto.rst b/doc/develop/driver-model/serial-howto.rst index 17b53e3cabf..8ca9a016f9a 100644 --- a/doc/develop/driver-model/serial-howto.rst +++ b/doc/develop/driver-model/serial-howto.rst @@ -97,8 +97,8 @@ Here are some things you might need to consider: uart2: uart2 { uart2_xfer: uart2-xfer { - rockchip,pins = <1 RK_PC2 RK_FUNC_2 &pcfg_pull_up>, - <1 RK_PC3 RK_FUNC_2 &pcfg_pull_none>; + rockchip,pins = <1 RK_PC2 2 &pcfg_pull_up>, + <1 RK_PC3 2 &pcfg_pull_none>; }; ... }; diff --git a/doc/develop/driver-model/virtio.rst b/doc/develop/driver-model/virtio.rst index 9a5e3240c3c..e5da9f4301c 100644 --- a/doc/develop/driver-model/virtio.rst +++ b/doc/develop/driver-model/virtio.rst @@ -284,5 +284,5 @@ for the remove method to be called before jumping to OS. 6. do funny stuff with the driver -.. _VirtIO: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf +.. _VirtIO: https://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf .. _QEMU: https://www.qemu.org diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 51fd68fa04b..0b757e8601e 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -49,6 +49,7 @@ Implementation logging makefiles menus + pmbus printf smbios spl diff --git a/doc/develop/pmbus.rst b/doc/develop/pmbus.rst new file mode 100644 index 00000000000..f5550541e83 --- /dev/null +++ b/doc/develop/pmbus.rst @@ -0,0 +1,637 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +PMBus support in U-Boot +======================= + +This document describes U-Boot's PMBus 1.x support: what it is for, +how it is structured, and how to add support for a new PMBus chipn +either from scratch from a chip datasheet or by porting an existing +Linux ``drivers/hwmon/pmbus/`` driver. + +.. contents:: + :local: + :depth: 2 + +Intent and scope +---------------- + +U-Boot's PMBus layer is not a hardware monitoring (hwmon) clone of +the Linux kernel's ``drivers/hwmon/pmbus/`` subsystem. Linux owns the +runtime side: continuous polling, sysfs publication, alert IRQ +handling, fan control loops. U-Boot owns the boot time side. Concretely +the U-Boot PMBus support exists to: + +* Identify the PMBus regulator(s) a board carries at boot: + ``MFR_ID``, ``MFR_MODEL``, ``MFR_REVISION`` reads, plus a quick + ``STATUS_WORD`` sanity check. +* Print telemetry so an operator can confirm rail voltages, input + current, and temperature before handing off to the kernel. One shot + reads, on demand, via the ``pmbus`` and ``regulator`` U-Boot + commands (``pmbus dev <name>; pmbus telemetry``, + ``regulator dev <name>; regulator value``). +* Decode chip alerts when a rail trips an over/under voltage, + over current, or thermal threshold; so a boot log shows why the + previous boot failed, before the kernel even comes up. +* Optionally trim a critical rail (typically the SoC core) before + the kernel takes over; "set the voltage prior to a kernel boot + to better protect the board". This is the existing + ``board/nxp/common/vid.c`` AVS path and any future per board + speed binning trim. + +Out of scope, by design: + +* No periodic polling. No worker thread. No background updates. +* No sysfs / procfs / userspace surface. U-Boot has none. +* No fan speed control loop. The kernel runs that. +* No long tail of virtual sensor registers (``PMBUS_VIRT_*``). +* No sensor caching / update timestamps. + +If you find yourself wanting any of those, the answer is "wait until +Linux comes up". Keep U-Boot's PMBus surface minimal. + +Architecture overview +--------------------- + +The framework is split into four layers (layer 3 comes in two +flavours, 3a and 3b), + +:: + + +----------------------------------------+ + | Layer 1: include/pmbus.h | + | Standard PMBus 1.x command codes, | + | numeric format enum, sensor class | + | enum, struct pmbus_driver_info, | + | decoder + transport prototypes, | + | STATUS_WORD bit names. | + +----------------------------------------+ + | Layer 2: lib/pmbus.c | + | Format decoders (LINEAR11/LINEAR16/| + | DIRECT) and encoder (LINEAR16), | + | two stage SMBus block read helper, | + | STATUS_*-bit print tables, generic | + | dispatcher pmbus_reg2data(). | + +----------------------------------------+ + | Layer 3a: drivers/power/regulator/ | + | <chip>.c | + | UCLASS_REGULATOR per chip drivers | + | ; one struct pmbus_driver_info | + | plus regulator set_value/get_value | + | ops. Optional: per chip identify() | + | hook to refine format from the | + | chip's own VOUT_MODE. | + +----------------------------------------+ + | Layer 3b: drivers/power/regulator/ | + | pmbus_generic.c | + | Catch all driver matching | + | compatible = "pmbus". | + | Auto detects format via VOUT_MODE | + | and PMBUS_QUERY where supported. | + | Use for compliant chips with no | + | per chip driver yet; ship | + | telemetry today, write a per chip | + | driver later only if quirks demand | + | it. | + +----------------------------------------+ + | Layer 4: board/<vendor>/<board>/ | + | <chip>_diag.c | + | Diagnostic commands only: | + | <chip>_info / <chip>_raw | + | Reads via regulator_get_value() | + | and lib/pmbus.c helpers. LINEAR / | + | DIRECT math NOT here. | + +----------------------------------------+ + +Generic vs. board specific separation rule. Layer 1, 2, and 3 +files are tree level and platform agnostic. Their comments may +reference only: + +* the PMBus 1.x specification, and +* chip manufacturer datasheets. + +Never a specific board, SoC, or product. Board-specific quirks +(a particular bus number, a particular slave address, a particular +PCB feedback divider, board local design notes) live exclusively in +``board/<vendor>/<board>/`` files. + +CLI commands +------------ + +The framework publishes one top level command, ``pmbus``, plus a +vendor namespace dispatcher so per chip code can register chip +specific extensions without touching the framework. + +Active device model +~~~~~~~~~~~~~~~~~~~ + +``pmbus`` mirrors the ``regulator`` command: select an active device +once, then operate on it across subcommands. The active device is +selected by I2C bus (decimal sequence number) and 7 bit address (hex, +``0x`` optional, à la ``i2c`` convention):: + + => pmbus dev 0:10 + pmbus: active i2c0:0x10 MFR_ID="MPS" MFR_MODEL="MPQ8785" vendor=mps + +The framework probes ``MFR_ID`` (in both natural and reverse byte +orders) at selection time, looks the result up in the chip match +registry populated by per chip code via ``pmbus_register_chip()``, +and caches the matched ``pmbus_driver_info``. All subsequent +subcommands consume that cached metadata. + +Standard subcommands +~~~~~~~~~~~~~~~~~~~~ + +:: + + pmbus list list UCLASS_REGULATOR devices (DM bound) + pmbus dev [<bus>:<addr>] show / select active PMBus device + pmbus info identification banner + driver_info + pmbus telemetry decoded VIN, VOUT, IIN, IOUT, TEMP + pmbus status decode every STATUS_* register + pmbus dump hex dump of every standard register + pmbus read <reg> [b|w|s] raw read (b=byte, w=word, s=string) + pmbus write <reg> <val> [b|w] raw write + pmbus clear [faults] issue CLEAR_FAULTS (03h) + pmbus vout [<uV>] read or set VOUT_COMMAND (microvolts) + pmbus scan [<bus>] PMBus aware probe of one or all I2C buses + +The ``<reg>`` argument accepts either a hexadecimal address +(``88``, ``0x`` optional) or a symbolic name (``READ_VIN``, +``VOUT_MODE``, ``MFR_ID``); symbolic names win when both parsed. +``<val>`` is hexadecimal too. Only ``pmbus vout``'s microvolt +argument and bus numbers are decimal. +Format selectors after the register select the SMBus transaction width: +``b`` for byte, ``w`` for 16 bit little endian word, +``s`` for the SMBus block read used by string registers. + +Decoded telemetry honours the active device's ``pmbus_driver_info``; +when no chip match has been registered, VOUT falls back to LINEAR16 +driven by ``VOUT_MODE`` and the other sensors fall back to LINEAR11. + +Vendor namespace +~~~~~~~~~~~~~~~~ + +Per chip drivers and board files publish chip specific subcommands +in the ``pmbus <vendor> ...`` namespace by calling +``pmbus_register_vendor_handler()`` at init time. The framework +dispatches ``pmbus mps last``, ``pmbus mps clear last``, and +``pmbus mps clear force`` to the MPS handler when the active +device matches the ``mps`` vendor. Additional vendor handlers for +``lltc``, ``renesas``, etc. land alongside the per chip drivers +that need them. + +Relationship to ``vdd_override`` / ``vdd_read`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The NXP Layerscape ``vdd_override <mV>`` and ``vdd_read`` commands +remain available in their original form for compatibility with +existing AVS production scripts. The new ``pmbus vout`` and +``pmbus vout <uV>`` subcommands cover the read and single shot +write paths against the same chips, but do not implement +``vdd_override``'s full sequence (board drop compensation, fuse +target derivation, multi step convergence loop, atomic +``PAGE_PLUS_WRITE`` block transaction, ``WRITE_PROTECT`` dance). +For interactive bring up ``pmbus vout`` is sufficient; for +production AVS, ``vdd_override`` stays canonical. + +Lifecycle: from board boot to Linux handoff +------------------------------------------- + +The PMBus framework spans the entire U-Boot lifecycle. This section +walks the boot timeline phase by phase, showing when each piece +comes online and how the regulator uclass and the ``pmbus`` CLI +converge on the same chip. + +Timeline overview +~~~~~~~~~~~~~~~~~ + +:: + + Phase 0 chip power on chip ramps to NVM default VOUT + Phase 1 boot ROM / SPL / TF-A PMBus typically untouched + Phase 2 U-Boot relocation, DM init regulators bound, not probed + Phase 3 first regulator probe chip driver runs, framework lights up + Phase 4 board hooks / boot scripts snapshot, AVS trim, gating + Phase 5 Linux handoff DT passed, chip state preserved + Phase 6 Linux runtime kernel pmbus driver takes over + +Phase 0: chip power on +~~~~~~~~~~~~~~~~~~~~~~ + +When the regulator chip receives its input voltage, it ramps its +output to the VOUT default programmed into its NVM at factory +provisioning. PMBus is silent: no software runs anywhere on the +SoC yet. + +Phase 1: pre U-Boot stages +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boot ROMs, secondary boot loaders (SPL, ARM TF-A BL2 / BL31) +typically do not touch PMBus. They focus on PLLs, DDR PHY init, +and bringing up enough hardware to load the next stage. Some +platforms have a pre U-Boot AVS path in board specific TF-A +code that writes ``VOUT_COMMAND`` from a fuse derived target; +that path is independent of the U-Boot framework described here. + +Phase 2: U-Boot relocation and DM init +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After relocation, U-Boot binds device tree nodes to drivers but +does not probe them. UCLASS_REGULATOR devices for PMBus chips +are bound (driver and DT match resolved) but the ``.probe`` +callback has not run yet. + +Framework state at this point: + +* chip match registry: empty +* vendor handler registry: empty +* active device: none +* regulator uclass: devices bound, none probed + +Phase 3: lazy regulator probe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The first caller into the regulator uclass for a given chip +triggers the chip driver's ``.probe``. Typical first callers: + +* a board ``EVENT_SPY`` at ``EVT_LAST_STAGE_INIT`` (boot snapshot) +* a U-Boot script: ``regulator dev <name>; regulator value`` +* the ``pmbus dev <name>`` CLI command (resolves to the regulator) +* another DT consumer with a ``regulator-supplies`` reference + +The probe chain looks like this:: + + <chip>_probe(dev) + pmbus_regulator_probe_common(dev, &<chip>_info, page) + dev_read_addr(dev) -> reg = <addr> + i2c_get_chip(dev->parent, addr) -> I2C chip handle + priv->i2c_dev = handle + priv->info = &<chip>_info + priv->page = page + (page > 0) write PMBUS_PAGE + <chip>_identify_vout(priv->i2c_dev) [optional] + read VOUT_MODE; refine info->format[PSC_VOLTAGE_OUT] + pmbus_regulator_apply_voltage_scale(dev, fb_div) [optional] + write PMBUS_VOUT_SCALE_LOOP if DT property set + pmbus_register_chip(&<chip>_match) [idempotent] + pmbus_register_vendor_handler(&<chip>_op) [idempotent] + +Once probed, three independent surfaces are functional against +the same chip: + +* the regulator uclass API (``regulator_get_value``, + ``regulator_set_value``, ``regulator_get_enable``, + ``regulator_set_enable``) +* the ``pmbus`` CLI (chip is reachable by name through + ``pmbus_resolve_by_name()``, by raw ``<bus>:<addr>`` through + ``pmbus_set_active()``) +* the chip's vendor extension subcommands (``pmbus <vendor> ...``) + +Phase 4: board hooks and boot scripts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boards hook the boot flow at well known points to drive board +specific PMBus behaviour. The framework prescribes none of these; +they are conventions: + +* boot time rail snapshot. An ``EVENT_SPY`` at + ``EVT_LAST_STAGE_INIT`` reads telemetry through the regulator + uclass and prints a one shot summary to the console. Useful + for operator visibility on serial during bring up. + +* pre kernel rail trim (AVS). A board hook in + ``board_late_init`` or a custom event spy reads a fuse derived + target voltage and calls ``regulator_set_value_force()`` to + trim the SoC core rail before kernel handoff. + +* Linux handoff gate. A bootcmd reads the rail voltage + through the regulator command and refuses to boot Linux if + the rail is outside the expected range. + +Phase 5: Linux handoff +~~~~~~~~~~~~~~~~~~~~~~ + +When U-Boot transfers control to Linux, it passes the device +tree (potentially patched). The DT compatible strings for PMBus +regulators must match those in the upstream kernel binding so +the kernel's ``drivers/hwmon/pmbus/<chip>.c`` picks them up. +Property names are shared with the kernel binding +(``regulator-name``, ``regulator-min-microvolt``, +``mps,vout-fb-divider-ratio-permille``, etc.); see "DT alignment +with Linux" below. + +The chip itself is left in the state U-Boot wrote it to. If +U-Boot trimmed VOUT, the chip stays at the trimmed voltage +through handoff. ``CLEAR_FAULTS`` state is preserved unless an +operator explicitly issued one. + +Phase 6: Linux runtime +~~~~~~~~~~~~~~~~~~~~~~ + +Linux's ``drivers/hwmon/pmbus/pmbus_core.c`` probes the chip, +exposes telemetry under ``/sys/class/hwmon``, and takes over +runtime voltage management through its regulator subsystem. +The hwmon framework polls periodically; U-Boot does not. + +Operation paths through the regulator uclass +-------------------------------------------- + +After the first probe completes, calls into the regulator uclass +for a PMBus chip flow through the shared helper. + +Read VOUT:: + + regulator_get_value(dev) + -> dm_regulator_ops->get_value + -> pmbus_regulator_get_value(dev) + pmbus_regulator_select_page(priv) + pmbus_read_byte(priv->i2c_dev, VOUT_MODE, &mode) + pmbus_read_word(priv->i2c_dev, READ_VOUT, &raw) + pmbus_reg2data(priv->info, PSC_VOLTAGE_OUT, raw, mode) + -> reg2data_linear16 (mode = 0) + -> reg2data_direct (chip configured for DIRECT) + return engineering value (microvolts) + +Write VOUT:: + + regulator_set_value(dev, uV) + -> dm_regulator_ops->set_value + -> pmbus_regulator_set_value(dev, uV) + pmbus_regulator_select_page(priv) + pmbus_read_byte(VOUT_MODE) + check (mode == LINEAR) [LINEAR16 only today] + raw = pmbus_data2reg_linear16(uV, mode) + dm_i2c_write(VOUT_COMMAND, raw) + +Read / write enable bit:: + + regulator_get_enable(dev) + -> pmbus_regulator_get_enable(dev) + pmbus_read_byte(OPERATION) & PB_OPERATION_ON + + regulator_set_enable(dev, on) + -> pmbus_regulator_set_enable(dev, on) + read OPERATION, set or clear PB_OPERATION_ON, write back + +Bus traffic per call: + +* ``get_value`` : 1 byte read (VOUT_MODE) + 1 word read (READ_VOUT) + + 1 byte write (PAGE) when ``page > 0`` +* ``set_value`` : 1 byte read (VOUT_MODE) + 1 word write (VOUT_COMMAND) + + 1 byte write (PAGE) when ``page > 0`` +* ``get_enable`` : 1 byte read (OPERATION) +* ``set_enable`` : 1 byte read (OPERATION) + 1 byte write (OPERATION) + +Common board hook patterns +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boot time rail snapshot:: + + static int my_board_pmbus_snapshot(void) + { + struct udevice *reg; + + if (regulator_get_by_platname("MY_RAIL", ®)) + return 0; + printf("MY_RAIL: VOUT = %d uV, enabled = %d\n", + regulator_get_value(reg), + regulator_get_enable(reg)); + return 0; + } + EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, my_board_pmbus_snapshot); + +The first call to ``regulator_get_value()`` triggers the chip +driver's ``.probe``, which seeds the chip match and vendor +extension registries. Subsequent ``pmbus`` CLI commands work +without further setup. + +Pre kernel rail trim (AVS):: + + int board_late_init(void) + { + struct udevice *reg; + int target_uV = compute_avs_target(); + + if (regulator_get_by_platname("VDD_CORE", ®)) + return 0; + return regulator_set_value_force(reg, target_uV); + } + +Use ``regulator_set_value_force()`` when the target may sit +outside the DT declared ``regulator-min-microvolt`` / +``regulator-max-microvolt`` range; force bypasses the bounds +check. + +Adding a new PMBus chip from scratch +------------------------------------ + +Use this path when the chip has no Linux driver yet, or when you want +to validate the U-Boot port against the datasheet alone. + +1. Confirm PMBus 1.x compliance level. Locate in the chip + datasheet: + + which PMBus standard command codes the chip implements + (``READ_VIN``, ``READ_VOUT``, ``STATUS_WORD``, ``MFR_ID`` ...), + which numeric format(s) it uses for VOUT (LINEAR16 with the + exponent in ``VOUT_MODE``, DIRECT with chip specific m/b/R, or + VID with one of the documented VRM tables), + which numeric format it uses for VIN, IIN, IOUT, TEMPERATURE + (most commonly LINEAR11; some MPS / MPS derivative chips use + DIRECT instead), + how many output rails it exposes (single page parts vs. + multi rail PMBus pages). + +2. Declare a ``struct pmbus_driver_info``. Wire each sensor + class to one ``enum pmbus_data_format``, plus the m/b/R triple if + the format is DIRECT:: + + static struct pmbus_driver_info chipname_info = { + .pages = 1, + .format[PSC_VOLTAGE_IN] = pmbus_fmt_direct, + .format[PSC_VOLTAGE_OUT] = pmbus_fmt_linear, + .format[PSC_CURRENT_OUT] = pmbus_fmt_direct, + .format[PSC_TEMPERATURE] = pmbus_fmt_direct, + .m[PSC_VOLTAGE_IN] = 4, .R[PSC_VOLTAGE_IN] = 1, + .m[PSC_CURRENT_OUT] = 16, .R[PSC_CURRENT_OUT] = 0, + .m[PSC_TEMPERATURE] = 1, .R[PSC_TEMPERATURE] = 0, + }; + +3. Bind to a DT compatible. Use the lowercase ``vendor,chip`` + tuple Linux uses (see "DT alignment with Linux" below). Add the + driver under ``drivers/power/regulator/`` matching the existing + skeleton (``fan53555.c``, ``pca9450.c``). + +4. Rely on the DT binding from the Linux kernel which is imported into + U-Boot under ``dts/upstream/Bindings/`` (for PMBus chips, + ``dts/upstream/Bindings/hwmon/pmbus/``). + +5. Smoke test. With the chip wired up in DT:: + + => regulator dev <name> + => regulator value + => regulator info + + Numbers should match the bench measurement to within the chip's + advertised LSB. + +Porting an existing Linux PMBus driver to U-Boot +------------------------------------------------ + +When the chip already has a ``linux/drivers/hwmon/pmbus/<chip>.c``, +that driver is the authoritative reference for format, coefficients, +and quirks. Take what carries; leave what does not. + +What carries verbatim +~~~~~~~~~~~~~~~~~~~~~ + +* Numeric formats (``format[PSC_*]``). +* DIRECT coefficients (``m[]``, ``b[]``, ``R[]``). +* Per page count and per page functionality bits (``pages``, + ``func[]``). +* VOUT_MODE driven per chip identify hook (e.g. MPQ8785's + switch between LINEAR16 and VID coerced DIRECT m=64 R=1). +* Vendor register addresses for chip specific quirks (fault + history, scale-loop, page mapping). + +What does not carry +~~~~~~~~~~~~~~~~~~~~~~~ + +* ``hwmon_device_register()`` and the attribute groups it consumes. +* ``struct pmbus_data`` / ``update_lock`` / ``last_updated`` + U-Boot has no caching layer. +* ALERT# IRQ wiring; U-Boot is single threaded boot code. +* Fan control hooks (``read_fan_*``, ``set_pwm_*``). +* Virtual register handling (``PMBUS_VIRT_READ_VIN_*`` etc.); those + are entirely a hwmon publication aid. +* ``module_i2c_driver(...)`` and ``MODULE_*`` macros; U-Boot uses + ``U_BOOT_DRIVER(...)``. + +Worked example: porting MPQ8785 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Linux's ``drivers/hwmon/pmbus/mpq8785.c`` is 193 LOC; the U-Boot +equivalent is ~150 LOC. + +The ``mpq8785_info`` struct transcribes verbatim:: + + .pages = 1, + .format[PSC_VOLTAGE_IN] = direct, .m[PSC_VOLTAGE_IN] = 4, .R[PSC_VOLTAGE_IN] = 1, + .format[PSC_CURRENT_OUT] = direct, .m[PSC_CURRENT_OUT] = 16, .R[PSC_CURRENT_OUT] = 0, + .format[PSC_TEMPERATURE] = direct, .m[PSC_TEMPERATURE] = 1, .R[PSC_TEMPERATURE] = 0, + +The VOUT format is decided at probe time from VOUT_MODE bits[7:5] : +mode 0 means LINEAR16, mode 1 or 2 means DIRECT m=64 R=1 (the chip's +"VID" mode is coerced to DIRECT by the driver). Translate Linux's +``mpq8785_identify()`` 1:1. + +The per chip quirks that carry over: + +* MPS NVM string byte order: chip stores ``S P M`` for the human + string ``MPS``. ``pmbus_read_string()`` accepts a ``reverse_bytes`` + flag for this case. +* ``mps,vout-fb-divider-ratio-permille`` DT property maps to + ``VOUT_SCALE_LOOP`` write at probe time. + +The quirks that do not carry over: + +* The ``PMBUS_VIRT_*`` virtual sensor wiring. Drop entirely. +* The ``hwmon_chip_info`` attribute group registration. +* The ``MODULE_AUTHOR`` / ``MODULE_LICENSE`` declarations. + +Using the generic ``compatible = "pmbus"`` driver +------------------------------------------------- + +When a board carries a PMBus chip without a per chip U-Boot driver, +the catch all ``drivers/power/regulator/pmbus_generic.c`` (Layer 3b) +binds against ``compatible = "pmbus"``. It auto detects format via +``VOUT_MODE`` and ``PMBUS_QUERY`` (where the chip supports it) and +provides telemetry + voltage set/get against the standard PMBus 1.x +subset. + +Decision tree: + +1. Try the generic driver first. Add the regulator node to the + board DT with ``compatible = "pmbus"`` plus the standard + regulator properties. Boot, run ``regulator value``, compare + against bench measurement. +2. Switch to a per chip driver only when the generic one is + wrong: telemetry shows wrong values (chip uses DIRECT with + non default coefficients), an alert can't be decoded (chip has + vendor specific status bits), AVS is needed (the boot path has + to actively trim VOUT before kernel handoff), or the chip has an + ADDR-pin auto promotion / VID coercion / vendor register quirk. + +DT alignment with Linux +----------------------- + +The same ``.dts`` file should work under both U-Boot (BL33) and Linux +post handoff. To make that possible: + +* Reuse the upstream Linux compatible for every PMBus chip. Look + in ``linux/Documentation/devicetree/bindings/hwmon/pmbus/`` and + ``linux/Documentation/devicetree/bindings/regulator/``. The + ``<vendor>,<chip>`` tuple from the kernel binding goes into U-Boot's + ``of_match_table`` unchanged. +* Reuse Linux property names verbatim: ``regulator-name``, + ``regulator-min-microvolt``, ``regulator-max-microvolt``, + ``regulator-boot-on``, ``regulator-always-on``, + ``mps,vout-fb-divider-ratio-permille``, etc. +* The DT binding is the kernel's, imported under + ``dts/upstream/Bindings/`` (PMBus chips live in + ``dts/upstream/Bindings/hwmon/pmbus/``). + +Multi rail/multi page chips (e.g. ISL68137 with seven outputs) +declare each rail as a child regulator node with ``reg = <page>``; +each child binds as a UCLASS_REGULATOR with that PMBus PAGE setting +applied at every read/write. + +Common pitfalls +--------------- + +These have all bitten contributors during nbxv3 bring up; record them +here so the next port doesn't repeat them. + +* VOUT_MODE/DIRECT format confusion. Most generic PMBus call + sites assume LINEAR16. Several MPS chips report VOUT in DIRECT + format with chip specific m/b/R after a single VOUT_MODE read, + the same chip read at the same address produces different + numbers depending on the format the driver applies. Always read + ``VOUT_MODE`` at probe time and switch the decoder accordingly. + Linux's per chip ``identify()`` callbacks document the exact + rules; copy them rather than guessing. +* SMBus block read protocol. Some I2C controllers strict check + block read transactions: the master must read the length byte + first, then reissue the read for the payload. Over reading a + fixed length and ignoring the length byte works on lenient + controllers but errors on strict ones. ``pmbus_read_string()`` + does the two stage read; use it. +* I2C bus number stability. ``uclass_get_device_by_seq()`` + uses the DT alias index (``i2c0`` -> ``UCLASS_I2C`` seq 0) when + aliases are declared, otherwise falls back to probe order which + varies with which controllers are enabled in the defconfig. + Always declare DT aliases for I2C buses you reference by index. +* ADDR-pin auto addressessing. Some chips (notably MPS parts) decode + their PMBus 7-bit address from an external resistor divider on + ADDR_VBOOT. The "default" address in the datasheet is the + factory fused slot; a board with a different divider or a die + with a different revision can land in another window. If the + driver hardcodes the default and the board side scan finds the + chip in another window, auto promote the working address rather + than failing the probe. +* MFR string byte order. Most PMBus chips return ``MFR_ID`` + characters in human order. Some MPS personalities reverse them. + Pass ``reverse_bytes=true`` to ``pmbus_read_string()`` for those; + spec compliant chips pass false. + +References +---------- + +* Linux PMBus core: ``linux/drivers/hwmon/pmbus/pmbus_core.c``, + decoder reference; ignore the hwmon publication and caching layers. +* Linux PMBus header: ``linux/drivers/hwmon/pmbus/pmbus.h``; API + surface reference; many constants and the ``struct + pmbus_driver_info`` shape are mirrored verbatim into U-Boot's + ``include/pmbus.h``. +* Linux DT bindings: + ``linux/Documentation/devicetree/bindings/hwmon/pmbus/``. diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 3c783ed5a0e..8ade440d84b 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -236,7 +236,7 @@ Tooling There are a number of tools available to help custodians and contributors alike with their contributions. As a project we make use of -the Patchwork project hosted at `OzLabs <http://patchwork.ozlabs.org/>`__ +the Patchwork project hosted at `OzLabs <https://patchwork.ozlabs.org/>`__ and more discussion on how it is used from both a contributor as well as custodian point of view can be found :ref:`here <patchwork>`. diff --git a/doc/develop/pytest/test_fit_verity_sign.rst b/doc/develop/pytest/test_fit_verity_sign.rst new file mode 100644 index 00000000000..94a39b08952 --- /dev/null +++ b/doc/develop/pytest/test_fit_verity_sign.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +test_fit_verity_sign +==================== + +.. automodule:: test_fit_verity_sign + :synopsis: + :member-order: bysource + :members: + :undoc-members: diff --git a/doc/develop/pytest/usage.rst b/doc/develop/pytest/usage.rst index 6002244d608..a9b8b8bd610 100644 --- a/doc/develop/pytest/usage.rst +++ b/doc/develop/pytest/usage.rst @@ -411,7 +411,7 @@ The board can be switched off now. Examples '''''''' -https://source.denx.de/u-boot/u-boot-test-hooks contains some working example hook +https://git.u-boot-project.org/u-boot/u-boot-test-hooks contains some working example hook scripts, and may be useful as a reference when implementing hook scripts for your platform. These scripts are not considered part of U-Boot itself. diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index a454d343676..d6b2d22697d 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -55,10 +55,10 @@ Current Status * U-Boot v2026.07 was released on Monday, 06 July 2026. -* The Merge Window for the next release (|next_ver|) is **open** until the -rc1 +* The Merge Window for the next release (|next_ver|) is **closed** with the -rc1 release on Monday, 27 July 2026. -* The next branch is now **closed** until the -rc2 release on Monday, 10 +* The next branch is now **open** with the -rc2 release on Monday, 10 August 2026. * Release "|next_ver|" is scheduled for Monday, 05 October 2026. @@ -69,13 +69,13 @@ Future Releases .. The following commented out dates are for when release candidates are planned to be tagged. -.. For the next scheduled release, release candidates were made on: +For the next scheduled release, release candidates were made on: -.. * U-Boot |next_ver|-rc1 was released on Mon 27 July 2026. +* U-Boot |next_ver|-rc1 was released on Mon 27 July 2026. -.. * U-Boot |next_ver|-rc2 was released on Mon 10 August 2026. +* U-Boot |next_ver|-rc2 was released on Mon 10 August 2026. -.. * U-Boot |next_ver|-rc3 was released on Mon 24 August 2026. +* U-Boot |next_ver|-rc3 was released on Mon 24 August 2026. .. * U-Boot |next_ver|-rc4 was released on Mon 07 September 2026. @@ -96,7 +96,7 @@ Previous Releases ----------------- Note: these statistics are generated by our fork of `gitdm -<https://source.denx.de/u-boot/gitdm>`_, which was originally created by +<https://git.u-boot-project.org/u-boot/gitdm>`_, which was originally created by Jonathan Corbet. * :doc:`statistics/u-boot-stats-v2026.07` which was released on 06 July 2026. diff --git a/doc/develop/security.rst b/doc/develop/security.rst index 84b130646f3..ed652ec756e 100644 --- a/doc/develop/security.rst +++ b/doc/develop/security.rst @@ -11,7 +11,7 @@ Contact ------- The preferred initial point of contact is to send email to -`[email protected]` and use `scripts/get_maintainers.pl` to also include any +`[email protected]` and use `scripts/get_maintainers.pl` to also include any relevant custodians. In addition, Tom Rini should be contacted at diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst index c3e0ef27824..b4f82eb18e1 100644 --- a/doc/develop/sending_patches.rst +++ b/doc/develop/sending_patches.rst @@ -5,7 +5,7 @@ Sending patches *Before you begin* to implement any new ideas or concepts it is always a good idea to present your plans on the `U-Boot mailing list -<https://lists.denx.de/listinfo/u-boot>`_. U-Boot supports a huge amount of +<https://lists.u-boot-project.org/mailman/listinfo/u-boot>`_. U-Boot supports a huge amount of very different systems, and it is often impossible for the individual developer to oversee the consequences of a specific change to all architectures. Discussing concepts early can help you to avoid spending effort on code which, @@ -15,7 +15,7 @@ resource - use it. Being familiar with the :doc:`process` is also important. A good introduction how to prepare for submitting patches can be found in the LWN article `How to Get Your Change Into the Linux Kernel -<http://lwn.net/Articles/139918/>`_ as the same rules apply to U-Boot, too. +<https://lwn.net/Articles/139918/>`_ as the same rules apply to U-Boot, too. .. _b4_contrib: @@ -25,7 +25,7 @@ Using b4 Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and send your patches. b4 has become the preferred tool to sending patches for many Linux kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that -targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` +targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` for recipient discovery. Start a topical series with ``b4 prep`` and keep the commits organised with @@ -51,7 +51,7 @@ additional runs. When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review the generated emails and ``--reflect`` to copy yourself for records before -dispatching to ``[email protected]``. +dispatching to ``[email protected]``. .. code-block:: bash @@ -86,8 +86,8 @@ patman now lives outside the U-Boot tree; install it with General Patch Submission Rules ------------------------------ -* All patches must be sent to the `[email protected] - <https://lists.denx.de/listinfo/u-boot>`_ mailing list. +* All patches must be sent to the `[email protected] + <https://lists.u-boot-project.org/mailman/listinfo/u-boot>`_ mailing list. * If your patch affects the code maintained by one of the :ref:`custodians`, CC them when emailing your patch. The easiest way to make sure you don't forget @@ -134,7 +134,7 @@ General Patch Submission Rules patches is by using the ``git format-patch`` command. For a patch that is fixing a bug or regression of some sort, please use the ``master`` branch of the mainline U-Boot git repository located at - https://source.denx.de/u-boot/u-boot.git as reference. For new features, if + https://git.u-boot-project.org/u-boot/u-boot.git as reference. For new features, if the ``next`` branch has been opened (which happens with the release of ``-rc2``) that branch should be used, otherwise ``master`` is acceptable. @@ -142,10 +142,6 @@ General Patch Submission Rules like wrapping of longer lines etc. The best way to send patches is by not using your regular mail tool, but by using either ``git send-email`` or the ``git imap-send`` command instead. - If you believe you need to use a mailing list for testing (instead of any - regular mail address you own), we have a special test list for such purposes. - It would be best to subscribe to the list for the duration of your tests to - avoid repeated moderation - see https://lists.denx.de/listinfo/test * Choose a meaningful Subject: - keep in mind that the Subject will also be visible as headline of your commit message. Make sure the subject does not @@ -317,7 +313,7 @@ to observe the following rules. Note: it is *not* sufficient to provide a change log in some cover letter that gets sent as a separate message with the patch series. The reason is that such cover letters are not as easily reviewed in our `patchwork queue - <http://patchwork.ozlabs.org/project/uboot/list/>`_ so they are not helpful + <https://patchwork.ozlabs.org/project/uboot/list/>`_ so they are not helpful to any reviewers using this tool. Example:: From: Joe Hacker <[email protected]> @@ -353,15 +349,15 @@ posted before, look up the old threads, and then manually compare if anything has been changed, or what. If you have problems with your e-mail client, for example because it mangles -white space or wraps long lines, then please read this article about `Email -Clients and Patches <http://kerneltrap.org/Linux/Email_Clients_and_Patches>`_. +white space or wraps long lines, then please read this about `Email +Clients and Patches <https://docs.kernel.org/process/email-clients.html>`_. Notes ----- 1. U-Boot is Free Software that can redistributed and/or modified under the terms of the `GNU General Public License - <http://www.fsf.org/licensing/licenses/gpl.html>`_ (GPL). Currently (August + <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>`_ (GPL). Currently (August 2022) version 2 of the GPL applies. Please see :download:`Licensing <../../Licenses/README>` for details. To allow that later versions of U-Boot may be released under a later version of the GPL, all new code that gets @@ -384,12 +380,12 @@ Notes Patch Tracking -------------- -Like some other projects, U-Boot uses `Patchwork <http://patchwork.ozlabs.org/>`__ +Like some other projects, U-Boot uses `Patchwork <https://patchwork.ozlabs.org/>`__ to track the state of patches. This is one of the reasons why it is mandatory to submit all patches to the U-Boot mailing list - only then they will be picked up by patchwork. -At http://patchwork.ozlabs.org/project/uboot/list/ you can find the list of +At https://patchwork.ozlabs.org/project/uboot/list/ you can find the list of open U-Boot patches. By using the "Filters" link (Note: requires JavaScript) you can also select other views, for example, to include old patches that have, for example, already been applied or rejected. @@ -474,14 +470,13 @@ Apply patches ^^^^^^^^^^^^^ To apply a patch from the `patchwork queue -<http://patchwork.ozlabs.org/project/uboot/list/>`_ using ``git``, download the +<https://patchwork.ozlabs.org/project/uboot/list/>`_ using ``git``, download the mbox file and apply it using:: git am file -The `openembedded wiki <http://wiki.openembedded.net/>`_ also provides a script -named `pw-am.sh -<http://cgit.openembedded.org/cgit.cgi/openembedded/tree/contrib/patchwork/pw-am.sh>`_ +OpenEmbedded also provides a script named `pw-am.sh +<https://git.openembedded.org/openembedded/tree/contrib/patchwork/pw-am.sh>`_ which can be used to fetch an 'mbox' patch from patchwork and git am it:: usage: pw-am.sh <number> @@ -500,7 +495,7 @@ The `pwclient` command line tool can be used for example to retrieve patches, search the queue or update the state. All necessary information for `pwclient` is linked from the bottom of -http://patchwork.ozlabs.org/project/uboot/ +https://patchwork.ozlabs.org/project/uboot/ Use:: @@ -511,4 +506,4 @@ for an overview on how to use it. pwparser ^^^^^^^^ -See http://www.mail-archive.com/[email protected]/msg00057.html +See https://lists.ozlabs.org/pipermail/patchwork/2010-January/000186.html diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst index 1a020caa411..1a6d13f6c7c 100644 --- a/doc/develop/tests_writing.rst +++ b/doc/develop/tests_writing.rst @@ -236,7 +236,7 @@ Include ``test/ut.h`` defines a number of macros to check values and to return from the test function if the assertion fails. See :doc:`../api/test` for details. -[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fe064646d2 +[1] https://git.u-boot-project.org/u-boot/u-boot/-/commit/9fe064646d Add a new driver model test @@ -282,7 +282,7 @@ implementations work as expected. Example commit: c48cb7ebfb4 ("sandbox: add ADC unit tests") [1] -[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/c48cb7ebfb4 +[1] https://git.u-boot-project.org/u-boot/u-boot/-/commit/c48cb7ebfb4 Add a new test suite diff --git a/doc/develop/uefi/iscsi.rst b/doc/develop/uefi/iscsi.rst index 51d38cde243..104ef87705f 100644 --- a/doc/develop/uefi/iscsi.rst +++ b/doc/develop/uefi/iscsi.rst @@ -125,17 +125,17 @@ iPXE For running iPXE on arm64 the bin-arm64-efi/snp.efi build target is needed:: - git clone http://git.ipxe.org/ipxe.git + git clone https://github.com/ipxe/ipxe cd ipxe/src make bin-arm64-efi/snp.efi -j6 EMBED=myscript.ipxe The available commands for the boot script are documented at: -http://ipxe.org/cmd +https://ipxe.org/cmd Credentials are managed as environment variables. These are described here: -http://ipxe.org/cfg +https://ipxe.org/cfg iPXE by default will put the CPU to rest when waiting for input. U-Boot does not wake it up due to missing interrupt support. To avoid this behavior create diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst index 177e887ebd9..883bd2b1451 100644 --- a/doc/develop/uefi/u-boot_on_efi.rst +++ b/doc/develop/uefi/u-boot_on_efi.rst @@ -300,9 +300,9 @@ Content of **boot.scr**: .. code-block:: bash ext4load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${prefix}Image - setenv kernel_size ${filesize} + env set kernel_size ${filesize} ext4load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} ${prefix}Initrd - setenv initrd_size ${filesize} + env set initrd_size ${filesize} zboot ${kernel_addr_r} ${kernel_size} ${ramdisk_addr_r} ${initrd_size} Extlinux configuration diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index 3ca22b572a9..94ddf690440 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -170,11 +170,11 @@ Sign an image with one of the keys in "db" on your host Now in U-Boot install the keys on your board:: fatload mmc 0:1 <tmpaddr> PK.auth - setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK + env set -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK fatload mmc 0:1 <tmpaddr> KEK.auth - setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK + env set -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK fatload mmc 0:1 <tmpaddr> db.auth - setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize db + env set -e -nv -bs -rt -at -i <tmpaddr>:$filesize db Set up boot parameters on your board:: @@ -412,7 +412,7 @@ bit in OsIndications variable with .. code-block:: console - => setenv -e -nv -bs -rt -v OsIndications =0x0000000000000004 + => env set -e -nv -bs -rt -v OsIndications =0x0000000000000004 Since U-Boot doesn't currently support SetVariable at runtime, its value won't be taken over across the reboot. If this is the case, you can skip @@ -698,12 +698,12 @@ end up with "host not found". We need to preset the "httpserverip" environment variable to proceed the wget:: - setenv httpserverip 192.168.1.1 + env set httpserverip 192.168.1.1 UEFI HTTP(s) Boot using lwIP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Similar to the above U-Boot can do EFI HTTP boot using lwIP. If we combine this -with Mbed TLS we can also download from https:// +with Mbed TLS we can also download from HTTPS. HTTP(s) Boot can be activated by specifying:: @@ -789,7 +789,7 @@ If the environment variable is set to 'list' a list of all tests is shown. Below you can find the output of an example session:: - => setenv efi_selftest simple network protocol + => env set efi_selftest simple network protocol => bootefi selftest Testing EFI API implementation Selected test: 'simple network protocol' |