summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-09riscv: set fdtfile on Milk-V MarsHeinrich Schuchardt
Set environment variable fdtfile to the correct value for the Milk-V Mars board. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09eeprom: starfive: function get_product_id_from_eeprom()Heinrich Schuchardt
Export a function get_product_id_from_eeprom() to read the product ID. This value can be used for fixing up the device-tree on JH7110 based products. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: do not set default fdt for VisionFive 2Heinrich Schuchardt
Currently in set_fdtfile() we set the value of environment variable fdtfile unconditionally. The implies that a value in the environment will be ignored. With the patch environment variable fdtfile will only be set if it does not yet exist. This requires that CONFIG_DEFAULT_FDT_FILE is not set. Now the user can either set and save fdtfile interactively or in the U-Boot configuration to overrule the device-tree name chosen based on the hardware in set_fdtfile(). Reported-by: E Shattow <[email protected]> Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: starfive: MMC card detectHeinrich Schuchardt
The VisionFive 2 board uses GPIO 41 as card detect as documented in https://doc-en.rvspace.org/VisionFive2/PDF/SCH_RV002_V1.2A_20221216.pdf. Signed-off-by: Heinrich Schuchardt <[email protected]> Acked-by: Minda Chen <[email protected]>
2024-04-09riscv: Move virtio scan to board_late_init()Łukasz Stelmach
When virtio_init() gets called from board_init() PCI isn't ready. Thus, virtio-over-PCI (e.g. network interfaces) devices can't be detected and used without additional `virtio scan` scan in the shell or a script. Signed-off-by: Łukasz Stelmach <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: support extension probing using riscv, isa-extensionsConor Dooley
A new property has been added, with an extensive rationale at [1], that can be used in place of "riscv,isa" to indicate what extensions are supported by a given platform that is a list of strings rather than a single string. There are some differences between the new property, "riscv,isa-extensions" and the incumbent "riscv,isa" - chief among them for the sake of parsing being the list of strings, as opposed to a string. Another advantage is strictly defined meanings for each string in a dt-binding, rather than deriving meaning from RVI standards. This will likely to some divergence over time, but U-Boot's current use of extension detection is very limited - there are just four callsites of supports_extension() in mainline U-Boot. These checks are limited to two checks for FPU support and two checks for "s" and "u". "s" and "u" are not supported by the new property, but they were also not permitted in "riscv,isa". These checks are only meaningful (or run) in M-Mode, in which case supports_extension() does not parse the devicetree anyway. Add support for the new property in U-Boot, prioritising it, before falling back to the, now deprecated, "riscv,isa" property if it is not present. Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: don't read riscv, isa in the riscv cpu's get_desc()Conor Dooley
cpu_get_desc() for the RISC-V CPU currently reads "riscv,isa" to get the description, but it is no longer a required property and cannot be assummed to always be present, as the new "riscv,isa-extensions" and "riscv,isa-base" properties may be present instead. On RISC-V, cpu_get_desc() has two main uses - firstly providing an informational name for the CPU for smbios or at boot with DISPLAY_CPUINFO etc and secondly it forms the basis of ISA extension detection in supports_extension() as it returns (a portion of) an ISA string. cpu_get_desc() returns a string, which aligned with "riscv,isa" but the new property is a list of strings. Rather than add support for the list of strings property, which would require creating an isa string from "riscv,isa-extensions", modify the RISC-V CPU's implementaion of cpu_get_desc() return the first compatible as the cpu description instead. This may be fine for the informational cases, but it would break extension dtection, given supports_extension() expects cpu_get_desc() to return an ISA string. Call dev_read_string() directly in supports_extension() to get the contents of "riscv,isa" so that extension detection remains functional. As a knock-on affect of this change, extension detection is no longer broken for long ISA strings. Previously if the ISA string exceeded the 32 element array that supports_extension() passed to cpu_get_desc(), it would return ENOSPC and no extensions would be detected. This bug probably had no impact as U-Boot does not currently do anything meaningful with the results of supports_extension() and most SoCs supported by U-Boot don't have anywhere near that complex of an ISA string. The QEMU virt machine's CPUs do however, so extension detection doesn't work there. Signed-off-by: Conor Dooley <[email protected]> reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09configs: milkv_duo: Add SD card configsKongyang Liu
Add configs related to sdhci and mmc for Sophgo Milk-V Duo board Signed-off-by: Kongyang Liu <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: dts: sophgo: Add clk node and sdhci nodeKongyang Liu
Add clk node and sdhci node for cv18xx SoCs according to patches from Linux kernel. clk: https://lore.kernel.org/all/IA1PR20MB4953F9AD6792013B54636F05BB4F2@IA1PR20MB4953.namprd20.prod.outlook.com/ sdhci: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Kongyang Liu <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09mmc: cv1800b: Add sdhci driver support for cv1800b SoCKongyang Liu
Add sdhci driver for cv1800b SoC. Signed-off-by: Kongyang Liu <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: cache: Implement dcache for cv1800bKongyang Liu
Add dcache operations invalidate_dcache_range and flush_dcache_range for cv1800b. Signed-off-by: Kongyang Liu <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: cpu: cv1800b: Add support for cv1800b SoCKongyang Liu
Add Sophgo cv1800b SoC to support RISC-V arch. Signed-off-by: Kongyang Liu <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2024-04-09riscv: add backtrace supportBen Dooks
When debugging, it is useful to have a backtrace to find out what is in the call stack as the previous function (RA) may not have been the culprit. Since this adds size to the build, do not add it by default and avoid putting it in the SPL build if not needed. Signed-off-by: Ben Dooks <[email protected]> Tested-by: Leo Yu-Chi Liang <[email protected]>
2024-04-08Merge tag 'efi-2024-07-rc1' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-efi Pull request efi-2024-07-rc1 Documentation: * improve description of FAT partition name generation * add missing :: in doc/usage/cmd/itest.rst UEFI: * fix address mode for __efi_runtime_start/stop, __efi_runtime_rel_start/stop * fix size of variable attribute constants * enable booting via EFI boot manager by default * correct the sequence of the EFI boot methods * correct finding the default EFI binary * don't delete variable from memory if update failed * fix append write behavior to non-existent variable * Use binman for testing capsule updates on the sandbox * Consider capsule test files in .gitignore and make clean
2024-04-08efi_loader: access __efi_runtime_rel_start/stop without &Ilias Apalodimas
A symbol defined in a linker script (e.g. __efi_runtime_rel_start = .;) is only a symbol, not a variable and should not be dereferenced. The common practice is either define it as extern uint32_t __efi_runtime_rel_start or extern char __efi_runtime_rel_start[] and access it as &__efi_runtime_rel_start or __efi_runtime_rel_start respectively. So let's access it properly since we define it as an array Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
2024-04-08efi_loader: access __efi_runtime_start/stop without &Ilias Apalodimas
A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is only a symbol, not a variable and should not be dereferenced. The common practice is either define it as extern uint32_t __efi_runtime_start or extern char __efi_runtime_start[] and access it as &__efi_runtime_start or __efi_runtime_start respectively. So let's access it properly since we define it as an array Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
2024-04-08boot: correct finding the default EFI binaryHeinrich Schuchardt
* The sandbox must not use an arbitrary file name bootsbox.efi but the file name matching the host architecture to properly boot the respective file. We already have an include which provides a macro with the name of the EFI binary. Use it. * The path to the EFI binary should be absolute. * The path and the file name must be capitalized to conform to the UEFI specification. This is important when reading from case sensitive file systems. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]> Tested-by: Ilias Apalodimas <[email protected]>
2024-04-08efi_loader: move HOST_ARCH to version_autogenerated.hHeinrich Schuchardt
efi_default_filename.h requires HOST_ARCH to be defined. Up to now we defined it via a CFLAGS. This does not scale. Add the symbol to version_autogenerated.h instead. Signed-off-by: Heinrich Schuchardt <[email protected]> Acked-by: Ilias Apalodimas <[email protected]>
2024-04-08boot: enable booting via EFI boot manager by defaultHeinrich Schuchardt
If UEFI is enabled in U-Boot, we want it to conform to the UEFI specification. This requires enabling the boot manager boot method. Reported-by: E Shattow <[email protected]> Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-04-08boot: correct the default sequence of boot methodsHeinrich Schuchardt
The default sequence of boot methods is determined by alphabetical sorting during linkage. * efi_mgr must run before efi to be UEFI compliant * pxe should run as last resort Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-04-08efi_loader: Don't delete variable from memory if adding a new one failedIlias Apalodimas
Our efi_var_mem_xxx() functions don't have a replace variant. Instead we add a new variable and delete the old instance when trying to replace a variable. Currently we delete the old version without checking the new one got added Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
2024-04-08efi_loader: handle EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESSHeinrich Schuchardt
We don't yet support EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS for file based variables, but we should pass it to TEE based variable stores. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-04-08efi_loader: EFI_VARIABLE_READ_ONLY should be 32bitHeinrich Schuchardt
GetVariable() and SetVariable() only accept a 32bit value for attributes. It makes not sense to define EFI_VARIABLE_READ_ONLY as unsigned long. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-04-08efi_loader: all variable attributes are 32bitHeinrich Schuchardt
GetVariable() and SetVariable() use an uint32_t value for attributes. The UEFI specification defines the related constants as 32bit. Add the missing EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS constant. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2024-04-08efi_loader: fix append write behavior to non-existent variableMasahisa Kojima
Current "variables" efi_selftest result is inconsistent between the U-Boot file storage and the tee-based StandaloneMM RPMB secure storage. U-Boot file storage implementation does not accept SetVariale call to non-existent variable with EFI_VARIABLE_APPEND_WRITE, it return EFI_NOT_FOUND. However it is accepted and new variable is created in EDK II StandaloneMM implementation if valid data and size are specified. If data size is 0, EFI_SUCCESS is returned. Since UEFI specification does not clearly describe the behavior of the append write to non-existent variable, let's update the U-Boot file storage implementation to get aligned with the EDK II reference implementation. Signed-off-by: Masahisa Kojima <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]> Tested-by: Ilias Apalodimas <[email protected]>
2024-04-08doc: improve description of FAT partition name generationHeinrich Schuchardt
List all prefix currently used for generating FAT partition names. Describe which device class uses which prefix. Signed-off-by: Heinrich Schuchardt <[email protected]>
2024-04-08doc: missing :: in doc/usage/cmd/itest.rstHeinrich Schuchardt
Add :: for correct formatting of example. Signed-off-by: Heinrich Schuchardt <[email protected]>
2024-04-08capsule: Makefile: add the generated files to CLEAN_FILES listSughosh Ganu
A certain set of capsule files are now generated as part of the sandbox build. Add these files to the CLEAN_FILES list for deletion on invoking any of the cleanup targets. Reviewed-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Sughosh Ganu <[email protected]>
2024-04-08capsule: add the generated capsules to gitignoreSughosh Ganu
The sandbox platform build now generates a set of capsules. Put the related files generated into gitignore. Reviewed-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Sughosh Ganu <[email protected]>
2024-04-08sandbox: capsule: binman: generate some capsules as part of buildSughosh Ganu
Currently, all the capsules for the sandbox platform are generated at the time of running the capsule tests. To showcase generation of capsules through binman, generate all raw(non FIT payload) capsules needed for the sandbox platform as part of the build. This acts as an illustrative example for generating capsules as part of a platform's build. Make corresponding change in the capsule test's configuration to get these capsules from the build directory. Signed-off-by: Sughosh Ganu <[email protected]>
2024-04-08sandbox: capsule: remove capsule related configsSughosh Ganu
The capsule update testing is carried out only on the sandbox and sandbox_flattree variants. Remove the capsule update related configs from the other sandbox variants. This ensures that the capsule files are generated only on variants which are used for the feature's testing. Signed-off-by: Sughosh Ganu <[email protected]>
2024-04-05Merge tag 'u-boot-imx-master-20240405' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-imx CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20228 - Convert imx8mp-beacon and verdin-imx8mm/verdin-imx8mp to OF_UPSTREAM. - Enable PCIe NVMe support on imx8mp_beacon. - Fix Ethernet and board detection on mx6cuboxi. - Fix signature_block_hdr struct fields. - Fix imx9_probe_mu prototype and make it to get called in EVT_DM_POST_INIT_R. - Test whether ethernet node is enabled before reading MAC EEPROM on DHSOM SoMs.
2024-04-05Merge tag 'qcom-next-2024Apr04' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-snapdragon - Ethernet, i2c, and USB support are now enabled by default - The clock driver gets some bug fixes and cleanup - Invalid FDTs are now properly detected in board_fdt_blob_setup(). - The pinctrl driver gains preparatory support for per-pin function muxes. - Support is added for two generations of Qualcomm HighSpeed USB PHY - A power domain driver is added for the Globall Distributed Switch Controllers on the GCC hardware block. - SDM845 gains USB host mode support. - OF_LIVE is enabled by default for Qualcomm platforms - Some U-Boot devicetree compatibility fixups are added during init to improve compatbility with upstream DT.
2024-04-05Merge tag 'u-boot-amlogic-20240404' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-amlogic - jethubj100: fix config, MAINTAINERS & update docs - Switch GXL, GXM, AXG, G12A, G12B & SM1 to using upstream DT
2024-04-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini
- kirkwood: Switch to using upstream dts/dtsi files (Tony) - mvebu: Turris Omnia - New board revision support (Marek)
2024-04-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-samsungTom Rini
2024-04-05arm: imx: fix signature_block_hdr struct fields orderJavier Viguera
According to the documentation (for example NXP's AN13994 on encrypted boot on AHAB-enabled devices), the format of the signature block is: +--------------+--------------+--------------+-------------+ | Tag | Length - msb | Length - lsb | Version | +--------------+--------------+--------------+-------------+ | SRK Table offset | Certificate offset | +-----------------------------+----------------------------+ | Blob offset | Signature offset | +-----------------------------+----------------------------+ There is no runtime error in the current u-boot code. The only user of struct signature_block_hdr is the "get_container_size" function in the "arch/arm/mach-imx/image-container.c" file, and it's only using the very first fields of the struct (which are in the correct position) and thus there is no runtime failure. On the other hand, extending the code to get the data encryption key blob offset on the signature header gives a wrong value as the field is in the wrong order. Signed-off-by: Javier Viguera <[email protected]>
2024-04-05verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAMMarcel Ziswiler
Move verdin-imx8mm and verdin-imx8mp to OF_UPSTREAM: - handle the fact that dtbs now have a 'freescale/' prefix - imply OF_UPSTREAM - remove redundant files from arch/arm/dts leaving only the *-u-boot.dtsi files - update MAINTAINERS files Signed-off-by: Marcel Ziswiler <[email protected]> Reviewed-by: Sumit Garg <[email protected]>
2024-04-05arm: imx9: Call imx9_probe_mu for DM post in board_rYe Li
This event callback imx9_probe_mu needs to be called in board_r as well, because many ELE APIs depending on this MU probed Signed-off-by: Ye Li <[email protected]>
2024-04-05arm: imx9: Correct imx9_probe_mu prototypeYe Li
Since the event callback imx9_probe_mu is re-defined, update its prototype. Signed-off-by: Ye Li <[email protected]>
2024-04-05mx6cuboxi: Fix Ethernet after DT sync with LinuxJosua Mayer
The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying addresses. U-Boot needs to auto-detect which phy is actually present, and at which address it is responding. Auto-detection from multiple phy nodes specified in device-tree does not currently work correct. As a work-around merge all three possible phys into one node with the special address 0xffffffff which indicates to the generic phy driver to probe all addresses. Signed-off-by: Josua Mayer <[email protected]> [fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.] Signed-off-by: Fabio Estevam <[email protected]> Tested-by: Christian Gmeiner <[email protected]> Tested-by: Christian Gmeiner <[email protected]>
2024-04-05mx6cuboxi: Do not print devicetree modelFabio Estevam
The mx6cuboxi_defconfig target supports several board variants. All of these variants use the hummingboard devicetree in U-Boot. Currently, the devicetree model as well as the board variant name are shown: ... Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) Board: MX6 Cubox-i ... Printing the devicetree model that is used internally by U-Boot may confuse users. Unselect the CONFIG_DISPLAY_BOARDINFO option so that only the board name is printed in board_late_init() instead. Signed-off-by: Fabio Estevam <[email protected]> Tested-by: Christian Gmeiner <[email protected]>
2024-04-05ARM: imx: stm32: Test whether ethernet node is enabled before reading MAC ↵Marek Vasut
EEPROM on DHSOM Check whether the ethernet interface is enabled at all before reading MAC EEPROM. As a cost saving measure, it can happen that the MAC EEPROM is not populated on SoMs which do not use ethernet. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Patrice Chotard <[email protected]>
2024-04-05configs: imx8mp_beacon: Enable PCIe NVMe drivesAdam Ford
The baseboard supports and NVMe drives via the PCIe slot. This requires a few extra config options to be enabled. The NVMe can be enumerated with the following commands: u-boot=> pci enum PCIE-0: Link up (Gen1-x1, Bus0) u-boot=> nvme scan u-boot=> nvme info Device 0: Vendor: 0x15b7 Rev: 20120022 Prod: 184960441105 Type: Hard Disk Capacity: 122104.3 MB = 119.2 GB (250069680 x 512) u-boot=> Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Sumit Garg <[email protected]>
2024-04-05arm64: imx: imx8mn-beacon: Migrate to OF_UPSTREAMAdam Ford
The imx8mn-beacon boards can migrate to OF_UPSTREAM which also allows for the removal the device tree files. Signed-off-by: Adam Ford <[email protected]>
2024-04-05arm64: imx: imx8mm-beacon: Migrate to OF_UPSTREAMAdam Ford
The imx8mm-beacon boards can migrate to OF_UPSTREAM which also allows for the removal the device tree files. Signed-off-by: Adam Ford <[email protected]>
2024-04-05arm64: imx: imx8mp-beacon: Migrate to OF_UPSTREAMAdam Ford
The imx8mp-beacon boards can migrate to OF_UPSTREAM which also allows for the removal the device tree files. Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Sumit Garg <[email protected]>
2024-04-05usb: xhci: Abort transfers with unallocated ringsJanne Grunau
Discovered while trying to use the second interface in the USB keyboard driver necessary on Apple USB keyboards. Reviewed-by: Marek Vasut <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Janne Grunau <[email protected]>
2024-04-05usb: xhci: Set up endpoints for the first 2 interfacesJanne Grunau
The xhci driver currently only does the necessary initialization for endpoints found in the first interface descriptor. Apple USB keyboards (released 2021) use the second interface descriptor for the HID keyboard boot protocol. To allow USB drivers to use endpoints from other interface descriptors the xhci driver needs to ensure these endpoints are initialized as well. Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors are considered during endpoint initialisation. For now define it to 2 as that is sufficient for supporting the Apple keyboards. Reviewed-by: Marek Vasut <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Janne Grunau <[email protected]>
2024-04-05usb: xhci: refactor xhci_set_configurationJanne Grunau
In the next step endpoints for multiple interfaces are set up. Move most of the per endpoint initialization to separate function to avoid another identation level. Reviewed-by: Marek Vasut <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Janne Grunau <[email protected]>