- Mar 01, 2024
-
-
Caleb Connolly authored
When booting U-Boot on board with a locked down first-stage bootloader, we emulate the Linux boot header. By passing the U-Boot FDT through this first-stage bootloader and retrieving it afterwards we can pre-populate the memory nodes and other info like the KASLR address. Add a function to export the FDT addr so that boards can use it over the built-in FDT. Don't check is_addr_accessible() here because we might not yet have a valid mem_map if it's going to be populated from the FDT, let the board do their own validation instead. Reviewed-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Sumit Garg <sumit.garg@linaro.org> Tested-by: Sumit Garg <sumit.garg@linaro.org> #qcs404 Signed-off-by:
Caleb Connolly <caleb.connolly@linaro.org>
-
Tom Rini authored
Sumit Garg <sumit.garg@linaro.org> says: Prerequisite ------------ This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-Boot repo via: $ git subtree add --prefix dts/upstream \ https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.7-dts --squash Background ---------- This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-Boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained. However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel. In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release. `dts/update-dts-subtree.sh` script provides a wrapper around git subtree pull command, usage from the top level U-Boot source tree, run: $ ./dts/update-dts-subtree.sh pull <devicetree-rebasing-release-tag> If required it is also possible to cherry-pick fixes from devicetree-rebasing tree prior to next sync, usage: $ ./dts/update-dts-subtree.sh pick <devicetree-rebasing-commit-id> The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback. [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ [4] https://github.com/u-boot/u-boot/pull/451 Changes ------- Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts` which can be selected via setting "<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. SoC/board maintainers are encouraged to migrate to use synced copies from `dts/upstream/src/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` for the SoC being used via Kconfig and set up "<vendor>/<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #10 and #11. Devicetree bindings schema checks --------------------------------- With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `dts/upstream/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree. Dependencies ------------ The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip: $ pip3 install dtschema Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems: $ apt install swig python3-dev Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). Recommended is also to install yamllint (used by dtschema when present). $ apt install yamllint Running checks -------------- In order to perform validation of DTB files, use the ``dtbs_check`` target: $ make dtbs_check It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'. $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml -
Since meson-gxbb based boards switched to using upstream DT, so drop redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files kept in arch/arm/dts directory for these boards. Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Although there were still some variations in board DTS files based on meson-gxbb SoC but I think those were minor differences from upstream and shouldn't impact boot on these devices. So enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory. Reviewed-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
-
Add myself as devicetree-rebasing maintainer. Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
Encourage SoC/board maintainers to migrate to using devicetree-rebasing subtree and maintain a regular sync with Linux kernel devicetree files and bindings. Along with that add documentation regarding how to run DT bindings schema checks. Signed-off-by: -
Since U-Boot switched away from manual CONFIG_* defines to Kconfig options, align devicetree documentation accordingly. Signed-off-by: -
dts/update-dts-subtree.sh is just a wrapper around git subtree commands. Usage from the top level U-Boot source tree, run: $ ./dts/update-dts-subtree.sh pull <release-tag> $ ./dts/update-dts-subtree.sh pick <commit-id> Signed-off-by: -
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/upstream/src/$(ARCH) (special case for arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64. This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files. Signed-off-by: -
Allow platforms to reuse DT headers and dtsi includes directly form upstream DT subtree which will be frequently synced with Linux kernel. This will further allow us to drop corresponding DT includes copy from U-Boot tree. Also, since the DT includes from upstream DT subtree are done after DT includes from U-Boot tree, so it shouldn't cause any conflicts. Tested-by:
Bryan Brattlof <bb@ti.com>
Signed-off-by: -
Allow u-boot to build DTB from a different directory tree such that *-u-boot.dtsi files can be included from a common location. Currently that location is arch/$(ARCH)/dts/, so statically define that common location. This is needed for platform owners to start building DTB files from devicetree-rebasing directory but still being able to include *-u-boot.dtsi files. Reviewed-by:
-
This adds the build infrastructure for checking DT binding schema documents and validating dtb files using the binding schema. Here we use devicetree-rebasing subtree to provide the DT bindings. Along with that adapt dts/upstream/Bindings/Makefile to align with old U-Boot Kbuild infrastructure. Dependency: ----------- The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:: pip3 install dtschema Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems:: apt install swig python3-dev Testing: -------- Build dts files and check using DT binding schema: $ make dtbs_check Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema. Note, at this point dtbs_check is an optional build target as there are many warnings generated due to custom DT properties used by many platforms in u-boot. It is expected with these checks that compliance with DT bindings to take place. Once that's done it can be added to CI builds to remain compliant with DT bindings. Reviewed-by: -
Since devicetree-rebasing is an external repo with its own coding style, exclude it from Azure and gitlab CI CONFIG checks. Reviewed-by:
-
- Feb 29, 2024
-
-
Tom Rini authored
-
Tom Rini authored
git-subtree-dir: dts/upstream git-subtree-split: aaba2d45dc2a1b3bbb710f2a3808ee1c9f340abe
-
Tom Rini authored
Raymond Mao <raymond.mao@linaro.org> says: This patch set adds/adapts a few bloblist APIs and implements Arm arch custom function to retrieve the bloblist (aka. Transfer List) from previous loader via boot arguments when BLOBLIST option is enabled and all boot arguments are compliant to the register conventions defined in the Firmware Handoff spec v0.9. If an arch wishes to have different behaviors for loading bloblist from the previous boot stage, it is required to implement the custom function xferlist_from_boot_arg().
-
When BLOBLIST is enabled, FDT is expected to be from bloblist carried from previous stage, instead of from OF_BOARD, therefore only enable OF_HAS_PRIOR_STAGE when BLOBLIST is disabled. Signed-off-by:Raymond Mao <raymond.mao@linaro.org>
-
During bloblist initialization, load the bloblist via boot arguments from the previous loader. If a valid bloblist exists in boot arguments, relocate it into the fixed bloblist memory region. If not, fallback to support BLOBLIST_ADDR or BLOBLIST_ALLOC. Signed-off-by: -
Add arch custom function to get bloblist from boot arguments. Check whether boot arguments aligns with the register conventions defined in FW Handoff spec v0.9. Signed-off-by: -
Save boot arguments x[0-3] into an array for handover of bloblist from previous boot stage. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
-
Save boot arguments r[0-3] into an array for handover of bloblist from previous boot stage. Signed-off-by:
-
The current bloblist pointer and size can be retrieved from global data, so we don't need to pass them from the function arguments. This change also help to remove all external access of gd->bloblist outside of bloblist module. Signed-off-by:
-
Instead of expecting the bloblist total size to be the same as the pre-allocated buffer size, practically we are more interested in whether the pre-allocated buffer size is bigger than the bloblist total size. Signed-off-by:
-
Add bloblist_check_reg_conv() to check whether the bloblist is compliant to the register conventions defined in Firmware Handoff specification. This API can be used for all Arm platforms. Signed-off-by: -
Tom Rini authored
Roger Quadros <rogerq@kernel.org> says: MUX driver should autoprobe if the device tree has "idle-states" property. Drop using the custom "u-boot,mux-autoprobe" property in TI device trees.
-
As it is present for USB and USB won't work without the MUX initialized correctly, add "bootph-all" property to MUX nodes. Signed-off-by:Roger Quadros <rogerq@kernel.org>
-
MUX driver should autoprobe if the device tree has "idle-states" property. Drop using the custom "u-boot,mux-autoprobe" property. Signed-off-by: -
Some platforms need the MUX state to be auto initialized at boot time even if there are no explicit users for the MUX. In these cases, the MUX device tree has "idle-states" property which specifies what state the MUX should be initialized to. So far we were relying on custom u-boot property "u-boot,mux-autoprobe" to autoprobe such MUXes. This patch causes the MUX to autoprobe if it has "idle-states" property in device tree. This should allow us to stop using the custom "u-boot,mux-autoprobe" property. Signed-off-by:
-
- Feb 28, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-efiTom Rini authored
Pull request efi-next-2024-02-28 * set IMAGE_DLLCHARACTERISTICS_NX_COMPAT in EFI binaries * provide SBI based runtime system reset * page align EFI binary section on ARMv7 * separate .data and .text sections of EFI binaries on ARMv7
-
Heinrich Schuchardt authored
EFI binaries should not contain sections that are both writable and executable. Separate the RX .text section from the RW .data section. We currently don't created relocation sections (.rel.*) for our EFI binaries. Anyway these would have to be converted to PE/COFF relocations. Enumerate them under DISCARD and add a comment. Correct the characteristics of the sections. Signed-off-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by:
-
Heinrich Schuchardt authored
Change the alignment of the relocation code in EFI binaries to match page boundaries. Signed-off-by:
-
Heinrich Schuchardt authored
On RISC-V systems system the Supervisory Binary Interface provides system reset and poweroff. Use it at EFI runtime. Signed-off-by: -
Heinrich Schuchardt authored
The IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag marks an EFI binary where the following conditions are met [1]: * Executable and writable sections are separated. * The application does not run self-modifying code. * The application uses the EFI_MEMORY_ATTRIBUTE_PROTOCOL when loading executable code. * The application does not assume that all memory ranges are usable. * The stack is not expected to be executable. The only EFI binaries U-Boot provides that do not fulfill these requirements are the EFI app and the EFI payload. Once we have implemented separation of writable and executable memory in U-Boot we can use the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag to decide if we will load an EFI binary. [1] New UEFI CA memory mitigation requirements for signing https://techcommunity.microsoft.com/t5/hardware-dev-center/new-uefi-ca-memory-mitigation-requirements-for-signing/ba-p/3608714 Signed-off-by:
-
- Feb 27, 2024
-
-
Tom Rini authored
Perform a little re-organization of Kconfig so that we can have CONFIG_SYS_CONFIG_NAME be unset and so not require a "board.h" file. Then go and remove a number of now not required header files.
-
Tom Rini authored
Generally speaking, we do not prompt for this value and define it in the board specific Kconfig file. There are some valid use cases however today where we do prompt for this value, so instead of having this be done in a number of locations, do this at the top-level location only. This removes the question from a number of other locations and makes it consistent that when we do set the value directly, we always do it the same way. We don't need to specify the type, it's always string. Signed-off-by: -
Tom Rini authored
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a lack of board.h file, unset this on the hc2910-2aghd05 platform and remove the otherwise empty file. Signed-off-by: -
Tom Rini authored
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a lack of board.h file, unset this on the slimbootloader platform and remove the otherwise empty file. Signed-off-by: -
Tom Rini authored
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a lack of board.h file, unset this on the qemu-x86* platforms and remove the otherwise empty file. Signed-off-by: -
Tom Rini authored
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a lack of board.h file, unset this on the minnowmax platform and remove the otherwise empty file. Signed-off-by: -
Tom Rini authored
Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a lack of board.h file, unset this on the galileo platform and remove the otherwise empty file. Signed-off-by:
-
