- Apr 22, 2024
-
-
André Przywara authored
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>
-
- Apr 21, 2024
-
-
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>
-
- Apr 20, 2024
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-imxTom Rini authored
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.
-
https://source.denx.de/u-boot/custodians/u-boot-efiTom Rini authored
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
-
Heinrich Schuchardt authored
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>
-
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:
-
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:
-
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:
-
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: -
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:
-
Heinrich Schuchardt authored
%s/mstching/matching/ Reported-by:
E Shattow <lucent@gmail.com> Signed-off-by:
-
Heinrich Schuchardt authored
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 authored
* add link to askenv man-page * add printenv Signed-off-by: -
Heinrich Schuchardt authored
The 'env' man-page is currently only partially sorted. Signed-off-by: -
Tim Harvey authored
Enable PCIe/NVMe support. Also, enable the reset driver which is a prerequisite for PCIe support. Signed-off-by:Tim Harvey <tharvey@gateworks.com>
-
Tim Harvey authored
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 authored
Add support for PCIe clocks required to enable PCIe support on iMX8MM SoC. Signed-off-by:
-
Francesco Dolcini authored
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>
-
Tim Harvey authored
Enable ipv6, wget, and tftpput support Signed-off-by: -
Tim Harvey authored
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: -
Stefan Eichenberger authored
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>
-
Fabio Estevam authored
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>
-
Tim Harvey authored
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:
-
- Apr 19, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-stmTom Rini authored
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
-
https://source.denx.de/u-boot/custodians/u-boot-dfuTom Rini authored
u-boot-dfu-20240419 - new "fastboot oem board" command
-
Patrice Chotard authored
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> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
The blue led is used to indicate U-Boot entering / exit indication then Linux heartbeat. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare 2 gpio-keys. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Patrice Chotard authored
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:
Patrick Delaunay <patrick.delaunay@foss.st.com>
-
