Sumit Garg authored 1 year ago and Tom Rini committed 1 year ago

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: Sumit Garg <sumit.garg@linaro.org>

Sumit Garg authored 1 year ago and Tom Rini committed 1 year ago

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: Sumit Garg <sumit.garg@linaro.org>

Sumit Garg authored 1 year ago and Tom Rini committed 1 year ago

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: Sumit Garg <sumit.garg@linaro.org>

Sumit Garg authored 1 year ago and Tom Rini committed 1 year ago

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: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

Sumit Garg authored 1 year ago and Tom Rini committed 1 year ago

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: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

Sumit Garg authored 1 year ago and Tom Rini committed 1 year ago

Since devicetree-rebasing is an external repo with its own coding style,
exclude it from Azure and gitlab CI CONFIG checks.

Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

git-subtree-dir: dts/upstream
git-subtree-split: aaba2d45dc2a1b3bbb710f2a3808ee1c9f340abe

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().

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

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>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

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: Raymond Mao <raymond.mao@linaro.org>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

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: Raymond Mao <raymond.mao@linaro.org>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

Save boot arguments x[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

Save boot arguments r[0-3] into an array for handover of bloblist from
previous boot stage.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

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: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

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: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Raymond Mao authored 1 year ago and Tom Rini committed 1 year ago

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: Raymond Mao <raymond.mao@linaro.org>

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.

Roger Quadros authored 1 year ago and Tom Rini committed 1 year ago

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>

Roger Quadros authored 1 year ago and Tom Rini committed 1 year ago

MUX driver should autoprobe if the device tree has "idle-states"
property. Drop using the custom "u-boot,mux-autoprobe" property.

Signed-off-by: Roger Quadros <rogerq@kernel.org>

Roger Quadros authored 1 year ago and Tom Rini committed 1 year ago

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: Roger Quadros <rogerq@kernel.org>

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

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: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Change the alignment of the relocation code in EFI binaries to match page
boundaries.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

On RISC-V systems system the Supervisory Binary Interface provides system
reset and poweroff. Use it at EFI runtime.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

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: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

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.

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 <trini@konsulko.com>

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 <trini@konsulko.com>

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 <trini@konsulko.com>

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 <trini@konsulko.com>

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 <trini@konsulko.com>

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: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the efi-x86_payload* platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the efi-x86_app* platforms and remove
the otherwise empty file.

Signed-off-by: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the edison platform and remove
the otherwise empty file.

Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the crownbay platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the cougarcanyon2 platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the cherryhill platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini <trini@konsulko.com>

Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a
lack of board.h file, unset this on the bayleybay platform and remove
the otherwise empty file.

Signed-off-by: Tom Rini <trini@konsulko.com>