- Feb 29, 2024
-
-
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:
Raymond Mao <raymond.mao@linaro.org>
-
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>
-
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>
-
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>
-
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>
-
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>
-
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>
-
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:
Roger Quadros <rogerq@kernel.org>
-
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>
-
- 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:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
Heinrich Schuchardt authored
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>
-
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 <heinrich.schuchardt@canonical.com>
-
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:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
-
- 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 <trini@konsulko.com>
-
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 <trini@konsulko.com>
-
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 <trini@konsulko.com>
-
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 <trini@konsulko.com>
-
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 <trini@konsulko.com>
-
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:
Tom Rini <trini@konsulko.com>
-
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 efi-x86_payload* platforms and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 efi-x86_app* platforms and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 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>
-
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 crownbay platform and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 cougarcanyon2 platform and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 cherryhill platform and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 bayleybay platform and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 coreboot platform and remove the otherwise empty file. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
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 xilinx_mbv platforms and remove the otherwise empty file. Acked-by:
Michal Simek <michal.simek@amd.com> Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
It is possible to have a platform which does not require a board.h file to build, but today we need an empty one for our generated config.h file to be valid. Allow for omitting this file if CONFIG_SYS_CONFIG_NAME is not set. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
Signed-off-by:
Tom Rini <trini@konsulko.com>
-
- Feb 24, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-imxTom Rini authored
- Enable the thermal driver for the imx8m phycore boards. - Convert imx53-qsb to watchdog driver to fix the 'reset' command. - Remove multiline string from imx6dl-sielaff. - Add SPI boot support for imxrt1050-evk. - Convert opos6uldev to watchdog driver to fix the 'reset' command.
-
Commit 68dcbdd5 ("ARM: imx: Add weak default reset_cpu()") caused the 'reset' command in U-Boot to not cause a board reset. Fix it by switching to the watchdog driver model via sysreset, which is the preferred method for implementing the watchdog reset. Signed-off-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com>
-
Commit 68dcbdd5 ("ARM: imx: Add weak default reset_cpu()") caused the 'reset' command in U-Boot to not cause a board reset. Fix it by switching to the watchdog driver model via sysreset, which is the preferred method for implementing the watchdog reset. Signed-off-by:
Fabio Estevam <festevam@gmail.com>
-
Enable the imx thermal driver to prevent booting when the system is too hot. Signed-off-by:
Benjamin Hahn <B.Hahn@phytec.de>
-