- Dec 11, 2024
-
-
Since RPI works well using EFI and has no size limitations with regards to U-Boot, add the needed structures to support capsule updates. While at it update the most commonly used defconfigs and include capsule support and U-Boot commands needed by EFI Tested-by:
Sughosh Ganu <sughosh.ganu@linaro.org> Signed-off-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
Peter Robinson authored
For a lot of usecases, such as display, camera, media the Raspberry Pi needs a lot more CMA than distros configure as default so we should pass this parameter through so things work as expected. Fix a spelling mistake while we're at it. Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Acked-by:
Matthias Brugger <mbrugger@suse.com>
-
- Dec 09, 2024
-
-
Tom Rini authored
Signed-off-by:Tom Rini <trini@konsulko.com>
-
-
- Dec 08, 2024
-
-
Marek Vasut authored
The U-Boot is currently not capable of handling ethernet-phy-ieee802.3-c45 PHYs correctly, and also does not handle MDIO bus wide reset-gpios property. Until proper C45 PHY support lands in U-Boot, disable AVB1/AVB2 interfaces. This only disables the two MACs with 88Q2110/88Q2112 100/1000BASE-T1 PHYs on ethenet sub-board, the main board AVB0 ethernet is unaffected. Signed-off-by:Marek Vasut <marek.vasut+renesas@mailbox.org>
-
Paul Barker authored
In rzg2l_pinconf_set(), there are no new variables defined in the case statement for PIN_CONFIG_INPUT_ENABLE so no additional scope is needed. Signed-off-by:
Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by:
-
Paul Barker authored
On the RZ/G2L SoC family, the direction of the Ethernet TXC/TX_CLK signal is selectable to support an Ethernet PHY operating in either MII or RGMII mode. By default, the signal is configured as an input and MII mode is supported. The ETH_MODE register can be modified to configure this signal as an output to support RGMII mode. As this signal is be default an input, and can optionally be switched to an output, it maps neatly onto an `output-enable` property in the device tree. Signed-off-by:
-
Paul Barker authored
The Ethenet interfaces on the Renesas RZ/G2L SoC family can operate at multiple power supply voltages: 3.3V (default value), 2.5V and 1.8V. rzg2l_pinconf_set() is extended to support the 2.5V setting, with a check to ensure this is only used on Ethernet interfaces as it is not supported on the SD & QSPI interfaces. While we're modifying rzg2l_pinconf_set(), drop the unnecessary default value for pwr_reg as it is set in every branch of the following if condition. Signed-off-by:
-
Paul Barker authored
We can call dev_read_u32_default() instead of calling fdt_getprop() then fdt32_to_cpu(). Signed-off-by:
-
Paul Barker authored
In the RZ/G2L family, core clocks are always on and can't be disabled. However, drivers which are shared with other SoCs may call clk_enable() or clk_enable_bulk() for a clock referenced in the device tree which happens to be a core clock on the RZ/G2L. To avoid the need for conditionals in these drivers, simply ignore attempts to enable a core clock. Signed-off-by:
-
- Dec 06, 2024
-
-
When MbedTLS TLS features were added MBEDTLS_HAVE_TIME was defined as part of enabling https:// support. However that pointed to the wrong function which could crash if it received a NULL pointer. Looking closer that function is not really needed, as it only seems to increase the RNG entropy by using 4b of the current time and date. The reason that was enabled is that lwIP was unconditionally requiring it, although it's configurable and can be turned off. Since lwIP doesn't use that field anywhere else, make it conditional and disable it from our config. Fixes: commit a564f509 ("mbedtls: Enable TLS 1.2 support") Reported-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
Jerome Forissier <jerome.forissier@linaro.org>
-
Add a missing comma in the update_info structure declaration. This fixes the following build error when building with EFI_RUNTIME_UPDATE_CAPSULE or EFI_CAPSULE_ON_DISK: board/emulation/qemu-arm/qemu-arm.c:52:9: error: request for member ‘images’ in something not a structure or union Fixes: cccea188 ("efi_loader: add the number of image entries in efi_capsule_update_info") Signed-off-by:
Vincent Stehlé <vincent.stehle@arm.com> Cc: Masahisa Kojima <masahisa.kojima@linaro.org> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Cc: Tom Rini <trini@konsulko.com>
-
Building SPL fails with MBEDTLS enabled. Currently we don't need it there. Signed-off-by:
-
Building qemu_arm64_defconfig with CONFIGS_DM_RTC=n and CONFIGS_RTC_PL031=y leads to a build failure. Adjust the vexpress64 configuration to avoid circular dependency. Signed-off-by: -
There are platforms which set the value of ram_top based on certain restrictions that the platform might have in accessing memory above ram_top, even when the memory region is in the same DRAM bank. So, even though the LMB allocator works as expected, when trying to allocate memory above ram_top, prohibit this by marking all memory above ram_top as reserved, even if the said memory region is from the same bank. Signed-off-by:
Andreas Schwab <schwab@suse.de>
-
Tom Rini authored
Resync all defconfig files using qconfig.py Signed-off-by:
-
- Dec 05, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-pmicTom Rini authored
CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/23718 - Correct a few debug/error print calls
-
https://source.denx.de/u-boot/custodians/u-boot-tpmTom Rini authored
CI: https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/23719 Two fixes for the EFI subsystem coming via the TPM tree as agreed by Heinrich The LMB patch fixes a failure in SystemReady testing. Nothing bad happens without the patch in the device operation, but the return values are wrong and SCT tests fail for MemoryAllocationServicesTest category. The second is a shielding the device against mistakes in the definition of struct fields needed by the capsule update mechanism. Instead of crashing, print a humna readable message of what's wrong.
-
Ilias Apalodimas authored
At the moment the LMB allocator will return 'success' immediately on two consecutive allocations if the second one is smaller and the flags match without resizing the reserved area. This is problematic for two reasons, first of all the new updated allocation won't update the size and we end up holding more memory than needed, but most importantly it breaks the EFI SCT tests since EFI now allocates via LMB. More specifically when EFI requests a specific address twice with the EFI_ALLOCATE_ADDRESS flag set, the first allocation will succeed and update the EFI memory map. Due to the LMB behavior the second allocation will also succeed but the address ranges are already in the EFI memory map due the first allocation. EFI will then fail to update the memory map, returning EFI_OUT_OF_RESOURCES instead of EFI_NOT_FOUND which break EFI conformance. So let's remove the fast check with is problematic anyway and leave LMB resize and calculate address properly. LMB will now - try to resize the reservations for LMB_NONE - return -1 if the memory is not LMB_NONE and already reserved The LMB code needs some cleanup in that part, but since we are close to 2025.01 do the easy fix and plan to refactor it later. Also update the dm tests with the new behavior. Fixes: commit 22f2c9ed ("efi: memory: use the lmb API's for allocating and freeing memory") Signed-off-by:
-
Ilias Apalodimas authored
The gen_v5_guid() is a void and does no error checking with pointers being available etc. Instead it expects all things to be in place to generate GUIDs. If a board capsule definition is buggy and does not define the firmware names when enabling capsule updates, the board will crash trying to bring up the EFI subsystem. Check for a valid firmware name before generating GUIDs. Reviewed-by:
-
- Dec 04, 2024
-
-
To ease debugging, use dev_err() instead of dev_dbg() for alerting when regulator has nonunique value. Signed-off-by:
Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by:
Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com>
-
Replace some debug() by dev_dbg() when dev variable is available/valid. Signed-off-by:
-
- Dec 03, 2024
-
-
-
PSCI reset is not implemented in Exynos850 EL3 firmware. Disable it to fix the reset in cases where it can be used, e.g. when running EFI selftest. Signed-off-by:
Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by:
Minkyu Kang <mk7.kang@samsung.com>
-
- Dec 02, 2024
-
-
Patch resolves two kind of bugs, one of which is vulnerability related to KASLR. === Issue briefly === Working with FDT (via non-relocated gd::fdt_blob) from inside bootm command may lead to the reading the garbage instead of FDT nodes. And this can result in various side-effects depending on DTS nodes, being parsed during bootm. But below is my specific story how I faced with this issue due to MESON_RNG probing failure. === Bugs description === 1) Bug is revealed on: * configuration below * U-boot 2024.10 - f919c3a8 ("Prepare v2024.10") It seems, the following patch is a trigger: ea955eea ("fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled") Generally, CONFIG_OF_EMBED=y & CONFIG_RNG_MESON=y are the most valuable ones for reproducing the issue. ``` CONFIG_ARCH_FIXUP_FDT_MEMORY=y CONFIG_CMD_FDT=y CONFIG_DEFAULT_FDT_FILE="" CONFIG_FDT_64BIT=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_OF_LIBFDT_ASSUME_MASK=0x0 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_OF_LIBFDT=y CONFIG_OF_LIST="meson-axg-our-device-name" CONFIG_OF_REAL=y CONFIG_OF_TRANSLATE=y CONFIG_SUPPORT_OF_CONTROL=y CONFIG_SYS_FDT_PAD=0x3000 CONFIG_TOOLS_OF_LIBFDT=y CONFIG_DM_RNG=y CONFIG_RNG_MESON=y ``` 2) Due to CONFIG_OF_EMBED, the DTS is embedded into U-boot ELF and accessible via __dtb_dt_begin symbol. On early boot stage (board_f.c) the fdtdec_setup() is called only once before U-boot's relocation into top of RAM. fdtdec_setup() initializes gd::fdt_blob for FDTSRC_EMBED case: ``` gd->fdt_blob = dtb_dt_embedded(); gd->fdt_src = FDTSRC_EMBED; ``` 3) Then reloc_fdt() is called in board_f.c But due to CONFIG_OF_EMBED=y the reloc_fdt() does not update gd::fdt_blob value (strictly speaking, it is impossible for CONFIG_OF_EMBED=y, because U-boot ELF has not been relocated yet at this moment). As a result after relocation we get fdt_blob, pointing to DTS address before relocation: ``` # bdinfo <...> relocaddr = 0x000000000fedf000 reloc off = 0x000000000eedf000 <...> fdt_blob = 0x010ce6c0 << points to __dtb_dt_begin before relocation new_fdt = 0x0000000000000000 << empty erroneously fdt_size = 0x0000000000000000 << zero erroneously ``` 4) During bootm command (according to our ITS-config file) the Linux is loaded into 0x01080000 (which is very close to fdt_blob addr 0x010ce6c0). ``` ## Loading kernel from FIT Image at 04000000 ... Trying 'kernel' kernel subimage <...> Load Address: 0x01080000 ``` So Linux image overwrites the gd::fdt_blob memory location in RAM (0x010ce6c0). 5) Issue: Hence any manipulation with DTS (say, via FDT API) inside implementation of bootm command leads to accessing the fdt_blob area with garbage, that can lead to two situations: 5.1) Abort. Call to fdt_off_dt_struct() from fdt_next_tag() :: fdt_offset_ptr():: fdt_offset_ptr_() returns with garbage, that leads to tagp value being out of RAM top addr (256 Mb in our board), causing the abort: ``` Boot cmd: bootm 0x4000000#boot_evt1 bootm_run_states() <...> image_setup_libfdt() fdt_chosen() fdt_kaslrseed() uclass_get_device() uclass_get_device_tail() device_probe() device_of_to_plat() meson_rng_of_to_plat() clk_get_by_name_optional() clk_get_by_name() clk_get_by_name_nodev() ofnode_stringlist_search() fdt_stringlist_search() fdt_getprop() fdt_get_property_namelen_() fdt_first_property_offset() fdt_check_node_offset_() fdt_next_tag(): ``` tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE); ``` fdt_next_tag() tagp:0x22890766 fdt_next_tag() ram_top:0x10000000 (tagp OUT of RAM) "Synchronous Abort" handler, esr 0x96000010, far 0x22890766 elr: 000000000108be24 lr : 000000000108be24 (reloc) elr: 000000000ff6fe24 lr : 000000000ff6fe24 x0 : 0000000000000041 x1 : 0000000000000000 x2 : 000000000ff3b57c x3 : 0000000000000012 x4 : 000000000ded2ad5 x5 : 0000000000000020 x6 : 00000000ffffffe8 x7 : 000000000ded2f40 x8 : 00000000ffffffd8 x9 : 000000000000000d x10: 0000000000000006 x11: 000000000001869f x12: 000000000fffffff x13: 000000000fffffff x14: 0000000000000000 x15: 000000000ded2abb x16: 000000000ff3b080 x17: 0000000000000001 x18: 000000000ded3dc0 x19: 0000000022890766 x20: 00000000010cb0f0 x21: 00000000000015e4 x22: 000000000ff8f4d8 x23: 000000000000000b x24: 000000000ded2fbc x25: 000000000ffe2000 x22: 000000000ff8f4d8 x23: 000000000000000b x24: 000000000ded2fbc x25: 000000000ffe2000 x26: 000000000ffe2000 x27: 000000000000000b x28: 000000000ff9cf2d x29: 000000000ded2f40 Code: aa1603e1 91197484 52801742 94004de8 (b9400276) ``` 5.2) Vulnerability situation "KASLR is disabled". Almost the same as in (5.1), but 2 situations happen (depending on the value of garbage): * call to fdt_offset_ptr_() :: fdt_off_dt_struct(fdt) returns not so big garbage, leading to tagp, being inside RAM. * or calculations of absoffset inside fdt_offset_ptr() leads to failure of the one of if() conditions with NULL as retval. Result is fdt_next_tag() interprets the tagp as FDT_END. And we are returning from our callstack via functions' error paths, leading to "No RNG device" and "KASLR disabled due to lack of seed": ``` fdt_kaslrseed() uclass_get_device() <...> device_probe() device_of_to_plat() meson_rng_of_to_plat() clk_get_by_name() clk_get_by_name_nodev() <...> fdt_stringlist_search() fdt_getprop() fdt_get_property_namelen_() fdt_first_property_offset() fdt_check_node_offset_() fdt_next_tag(): ``` tagp = fdt_offset_ptr(fdt, offset, FDT_TAGSIZE); ``` fdt_next_tag() tagp:0000000001890677 fdt_next_tag() ram_top:0x10000000 (tagp is inside RAM) uclass_get_device_tail():486 device_probe() ret:-22 No RNG device Starting kernel ... [ 0.000000] Linux version 6.9.12 [ 0.000000] KASLR disabled due to lack of seed ``` Signed-off-by:
Evgeny Bachinin <EABachinin@salutedevices.com>
-
This breaks chromebook_coral which says: Video: No video mode configured in FSP! This reverts commit 2e931317. Signed-off-by:
-
A recent lwip change stopped binman's init from working, so it is not possible to read nodes from the image description anymore. Correct this by dropping the offending line. Signed-off-by:
-
- Nov 30, 2024
-
-
It doesn't make sense for a README file to be executable. Remove that bit. Signed-off-by:Rasmus Villemoes <ravi@prevas.dk>
-
It doesn't make sense for these files to have the x bit set. It was, probably accidentally, added in: Fixes: 2c494e62 (arm: dts: Stratix10: Add QSPI node) Signed-off-by:
-
The '?' that is used in the sed expression that determines MK_ARCH is part of the extended regular expression syntax, but the default behaviour of sed as specified by POSIX is to use only basic regular expression syntax. Use the equivalent '\{0,1\}' instead as suggested by the OpenBSD re_format(7) man page. Fixes: 04b1d842 ("Makefile: fix empty MK_ARCH when using ccache") Signed-off-by:Mark Kettenis <kettenis@openbsd.org> Reviewed-by:
Marek Vasut <marex@denx.de> Tested-by:
-
Commit 356011f7 ("lwip: fix code style issues") has inadvertently broken the support for the legacy syntax: => wget 192.168.0.16:test.bin invalid uri, no file path Invalid URL. Use http(s):// The reason is two calls to strncpy() were replaced by strlcpy() without paying attention to the fact that they are not equivalent in the present case. Since we are using a character counter (n) and since we do not depend on having a properly null-terminated string at each step in the parsing, strlcpy() is not justified and strncpy() is the right tool for the job. So use it again. Reported-by:
-
This reverts commit ("commit a68c9ac5 ("efi_memory: do not add U-Boot memory to the memory map"). This code was removed when the EFI subsystem started using LMB calls for the reservations. In hindsight it unearthed two problems. The e820 code is adding u-boot memory as EfiReservedMemory while it should look at what LMB added and decide instead of blindly overwriting it. The reason this worked is that we marked that code properly late, when the EFI came up. But now with the LMB changes, the EFI map gets added first and the e820 code overwrites it. The second problem is that we never mark SetVirtualAddressMap as runtime code, which we should according to the spec. Until we fix this the current hack can't go away, at least for architectures that *need* to call SVAM. More specifically x86 currently requires SVAM and sets the NX bit for pages not marked as *_CODE. So unless we do that late, it will crash trying to execute from non-executable memory. It's also worth noting that x86 calls SVAM late in the boot, so this will work until someone decides to overwrite/use BootServicesCode from the OS. Notably arm64 disables it explicitly if the VA space is > 48bits, so doesn't suffer from any of these problems. This doesn't really deserve a fixes tag, since it brings back a hack to remedy a situation that was wrong long before that commit, but in case anyone hits the same bug ... Simon sent the original revert in the link, but we need a proper justification for it. Link: https://lore.kernel.org/u-boot/20241112131830.576864-1-sjg@chromium.org/ Signed-off-by: -
https://gitlab.denx.de/u-boot/custodians/u-boot-imxTom Rini authored
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/23643 - Make DRAM coding GPIOs available before relocation on Data Modul i.MX8M Mini/Plus eDM SBC because the DRAM configuration GPIO straps must be accessible in SPL and before relocation because the GPIOs are sampled both in U-Boot SPL as well as early on in U-Boot proper. - Pick safe DRAM size on failure on Data Modul i.MX8M Mini/Plus eDM SBC instead of failing with hang() or panic(). - Replace YModem with SDP on Data Modul i.MX8M Mini eDM SBC SPL since SDP is much more flexible. - Deduplicate Data Modul i.MX8M eDM SBC defconfigs. - Perform plain boot in altbootcmd on Data Modul i.MX8M Mini/Plus eDM SBC.
-
- Nov 29, 2024
-
-
Since net_test_wget() is testing a command and is in test/cmd it should be in the 'cmd' test suite, not 'lib'. Saving and restoring the values of the environment variables that the test manipulates is necessary to avoid a regression when running the whole ut test suite. A minimal reproducer is: $ ./u-boot -T -c "ut cmd net_test_wget; ut dm dm_test_eth_act" | \ grep -E "(Test:|Failures:)" Reported-by: -
Tom Rini authored
While I had thought this commit was a cherry-pick from upstream, it is not. And so, this is not allowed here. This reverts commit dfe5f16a. Signed-off-by:
-
Marek Vasut authored
Enable PCIe/NVMe support on Data Modul i.MX8M Mini eDM SBC. Except for the configuration options which are enabled, add slight adjustment to board u-boot.dtsi, which is necessary as there is currently no driver for the I2C PCIe clock generator. Since the generator is strapped to be always on, it is possible to supplant the generator functionality by fixed-clock. Signed-off-by: -
Marek Vasut authored
The YModem support in SPL was never really used on this device, the SDP support is much more convenient on i.MX8M Mini based hardware. Replace the YModem support with SDP support. The SDP can be utilized by forcing the board into SDP boot mode by grounding test point right next to silkscreen label U30, and then by using mfgtools 'uuu -brun spl flash.bin' once the device enumerates on host system USB bus. The SDP capable USB port is available on the USB micro-B port on the base board. Signed-off-by:
Peng Fan <peng.fan@nxp.com>
-
Marek Vasut authored
Deduplicate defconfigs for all Data Modul i.MX8M eDM SBC systems by factoring out the common parts into generic imx8m_data_modul.config and including those using the #include <configs/...> preprocessor macro in the current set of board specific defconfigs. The preprocessor macro is applicable to defconfigs as well. This introduces no functional change, the resulting .config is almost identical for all Data Modul i.MX8M eDM SBC systems, except for slight alignment in DEBUG_UART and SYS_PBSIZE. Signed-off-by: -
Marek Vasut authored
The current A/B switching preparatory altbootcmd is confusing to users, replace it with plain 'run bootcmd' which can be replaced by proper A/B switching altbootcmd when the matching updater is added on top of the platform. By default, keep the boot counter incrementing, but do not do any A/B partition switching. Signed-off-by: -
Marek Vasut authored
In case gpio_request_list_by_name_nodev() in board dmo_get_memcfg() returns error code, pick a safe default DRAM configuration instead of bailing out with some sort of hang() or panic(). The BIT(2)|BIT(0) strap option is the lowest known option of 2 GiB , use that. Signed-off-by:
-
