The driver used for the Allwinner I2C IP is using proper DT and DM
enablement for a while: we enable the clock gate and de-assert the reset
line in the driver's probe() routine, and the pinmux setup is taken care
of by the DM framework.

This means the explicit call to the i2c_init_board() routine is not
needed for U-Boot proper. As the board_init() function in board.c is
only called for U-Boot proper, we can remove the call, something that
the comment there hinted at already.

Fix the comment for the board_init() function on the way: we were not
really doing board specific setup there. The fact that this function
is called from U-Boot proper only is probably more helpful for reasoning
about this code.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Some later 32-bit SoCs require some setup of the Secure Peripherals
Controller, which is handled in tzpc_init().
At the moment this is guarded in board.c by some #ifdefs selecting the
SoCs that need it.

Move those #ifdef guards into the header file, providing an empty stub
function for all other SoCs, so that the #ifdefs can be removed from the
.c file, to improve readability.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The Allwinner F1C100s SoC has a MUSB controller like the one in the A33,
but needs an SRAM region to be claimed like the A10. We do the latter
anyway, even on chips that don't need it, so there is no real difference
in our compatible string matching.

Add a mapping between the config struct used in the Linux to our
requirements here on the way.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Maksim Kiselev authored 1 year ago and André Przywara committed 11 months ago

R528/T113 SoCs uses the same SPI IP as the H6, also have the same clocks
and reset bits layout, but the CCU base is different. Another difference
is that the new SoCs do not have a clock divider inside. Instead of this
we should configure sample mode depending on input clock rate.

The pin assignment is also different: the H6 uses PC0, the R528/T113 PC4
instead. This makes for a change in spi0_pinmux_setup() routine.

This patch extends the H6/H616 #ifdef guards to also cover the R528/T113,
using the shared CONFIG_SUNXI_GEN_NCAT2 and CONFIG_MACH_SUN8I_R528
symbols. Also use CONFIG_SUNXI_GEN_NCAT2 symbol for the Kconfig
dependency.

Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>

CI:
https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20444

- Make i.MX93 boot less verbose.
- Remove unneedd environment variables from Toradex i.MX boards.
- Use gpio-hog on verdin-imx8mm/imx8mp.
- Add PCIe support for i.MX8MM.
- Add TPM support for imx8m*-venice.

Pull request efi-2024-07-rc1-3

Documentation:

* sort env sub-commands alphabetically
* update list of aliases for the env command

UEFI:

* allow enabling SetVariable at runtime
  for future OS supported writing to ubootefi.var
* use event callback for initrd deregistration

Others:

* correct alignment of x86 firmware tables

On qemu-x86_64_defconfig the following was observed:

    => efidebug tables
    00000000000f0074  eb9d2d31-2d88-11d3-9a16-0090273fc14d  SMBIOS table

The SMBIOS configuration table does not point to a paragraph-aligned
(16 byte aligned) address. The reason is that in write_tables() rom_addr is
not aligned and copied to gd->arch.smbios_start.

The Simple Firmware Interface requires that the SFI table is paragraph-
aligned but our code does not guarantee this.

As all tables written in write_tables() must be paragraph-aligned, we
should implement the address rounding in write_tables() and not in table
specific routines like copy_pirq_routing_table().

Add paragraph-alignment in write_tables().

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Ilias Apalodimas authored 11 months ago and Heinrich Schuchardt committed 11 months ago

Since we support SetVariableRT now add the relevant tests

- Search for the RTStorageVolatile and VarToFile variables after EBS
- Try to update with invalid variales (BS, RT only)
- Try to write a variable bigger than our backend storage
- Write a variable that fits and check VarToFile has been updated
  correclty
- Append to the variable and check VarToFile changes
- Try to delete VarToFile which is write protected
- Try to add/delete runtime variables
- Verify VarToFile contains a valid file format

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

Ilias Apalodimas authored 11 months ago and Heinrich Schuchardt committed 11 months ago

Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.

So let's add a new variable, in its own namespace called "VarToFile"
which contains a binary dump of the updated RT, BS and, NV variables
and will be updated when GetVariable is called.

Some adjustments are needed to do that.
Currently we discard BS-only variables in EBS(). We need to preserve
those on the RAM backend that exposes the variables. Since BS-only
variables can't appear at runtime we need to move the memory masking
checks from efi_var_collect() to efi_get_next_variable_name_mem()/
efi_get_variable_mem() and do the filtering at runtime.

We also need an efi_var_collect() variant available at runtime, in order
to construct the "VarToFile" buffer on the fly.

All users and applications (for linux) have to do when updating a variable
is dd that variable in the file described by "RTStorageVolatile".

Linux efivarfs uses a first 4 bytes of the output to represent attributes
in little-endian format. So, storing variables works like this:

$~ efibootmgr -n 0001
$~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1

[0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage



Suggested-by: Ard Biesheuvel <ardb@kernel.org> # dumping all variables to a variable
Co-developed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> # contributed on efi_var_collect_mem()
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Ilias Apalodimas authored 11 months ago and Heinrich Schuchardt committed 11 months ago

Previous patches enable SetVariable at runtime using a volatile storage
backend using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's
no recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and update it at runtime

$~ efivar -p -n b2ac5fc9-92b7-4acd-aeac-11e818c3130c-RTStorageVolatile
GUID: b2ac5fc9-92b7-4acd-aeac-11e818c3130c
Name: "RTStorageVolatile"
Attributes:
	Boot Service Access
	Runtime Service Access
Value:
00000000  75 62 6f 6f 74 65 66 69  2e 76 61 72 00           |ubootefi.var.   |

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

Ilias Apalodimas authored 11 months ago and Heinrich Schuchardt committed 11 months ago

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>

Masahisa Kojima authored 1 year ago and Heinrich Schuchardt committed 11 months ago

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>

%s/mstching/matching/

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

After allocating memory for the initrd file path we need to check the
initrd buffer pointer is not NULL.

Fixes: 87d79142 ("eficonfig: menu-driven addition of UEFI boot option")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

* add link to askenv man-page
* add printenv

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

The 'env' man-page is currently only partially sorted.

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

Enable PCIe/NVMe support. Also, enable the reset
driver which is a prerequisite for PCIe support.

Signed-off-by: Tim Harvey <tharvey@gateworks.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>

Enable ipv6, wget, and tftpput support

Signed-off-by: Tim Harvey <tharvey@gateworks.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 23fe2def
("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>

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

u-boot-dfu-20240419

- new "fastboot oem board" command

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>

Add 2 gpio-keys :
  _ button-user-1 for stm32prog mode activation.
  _ button-user-2 for fastboot mode activation.

Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.

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>

Add 2 gpio-keys :
  _ button-user-1 for stm32prog mode activation.
  _ button-user-2 for fastboot mode activation.

Remove proprietary st,fastboot-gpios and st,stm32prog-gpios.

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>