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>
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>
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
If SYSRESET support is enabled for the RAA215300 PMIC, we need to bind
the raa215300_sysreset driver as a child device of the PMIC.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This patch adds support for resetting a board via the RAA215300 PMIC.
Note that the RAA215300 documentation names the available reset types
differently to u-boot:
* A "warm" reset via the RAA215300 PMIC will fully reset the SoC
(CPU & GPIOs), so this corresponds to SYSRESET_COLD.
* A "cold" reset via the RAA215300 PMIC will cycle all power supply
rails, so this corresponds to SYSRESET_POWER.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The RZ/G2L SMARC module is powered via a Renesas RAA215300 PMIC which
provides several voltage converters, a real time clock (RTC) and reset
control. A basic driver is implemented for this device so that we can
read, write and dump the PMIC registers.
The raa215300_bind() function is added as a stub, binding of the
sysreset driver will be added in a later patch.
Additional features of this PMIC (such as reset control) may be
supported by future patches.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This driver supports the I2C module on the Renesas RZ/G2L (R9A07G044)
SoC, also known as the RIIC module.
This patch is based on both the u-boot driver in the Renesas RZ BSP
3.0.5 release [1] (commit 7fcc1fdc2534), and the Linux v6.7 driver
(commit 0dd3ee311255).
Support for deblocking the I2C bus is included as this may be needed
after triggering a reset via the Power Management IC (PMIC) over I2C
(the PMIC asserts the reset line before the SoC completes the I2C write
transaction with obvious bus locking effects). If the SDA line is
observed to be low during initialisation, we automatically attempt to
deblock.
[1]: https://github.com/renesas-rz/renesas-u-boot-cip
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Pull in the recent changes to the RZ/G2L device tree and related dtsi
files so that we're aligned with Linux v6.7 (commit 0dd3ee311255).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
When enabling/disabling a clock or reset signal, confirm that the change
has completed before returning from the function. A somewhat arbitrary
100ms timeout is defined to ensure that the system doesn't lock up in
the case of an error.
Since we need to dynamically determine if we're waiting for a 0 bit or a
1 bit, it's easier to use wait_for_bit_32() than readl_poll_timeout().
This change is needed for reliable initialization of the I2C driver
which is added in a following patch.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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>
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>
Instead of downloading coreboot binaries from a Google drive location,
use the ones we have built ourselves.
Signed-off-by: Tom Rini <trini@konsulko.com>
To make CI runs rely less on external servers, build a coreboot release
from source and populate /opt/coreboot with the output.
Signed-off-by: Tom Rini <trini@konsulko.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>
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>
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>
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>
- 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 68dcbdd594 ("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 68dcbdd594 ("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>
