diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/boards/imx/nxp-imx8mm-evk.rst | 18 | ||||
| -rw-r--r-- | Documentation/boards/imx/nxp-imx8mn-evk.rst | 24 | ||||
| -rw-r--r-- | Documentation/boards/imx/nxp-imx8mp-evk.rst | 24 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/barebox/aliases.rst | 19 | ||||
| -rw-r--r-- | Documentation/devicetree/index.rst | 45 | ||||
| -rw-r--r-- | Documentation/user/automount.rst | 2 |
6 files changed, 118 insertions, 14 deletions
diff --git a/Documentation/boards/imx/nxp-imx8mm-evk.rst b/Documentation/boards/imx/nxp-imx8mm-evk.rst index c3cd35ae38..f0dfc53ed0 100644 --- a/Documentation/boards/imx/nxp-imx8mm-evk.rst +++ b/Documentation/boards/imx/nxp-imx8mm-evk.rst @@ -69,3 +69,21 @@ board for serial download mode as printed on the PCB. You can start barebox with the imx-usb-loader tool that comes with barebox like this: ./scripts/imx/imx-usb-loader images/barebox-nxp-imx8mm-evk.img + +Installing barebox +================== + +When the EVK is strapped to boot from eMMC, the i.MX8M bootrom will +consult the eMMC ext_csd register to determine whether to boot +from the active eMMC boot partition or from the user area. + +The same barebox image written to the start of the SD-Card can +be written to the start of the eMMC user area. Power-fail-safe +installation to the eMMC boot partition requires special handling: + + - The barebox image must be written to the inactive boot partition, + then afterwards, the newly written boot partition is activated + (This is controlled by the barebox ``mmcX.boot`` variable). + +The ``barebox_update`` command takes care of this and need just be +supplied a barebox image as argument. diff --git a/Documentation/boards/imx/nxp-imx8mn-evk.rst b/Documentation/boards/imx/nxp-imx8mn-evk.rst index b920e22d33..177fc59c10 100644 --- a/Documentation/boards/imx/nxp-imx8mn-evk.rst +++ b/Documentation/boards/imx/nxp-imx8mn-evk.rst @@ -58,3 +58,27 @@ Build barebox make imx_v8_defconfig make + +Installing barebox +================== + +When the EVK is strapped to boot from eMMC, the i.MX8M bootrom will +consult the eMMC ext_csd register to determine whether to boot +from the active eMMC boot partition or from the user area. + +The same barebox image written to the start of the SD-Card can +be written to the start of the eMMC user area. Power-fail-safe +installation to the eMMC boot partition requires special handling: + + - The barebox image must be written to the inactive boot partition, + then afterwards, the newly written boot partition is activated + (This is controlled by the barebox ``mmcX.boot`` variable). + + - The barebox image includes a 32KiB preamble that allows the image + to be directly writable to the start of the SD-Card or eMMC user area. + Unlike older i.MX8M, the i.MX8MN BootROM expects the bootloader to not + start at an offset when booting from eMMC boot partitions, thus the first + 32KiB must be stripped. + +The ``barebox_update`` command takes care of this and need just be +supplied a barebox image as argument. diff --git a/Documentation/boards/imx/nxp-imx8mp-evk.rst b/Documentation/boards/imx/nxp-imx8mp-evk.rst index 1074992f2f..53cdd904ab 100644 --- a/Documentation/boards/imx/nxp-imx8mp-evk.rst +++ b/Documentation/boards/imx/nxp-imx8mp-evk.rst @@ -66,3 +66,27 @@ Boot Configuration The NXP i.MX8MP-EVK board has four switches responsible for configuring bootsource/boot mode. The settings for the different boot sources are printed on the board. + +Installing barebox +================== + +When the EVK is strapped to boot from eMMC, the i.MX8M bootrom will +consult the eMMC ext_csd register to determine whether to boot +from the active eMMC boot partition or from the user area. + +The same barebox image written to the start of the SD-Card can +be written to the start of the eMMC user area. Power-fail-safe +installation to the eMMC boot partition requires special handling: + + - The barebox image must be written to the inactive boot partition, + then afterwards, the newly written boot partition is activated + (This is controlled by the barebox ``mmcX.boot`` variable). + + - The barebox image includes a 32KiB preamble that allows the image + to be directly writable to the start of the SD-Card or eMMC user area. + Unlike older i.MX8M, the i.MX8MP BootROM expects the bootloader to not + start at an offset when booting from eMMC boot partitions, thus the first + 32KiB must be stripped. + +The ``barebox_update`` command takes care of this and need just be +supplied a barebox image as argument. diff --git a/Documentation/devicetree/bindings/barebox/aliases.rst b/Documentation/devicetree/bindings/barebox/aliases.rst index e6face2c33..2848a88f15 100644 --- a/Documentation/devicetree/bindings/barebox/aliases.rst +++ b/Documentation/devicetree/bindings/barebox/aliases.rst @@ -19,17 +19,22 @@ probing the node at ``&iwdg`` will be named ``wdog0``. By default, barebox will assume the aliases in the DT to align with the bootsource communicated by the firmware. If this is not the case, -a device tree override is possible via an -``/aliases/barebox,bootsource-${bootsource}${bootsource_instance}`` +a device tree override is possible via a +``/chosen/barebox,bootsource-${bootsource}${bootsource_instance}`` property: .. code-block:: none - &{/aliases} { - mmc0 = &sdmmc0; - mmc1 = &sdhci; - barebox,bootsource-mmc0 = &sdhci; - barebox,bootsource-mmc1 = &sdmmc0; + / { + aliases { + mmc0 = &sdmmc0; + mmc1 = &sdhci; + }; + + chosen { + barebox,bootsource-mmc0 = &sdhci; + barebox,bootsource-mmc1 = &sdmmc0; + }; }; This will ensure that when booting from MMC, ``/dev/mmc${bootsource_instance}`` diff --git a/Documentation/devicetree/index.rst b/Documentation/devicetree/index.rst index 61ac0433fb..36fa69058d 100644 --- a/Documentation/devicetree/index.rst +++ b/Documentation/devicetree/index.rst @@ -37,8 +37,8 @@ environment or boot-time device configuration. Device Tree probing largely happens via compatible properties with no special meaning to the node names themselves. It's thus paramount that any device tree -nodes extended in the barebox device tree are referenced by a phandle, not by -path, to avoid run-time breakage like this:: +nodes extended in the barebox device tree are referenced by label (e.g. +``<&phandle>``, not by path, to avoid run-time breakage like this:: # Upstream dts/src/$ARCH/board.dts / { @@ -62,15 +62,48 @@ path, to avoid run-time breakage like this:: In the previous example, a device tree sync with upstream resulted in a regression as the former override became a new node with a single property without effect. -Using phandles avoids this. When no phandle mapping the full path is defined -upstream, the ``&{/path}`` syntax should be used instead, e.g.:: +The preferred way around this is to use labels directly:: + + # Upstream dts/src/$ARCH/board.dts + / { + leds { + status_led: red { }; + }; + }; + + # barebox arch/$ARCH/dts/board.dts + #include <$ARCH/board.dts> + + &status_led { + barebox,default-trigger = "heartbeat"; + }; + +If there's no label defined upstream for the node, but for a parent, +a new label can be constructed from that label and a relative path:: + + # Upstream dts/src/$ARCH/board.dts + / { + led_controller: leds { + red { }; + }; + }; + + # barebox arch/$ARCH/dts/board.dts + #include <$ARCH/board.dts> + + &{led_controller/red} { + barebox,default-trigger = "heartbeat"; + }; + +As last resort, the full path shall be used:: &{/leds/red} { barebox,default-trigger = "heartbeat"; }; -This would lead to a compile error should the ``/leds/red`` path be renamed or -removed. This also applies to uses of ``/delete-node/``. +Any of these three approaches would lead to a compile error should the +``/leds/red`` path be renamed or removed. This also applies to uses +of ``/delete-node/``. Only exception to this rule are well-known node names that are specified by the `specification`_ to be parsed by name. These are: ``chosen``, ``aliases`` diff --git a/Documentation/user/automount.rst b/Documentation/user/automount.rst index 1fdeffc663..b41b41ef02 100644 --- a/Documentation/user/automount.rst +++ b/Documentation/user/automount.rst @@ -15,7 +15,7 @@ TFTP server, the following is required: .. code-block:: sh mkdir -p /mnt/tftp - automount /mnt/tftp 'ifup -a && mount -t tftp $global.net.server /mnt/tftp' + automount /mnt/tftp 'ifup -a1 && mount -t tftp $global.net.server /mnt/tftp' This creates an automountpoint on ``/mnt/tftp``. Whenever this directory is accessed, the command ``ifup eth0 && mount -t tftp $eth0.serverip /mnt/tftp`` is executed. |