When we store EFI variables on file we don't allow SetVariable at runtime,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariable at runtime we copy runtime variables in RAM and expose them
to the OS. Add a Kconfig option and provide SetVariable at runtime using
the same memory backend. The OS will be responsible for syncing the RAM
contents to the file, otherwise any changes made during runtime won't
persist reboots.
It's worth noting that the variable store format is defined in EBBR [0]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.
- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system
- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
BootNext: 0001
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* debian HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x100000)/File(EFI\debian\grubaa64.efi)
Boot0001* virtio 0 VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,850000001f000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,1600850000000000){auto_created_boot_option}
$~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootNext"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
00000000 01 00
FWTS runtime results
Skipped tests are for SetVariable which is now supported
'Passed' test is for QueryVariableInfo which is not yet supported
Test: UEFI miscellaneous runtime service interface tests.
Test for UEFI miscellaneous runtime service interfaces 6 skipped
Stress test for UEFI miscellaneous runtime service i.. 1 skipped
Test GetNextHighMonotonicCount with invalid NULL par.. 1 skipped
Test UEFI miscellaneous runtime services unsupported.. 1 passed
Test: UEFI Runtime service variable interface tests.
Test UEFI RT service get variable interface. 1 passed
Test UEFI RT service get next variable name interface. 4 passed
Test UEFI RT service set variable interface. 8 passed
Test UEFI RT service query variable info interface. 1 skipped
Test UEFI RT service variable interface stress test. 2 passed
Test UEFI RT service set variable interface stress t.. 4 passed
Test UEFI RT service query variable info interface s.. 1 skipped
Test UEFI RT service get variable interface, invalid.. 5 passed
Test UEFI RT variable services unsupported status. 1 passed, 3 skipped
[0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Currently efi_initrd_deregister() is called in bootefi.c
when the image started from bootefi command returns.
Since efi_guid_event_group_return_to_efibootmgr event is
implemented, so let's use this event for invoking
initrd deregistration.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
After allocating memory for the initrd file path we need to check the
initrd buffer pointer is not NULL.
Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Remove not needed variables from environment and include config files.
- setup variable used to be executed from some bootscript, however
it's not required and there is no point on having this small helper
here
- boot_file, kernel_file, ip_dyn variables are not used anywhere
- fdt_fixup variable is just set empty
- defargs, vidargs variables used to be used from some bootscript,
however there is no point on having it here and even old legacy
bootscript can work without them
- removed CONFIG_ENABLE_DDR_TRAINING_DEBUG, this is a leftover from
some copy/paste
On colibri imx6ull/imx7 NAND module, remove consoleblank=0, this is
already the Linux kernel default therefore useless.
Various Linux Kernel command line options removed are not-existing
left-over that applied to some old NXP i.MX downstream branch
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The GW73xx baseboard needs a PCI dt adjustment for revC/D based on a
change of the PCIe switch. Make sure we are only doing this for a pci
based ethernet to avoid causing a boot hang when the ethernet1 alias
points to eqos or fec. To know this is a pcie device ensure the alias
begins with the pcie controller.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
In Linux, we allow sleep moci to be turned off when the carrier board
supports it and the system is in suspend. In U-Boot, however, we want
the sleep moci to be always on. So we use a gpio hog and disable the
regulator. This change is necessary because we switched to upstream
device tree files with commit 23fe2def1edf
("verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAM"). A
recent upstream patch removes the gpio hog from the Linux device tree,
so we need to add it to the u-boot dtsi. The following patch will remove
the gpio hog from the Linux device tree:
https://lore.kernel.org/linux-devicetree/20240405160720.5977-1-eichest@gmail.com/
The U-Boot patch can be applied without it and will not break the build.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
The following information printed on every boot is not very
helpful for the users:
SOC: 0xa0009300
LC: 0x40040
Move them to debug() level.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Mathieu Othacehe <othacehe@gnu.org>
Enable support for TPM2 devices. As the ATTPM20P TPM2 used on the
Gateworks Venice boards hangs off the SPI bus we enable SPI support
as well.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
_ Add OHCI HCD support for STM32MP15xx DHSOM
_ Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
_ Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
_ Jump to ep on successful resume in PSCI suspend code
_ Add FASTBOOT support for STM32MP13
_ Fix/Rework key and leds management for STM32MP13/15
_ net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support
MP2:
_ Add stm32-fmc-ebi support
_ Add: sdmmc2 support and fix AARCH64 compilation
-----BEGIN PGP SIGNATURE-----
iQJQBAABCgA6FiEEXyrViUccKBz9c35Jysd4L3sz/6YFAmYiQ/EcHHBhdHJpY2Uu
Y2hvdGFyZEBmb3NzLnN0LmNvbQAKCRDKx3gvezP/ph+3D/4qsN+tYQYzBfCnhCjA
eEHMHGS6wBUg4riF5bjvk68CEVDIxm7NARFJi0RodvYsOZF7kLLyELm9yyNcWb+1
gkqLNcLLWFRhLyAIfCTnl88+luR6F48TPdVIXw17Vb3n4Fc99ICaS2PHYbHeRbR+
d/oga0DBz2N21+scYrUjPQoeczdk/fui84AXF7u8/7zFdYY0p50wHItKQHt4KXMv
TnM9KbeHGlxRdIiVR2Jvv5Q51mhwv8XczgOZdmGLDYBV3xKexacHsLgfVcwSM2C8
1YHFA6VWVAOcJyQ+VFKmQw0JoTUWueJCY21T6H6fsAnpMTc9tksu3nLJO0P8CCN0
IbI50trzLWPy/BZtqJwV67durp6ZA6hT5wQOTo7NHAFocql9hJKtDuhvTVHqmx6R
6SWpTWD24Mkgd9FrXk/yMEUOmihOB8U6q+GkyPf/yfWyZK93mUwiRStFkBwEz8QY
AX5gNoQ7+zJhkfZ4VdsCsFaVJV7Y9vlN3hnNhqLVEhXJ9GvFOszAZOTuuO8rLAv7
i7HE8Hk7zv6j15qSUPKOQv8BO0eVFlLPzTXS9F/uzSlpjfpNIs7At3TyQ4pAukRo
uHc7KjHpVAkC+7YeMuVR3VFQ/p2+5EyxMclKIvGlOxqD/+m1Keu+C4/gTkWYlIgx
mWqsvZCAi2RmDcUWBBB2mHpswQ==
=up9Y
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20240419' of https://source.denx.de/u-boot/custodians/u-boot-stm
MP1:
_ Add OHCI HCD support for STM32MP15xx DHSOM
_ Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
_ Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
_ Jump to ep on successful resume in PSCI suspend code
_ Add FASTBOOT support for STM32MP13
_ Fix/Rework key and leds management for STM32MP13/15
_ net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support
MP2:
_ Add stm32-fmc-ebi support
_ Add: sdmmc2 support and fix AARCH64 compilation
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in kernel DT.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The blue led is used to indicate U-Boot entering / exit indication
then Linux heartbeat.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in kernel DT.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
2 gpio-keys.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Remove "color" property from led-red node which is not supported
by U-Boot.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from led-red and
led-blue led's node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Instead of using gpio directly to detect key pressed on button
dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Enable BUTTON_GPIO flag for STM32MP15.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Enable BUTTON_GPIO flag for STM32MP15.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Enable BUTTON_GPIO flag for STM32MP15.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Enable BUTTON_GPIO flag for STM32MP15.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
When building with AARCH64 defconfig, we got warnings, fix them.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Fix flash@0 partition node name with correct offset.
Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-dhcom/dhcor")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Fix flash@0 partition node name with correct offset.
Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand node for
stm32mp15xx-dhcom/dhcor")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Fix flash@0 and nand@0 partition node name with correct offset.
Fixes: e91d3c61767b ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-ev1")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
released from endless loop in BootROM only by populating TAMP BKPxR 4
and 5 with magic and branch address and sending SGI0 interrupt from
core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized
as well to release the core 1 from endless loop during the second SGI0
handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup
registers, the ones which contain the core 1 magic, branch address and
boot information.
This requirement seems to be undocumented, therefore it was necessary
to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump.
Ultimately, it turns out that a certain BootROM function reads out the
TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero.
If they are zero, the BootROM code again waits for SGI0 using WFI, else
the execution moves forward until it reaches handoff to the TAMP BKPxR 5
branch address.
This fixes CPU core 1 release using U-Boot PSCI implementation on an
OTP-CLOSED system, i.e. system with fuse 0 bit 6 set.
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
SoC revision is only accessible via DBUMCU IDC register,
which requires BSEC.DENABLE DBGSWENABLE bit to be set to
make the register accessible, otherwise an access to the
register triggers bus fault. As BSEC.DBGSWENABLE is zero
in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
bit as this might open a brief window for timing attacks.
Instead, report that this system is OTP-CLOSED and do not
report any SoC revision to avoid confusing users. Use an
SEC/C abbreviation to avoid growing SOC_NAME_SIZE .
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not
in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two
Makefile entries in each subdirectory. Drop the bogus one and keep
only the correct one, the one in arch/arm/mach-stm32mp/Makefile .
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
