arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma
Currently, the onboard Cypress CYUSB3304 USB hub is not defined in
the device tree, and hub reset pin is provided as vcc5v0_host
regulator to usb phy. This causes instability issues, as a result
of improper reset duration.
The fixed regulator device requests the GPIO during probe in its
inactive state (except if regulator-boot-on property is set, in
which case it is requested in the active state). Considering gpio
is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then
the regulator gets enabled (because regulator-always-on property),
which drives it to its active state, meaning driving it low.
The Cypress CYUSB3304 USB hub actually requires the reset to be
asserted for at least 5 ms, which we cannot guarantee right now
since there's no delay in the current config, meaning the hub may
sometimes work or not. We could add delay as offered by
fixed-regulator but let's rather fix this by using the proper way
to model onboard USB hubs.
Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub
consist of two 'logical' hubs, for USB2.0 and USB3.0.
Use the 'reset-gpios' property of hub to assign reset pin instead
of using regulator. Rename the vcc5v0_host regulator to
cy3304_reset to be more meaningful. Pin is configured to
output-high by default, which sets the hub in reset state
during pin controller initialization. This allows to avoid double
enumeration of devices in case the bootloader has setup the USB
hub before the kernel.
The vdd-supply and vdd2-supply properties in hub nodes are
added to provide correct dt-bindings, although power supplies are
always enabled based on HW design.
Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable@vger.kernel.org # 6.6 Cc: stable@vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thaumatec.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: d7cc532df95f7f159e40595440e4e4b99481457b ]
dt-bindings: usb: cypress,hx3: Add support for all variants
The Cypress HX3 hubs use different default PID value depending
on the variant. Update compatibles list.
Becasuse all hub variants use the same driver data, allow the
dt node to have two compatibles: leftmost which matches the HW
exactly, and the second one as fallback.
Fixes: 1eca51f58a10 ("dt-bindings: usb: Add binding for Cypress HX3 USB 3.0 family") Cc: stable@vger.kernel.org # 6.6 Cc: stable@vger.kernel.org # Backport of the patch ("dt-bindings: usb: usb-device: relax compatible pattern to a contains") from list: https://lore.kernel.org/linux-usb/20250418-dt-binding-usb-device-compatibles-v2-1-b3029f14e800@cherry.de/ Cc: stable@vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-2-4a76a474a010@thaumatec.com
[taken with Greg's blessing] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 1ad4b5a7de16806afc1aeaf012337e62af04e001 ]
dt-bindings: usb: usb-device: relax compatible pattern to a contains
The dt-core typically allows multiple compatibles[1] but usb-device
currently forces a single compatible.
This is an issue when multiple devices with slightly different productID
all behave the same. This would require the driver to keep updating its
compatible matching table to include this new productID instead of doing
what is usually done: have two compatibles, the leftmost which matches
exactly the HW device definition, and the rightmost one as a fallback
which is assumed to be 100% compatible with the device at hand. If this
assumption turns out to be wrong, it is easy to work around this without
having to modify the device tree by handling the leftmost compatible in the driver.
configs: puma-rk3399: enable onboard USB hub support
Since commit
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/?id=0fe42d171081426ab119ca5c0eb130e5f3a9a805
RK3399 Puma now models the onboard USB hub properly via onboard USB hub
device nodes with appropriate reset and power supplies instead of
hacking things around (a hack that didn't even work reliably).
This means this driver needs to be enabled in U-Boot as well otherwise
USB will stop working at all.
usb: onboard-hub: Add support for Cypress HX3 family
The HX3 is a family of USB3.0 hub controllers that comes in
different variants: CYUSB330x/CYUSB331x/CYUSB332x/CYUSB230x.
To support this hub, controlling of reset pin and two
power supplies is required.
The reset time is set to 10ms, based on the datasheet [1].
Power-on delay time is not required, so it is set to 0.
The compatible strings added to of_match table are
compliant with usb/cypress,hx3.yaml bindings.
usb: onboard-hub: Add support for multiple power supplies
Some of the onboard hubs require multiple power supplies, so extend
the driver to support them.
The implementation is inspired by the kernel driver, as introduced
by commit [1] in the v6.10 kernel.
usb: onboard-hub: Set the reset gpio pin before freeing
In the usb_onboard_hub_remove, the reset gpio, if available, is
freed. The pin state however, remains unchanged, as set in the
usb_onboard_hub_reset. The hub is then left enabled.
During second onboard hub probing, the hub is initially enabled
(reset pin in state "0"), and then it is being reset by the reset
function (transition to "1" and then to "0"). Because of this,
the hub first disconnects from root hub, and then it connects again.
When the devices are being discovered in the usb_scan_port in the
usb_hub driver, initially there is the USB_PORT_STAT_CONNECTION bit
not set in portstatus, but USB_PORT_STAT_C_CONNECTION set in
portchange data (which is because disconnect event occurred first).
In this condition, the driver does not wait for devices to appear.
This can cause the hub (and all child devices) to be not enumerated
when rescanning on "usb reset" command.
To fix this, set the reset gpio to active in usb_onboard_hub_remove,
to put the hub into reset state.
However, in case the hub reset pin is by default held in high
state by HW before U-Boot takes over, in which case the USB hub is
active, then during the first probe it gets reset and we might get
into the same issue of the hub being not enumerated.
usb: onboard-hub: Use devm API do automatically free the reset GPIO
The reset GPIO is obtained during driver probing by the function
devm_gpiod_get_optional, which means the GPIO will be automatically
freed when the device is removed. Because of this, explicit call
to free the reset GPIO in hub remove function is not needed.
To support the Managed device resources, the DEVRES config must
be enabled, otherwise the devres functions fall back to non-managed
variants. Set the necessary dependency to DEVRES in Kconfig.
usb: onboard-hub: Use the ofnode to check if the peer-hub was probed
Currently the check in usb_onboard_hub_bind is relying on specific
compatible string for the Michrochip USB5744. Replace this with
more generic approach that will allow to add new types of devices
to the of_match table. Because the driver only needs to bind one
"half" of the hub, the peer-hub node is used to find out if it
was already done. In case peer-hub was bound, -ENODEV is returned.
Tom Rini [Sat, 7 Jun 2025 14:18:54 +0000 (08:18 -0600)]
Merge tag 'doc-2025-07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request doc-2025-07-rc4
Documentation:
* fix typo in gcc.rst
* correct EFI_TCG2_PROTOCOL_MEASURE_DTB description
* Add missing reference to firmware for BB-AI64
* Tidy up the bootefi-command docs
Peter Robinson [Sun, 25 May 2025 12:10:58 +0000 (13:10 +0100)]
doc: board: ti: Add missing firmware for BB-AI64
The details of the sysfw.itb from the R5 build that
also needs to be copied as part of the target images
is missing, but is included in the image formats a
little further down, so add it to the instructions.
%s/data that change/data that changes/
%s/cannot be used has/cannot be used for/
%s/Otherwise/Otherwise,/
%s/allows better measurement/allows for better measurement/
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Andrew Davis [Thu, 22 May 2025 16:40:13 +0000 (11:40 -0500)]
board: ti: am62ax: env: Use default MMC related args
There are common MMC args for TI plats in include/environment/ti/mmc.env.
Since we already include this, there is no need to redefine these
MMC vars. Use the defaults.
This seems like something that could have been done while refactoring
these vars in the first place as it happened after this AM62A file
was available hence the fixes tag.
Reported-by: Chirag Shilwant <c-shilwant@ti.com> Fixes: 3709b529156e ("env: ti: mmc.env: Move mmc related args to common place") Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Acked-by: Chirag Shilwant <c-shilwant@ti.com> Reviewed-by: Judith Mendez <jm@ti.com>
usb: onboard-hub: Fix return type for regulator APIs
Apart from ENOENT observing return value as ENOSYS when
!DM_REGULATOR that's why cover both configurations.
Changed code is not working as operation should be "&&"
not "||" (ret != -ENOENT && ret != -ENOSYS).
Also fix the remove function where the regulator_set_enable_if_allowed()
function is returning an error.
Tom Rini [Tue, 3 Jun 2025 15:00:52 +0000 (09:00 -0600)]
Merge tag 'qcom-more-for-2025.07' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon
More Qualcomm fixes for 2025.07
* Adjust fdtfile logic to support more boards
* Support linux,code variable in qcom-pmic button driver
* Minor CLK API adjustments and apq8096/msm8916 fixes
* vbus regulator register fixes
* dragonboard410c KASLR support and other fixes
Sumit Garg [Mon, 5 May 2025 12:43:33 +0000 (18:13 +0530)]
mach-snapdragon: Update fdtfile logic to work for RB1 and RB2
RB1 and RB2 have three root compatibles where the last one can't be used
to decode fdtfile name (qcm* vs qrb*). So rather just rely on the first
compatible to retrieve the SoC name.
button: qcom-pmic: allow to specify code in devicetree
Most device vendors put "Volume Down" button onto PMIC RESIN.
But Sony is special: see
dts/upstream/src/arm64/qcom/sdm630-sony-xperia-nile.dtsi or [1].
They put "Volume Down" on PMIC GPIO 7 where others usually put
"Volume Up", and KEY_VOLUMEUP is inside &pon_resin.
Currently if you boot U-Boot on such Sony device, you end up
with 2 "Volume Down" buttons, and no "Volume Up", which makes
navigating menu problematic.
Support reading devicetree "linux,code" property and override
statically defined button code & label based on that.
Stephan Gerhold [Thu, 24 Apr 2025 09:16:46 +0000 (11:16 +0200)]
clk: qcom: apq8016: Fix SDCC clock warnings
As of commit dc8754e8e408 ("clk/qcom: apq8016: improve clk_enable logging")
there are now warnings in the U-Boot console on DragonBoard 410c:
apq8016_clk_enable: unknown clk id 122
apq8016_clk_enable: unknown clk id 123
apq8016_clk_enable: unknown clk id 124
apq8016_clk_enable: unknown clk id 125
This is because we don't implement enable() properly for the SDCC clocks.
Currently they are being enabled as part of set_rate().
Fix this by moving the enable calls out of the apq8016_clk_init_sdc()
function and convert them to the equivalent GATE_CLK_POLLED() definitions.
Stephan Gerhold [Thu, 24 Apr 2025 09:16:44 +0000 (11:16 +0200)]
clk: qcom: Allow polling for clock status in qcom_gate_clk_en()
GATE_CLK() in its current state is unsafe: A simple write to the clock
enable register does not guarantee that the clock is immediately running.
Without polling the clock status, we may issue writes to registers before
the necessary clocks start running. This doesn't seem to cause issues in
U-Boot at the moment, but for example removing the CLK_OFF polling in TF-A
for the SMMU clocks on DB410c reliably triggers an exception during boot.
Make it possible to poll the branch clock status register, by adding a new
GATE_CLK_POLLED() macro that takes the extra register address. Existing
usages work just as before, without polling the clock status. Ideally all
usages should be updated to specify the correct poll address in the future.
The Qualcomm naming for these clocks is "branch" and not "gate", but let's
keep the existing naming for now to avoid confusion until all others
drivers have been converted.
Stephan Gerhold [Thu, 24 Apr 2025 09:16:43 +0000 (11:16 +0200)]
clk: qcom: Use setbits_le32() for qcom_gate_clk_en()
The other clock enable functions in clock-qcom.c use setbits_le32() to
read/modify/write the enable registers. Use the same for qcom_gate_clk_en()
to simplify the code a bit.
Stephan Gerhold [Thu, 24 Apr 2025 09:16:41 +0000 (11:16 +0200)]
clk: qcom: apq8016: Fix SDCC clock addresses
The SDCC_...(n) macros in clock-apq8016.c result in the wrong addresses:
- SDCC1: SDCC_APPS_CBCR(0) = ((0 * 0x1000) + 0x41018) = 0x41018
Should be 0x42018, this is an invalid register close to the USB clocks.
- SDCC2: SDCC_APPS_CBCR(1) = ((1 * 0x1000) + 0x41018) = 0x42018
Should be 0x43018, this is the SDCC1 clock.
When we try to enable SDCC2, we actually end up enabling SDCC1. When we try
to enable SDCC1, we just issue some broken register writes.
This hasn't caused any trouble so far, because the boot firmware is keeping
both SDCC clocks running. However, if these clocks are disabled when
entering U-Boot, MMC initialization is failing.
Fix this by using the proper offset for the macros. The SDCC_CMD_RCGR() was
already correct, but change it the same way for consistency.
Fixes: 085921368b7d ("arm: Add support for Qualcomm Snapdragon family") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Casey Connolly <casey.connolly@linaro.org> Link: https://lore.kernel.org/r/20250424-apq8016-clock-fixes2-v2-1-fcc371c9e45f@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Stephan Gerhold [Thu, 17 Apr 2025 13:49:12 +0000 (15:49 +0200)]
board: dragonboard410c: Drop custom reduced malloc size
At the moment, the dragonboard410c_defconfig specifies a custom
SYS_MALLOC_LEN, lower than the default for Qualcomm boards defined in
arch/arm/mach-snapdragon/Kconfig. It looks like it's too low, since
flashing larger sparse partition images using Fastboot fails with:
Stephan Gerhold [Thu, 17 Apr 2025 13:49:11 +0000 (15:49 +0200)]
board: dragonboard410c: Fix button cmd name
Commit 359e1d4a57e0 ("board: dragonboard410c: Use button_cmd instead of
custom code") was made in parallel with commit 8f5685d5d32f ("button:
qcom-pmic: prettify and standardise button labels"), which changed the
default button label from "vol_down" to "Volume Down". This is causing
errors in the console during boot now:
No button labelled 'vol_down'
Fix this by using the new label.
Fixes: 359e1d4a57e0 ("board: dragonboard410c: Use button_cmd instead of custom code") Fixes: 8f5685d5d32f ("button: qcom-pmic: prettify and standardise button labels") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250417-db410c-fixes2-v1-1-76ad994da152@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Tom Rini [Mon, 2 Jun 2025 14:42:04 +0000 (08:42 -0600)]
Merge tag 'i2cfixes-for-2025.07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-i2c
i2c bugfixes for v2025.07-rc4
- designware_i2c: fix globally wrong return value -1 into -ETIMEDOUT
in driver, which leaded in silent errors as a timeout resulted in
an uninitialized value being returned, potentially causing
unexpected behavior.
i2c: designware_i2c Return -ETIMEDOUT for timeout errors
Change the return value for timeout errors in i2c-designware from 1 to
-ETIMEDOUT. Returning errors as negative values is standard practice in the
u-boot, which enhances error handling consistency across the codebase.
The current behavior can lead to silent errors when functions check for
negative return values to identify errors. For example, in
`dm_i2c_reg_read` from i2c-uclass.c, a timeout results in an uninitialized
value being returned, potentially causing unexpected behavior.
Cc: Heiko Schocher <hs@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Wojciech Szamocki <wojciech.szamocki@nokia.com> Signed-off-by: Wojciech Szamocki <wojciech.szamocki@nokia.com> Reviewed-by: Heiko Schocher <hs@denx.de>
Martin Kaistra [Tue, 15 Apr 2025 15:04:00 +0000 (17:04 +0200)]
net: gem: ignore tx_clk if MII is used
If the MII interface is used, the PHY is the clock master, thus don't
set the clock rate. On Zynq-7000, this will prevent the following
error:
zynq_gem ethernet@e000b000: failed to set tx clock rate 25000000
phy: zynqmp: Fix sgmii clk ctrl GTR lane bit shift
The bitshift in GEM_CLK_CTRL register is five bits, not two. There are
four bits for each GEM, and one bit reserved in between.
This has caused that using more than one GEM is impossible,
additionally corrupting the GEM0's configuration, leaving GEM0
unusable as well (ie. if GEM0 and GEM1 are used, GEM1 configuration is
going to write to GEM0's registers wrong value, leaving GEM0 unusable)
drivers: fpga: intel_sdm_mb: Flush cache before FPGA configuration
FPGA configuration encounters failure when the cache is not flushed.
Add cache flushing to the memory region that holds the FPGA
configuration bitstream.
The pcireg base is not assigned to any address, reading the
pcireg base with PS_LINKUP_OFFSET which is incorrect and
giving random values. So update the pcireg base from
devicetree so that we can read the valid PCIE link status
and PHY ready status.
Eddie Kovsky [Wed, 21 May 2025 21:26:59 +0000 (15:26 -0600)]
image: android: fix ramdisk default address
Commit 21e7fa0e3ac5 ("image: android: handle ramdisk default address")
changed the default behavior for header versions less than or equal to 2.
The ramdisk address (img_data.ramdisk_ptr) is only assigned to *rd_data
if the physical load address (img_data.ramdisk_addr) is equal to 0 or
the Android default ramdisk address.
/* Ramdisk can be used in-place, use current ptr */
if (img_data.ramdisk_addr == 0 ||
img_data.ramdisk_addr == ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR) {
*rd_data = img_data.ramdisk_ptr;
} else {
ramdisk_ptr = img_data.ramdisk_addr;
*rd_data = ramdisk_ptr;
memcpy((void *)(ramdisk_ptr), (void *)img_data.ramdisk_ptr,
img_data.ramdisk_size);
}
When the img_data.ramdisk_addr and the img_data.kernel_addr are the same
*rd_data needs to be assigned to the ramdisk address (ramdisk_ptr), not
the physical address (ramdisk_addr).
As a result of the current behavior, we can no longer boot a kernel on
the Renesas R-Car S4 board.
Add an additional check to the if clause so that the ramdisk address is
assigned when the kernel address and the ramdisk address are the same,
restoring the previous default behavior.
Benjamin ROBIN [Tue, 20 May 2025 20:35:15 +0000 (22:35 +0200)]
bootm: Fix bmi->images pointer not initialized in some cases
When building with only bootz command, without bootm, images pointer
inside bootm_info structure is not initialized. And since this structure
is stored in stack, the generated error is kind of random, but most of
the time this will generate: "ramdisk - allocation error".
Also, after analysis, this problem could occur with the command booti,
if the command bootm is disabled.
Currently bootm_init() is called by: do_bootz(), do_bootm(), do_booti()
and by do_stm32prog(). And all of these commands execute bootm_run_states()
which access the images pointer stored into bootm_info structure.
So, to fix this issue, just do the assignment unconditionally.
Fixes: c2211ff65136 ("bootm: Add more fields to bootm_info") Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
Benjamin ROBIN [Sat, 17 May 2025 20:09:30 +0000 (22:09 +0200)]
env: Fix network support when CONFIG_NET_LWIP is set
When lwIP (CONFIG_NET_LWIP) is used instead of legacy stack (CONFIG_NET),
environment flags support associated with network was not built: restore
support of "i" and "m" environment flags.
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr> Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Marek Vasut [Sun, 2 Mar 2025 18:30:28 +0000 (19:30 +0100)]
scripts/setlocalversion: Reinstate .scmversion support
The .scmversion is used by oe-core to append U-Boot version string.
LOCALVERSION is not fully compatible replacement as it adds trailing
"-dirty" string at the end of version string in case the U-Boot git
tree contains uncommitted changes. This behavior itself is correct.
However, OE builds do clone U-Boot sources from git and may apply
additional patches on top, which are not tracked in U-Boot git tree,
but rather in the OE metalayer git tree, which leads to the addition
of "-dirty" string as well.
The .scmversion used by oe-core used to replace the version string
suffix fully, including the "-dirty" string. Reinstate support for
the .scmversion to let OE core do exactly that as it used to do it.
Fixes: 5c02350fa03d ("scripts/setlocalversion: sync with linux v6.9") Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Sun, 13 Apr 2025 13:10:45 +0000 (15:10 +0200)]
ARM: renesas: Enable serial RX buffer on Renesas R-Car
Enable CONFIG_SERIAL_RX_BUFFER on all Renesas R-Car devices which
use the SCIF serial port. This allows receiving large strings at
bulk even if the RX FIFO is small and would otherwise overflow.
The usual trigger for the problem addressed here is a paste of a
very long command into U-Boot command line, somewhere between 400
and 500 characters long. The trailing end of the string is usually
not received and the command line input stops responding due to RX
overflow errors. The CONFIG_SERIAL_RX_BUFFER allows efficient read
of data from the RX FIFO, which prevents the overflow, and allows
safe reception of long pasted strings.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The issue here is that the function read_allocated_block() will report
problems via a negative return value. If we say the return value is
stored in an lbaint_t that can no longer happen (and Coverity discovered
this by reporting a no effect comparison and then dead code). The
problem being fixed by allowing for storing a larger block number will
have to be solved in some other manner.
* run dhcp if an http boot option is selected
* separate device path into its own header and add it to the API docs
* rename END to EFI_DP_END
* make x86 SMBIOS tables usable in the EFI context
Tom Rini [Sat, 15 Mar 2025 01:27:36 +0000 (19:27 -0600)]
usb: ulpi: Clean up how we enable support
The way we enable ULPI support today isn't something that should work.
The "optional" keyword in a choice statement is not a documented
feature. To make this work in a supported way, make USB_ULPI something
we ask about if USB_HOST is set. Next, we move the choice of what
viewer to use to be after the framework portion and to depend on that.
We then borrow a few words from the top-level README to make the help
text here clearer. Finally we make the Qualcomm driver select ULPI as
it's required and we make the tegra driver not duplicate a check that
Kconfig now handles for us.
dwc3_core_init loops 'timeout' times to check if the IP block is out
of reset using 'while (timeout--)'. If there is some issue and
the block doesn't come out of reset, the loop will run till
'timeout' becomes zero and the post decrement operator would set
timeout to 0xffffffff. Though the IP block is not out reset, the
subsequent if check 'if !timeout' would fail as timeout is not
equal to zero and the function proceeds with the initialization.
Ilias Apalodimas [Fri, 23 May 2025 13:04:04 +0000 (16:04 +0300)]
efi_loader: Run dhcp if an http boot option is selected
The EFI boot manager relies on having an IP address before trying to
boot an EFI HTTP(s) boot entry. However, defining it as a boot or
pre-boot command is not always the right answer since it will
unconditionally add delay to the board boot, even if we don't boot
over the network.
So let's do a DHCP request from the boot manager, if 'ipaddr' is
empty and fail early if we don't have an address.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Simon Glass [Fri, 23 May 2025 16:55:04 +0000 (17:55 +0100)]
x86: efi_loader: Ensure the SMBIOS tables are sent via EFI
The EFI-loader code has not been fully converted to use bloblist, so
relies on the SMBIOS-table address being set in global_data.
Set this up in write_tables() so that the SMBIOS tables are actually
available.
Enable the command for x86 QEMU so that the SMBIOS tests actually run.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 83ce35d6ebb ("emulation: Use bloblist to hold tables") Reported-by: Niklas Sombert <niklas.sombert@uni-duesseldorf.de> Tested-by: Niklas Sombert <niklas.sombert@uni-duesseldorf.de> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Simon Glass [Sat, 24 May 2025 17:28:23 +0000 (11:28 -0600)]
efi: Rename END to EFI_DP_END
This exported symbol has a very generic name. Rename it to indicate that
it relates to EFI and device-paths.
Fix checkpatch warnings related to use of multiple assignments.
Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Simon Glass [Sat, 24 May 2025 17:28:21 +0000 (11:28 -0600)]
efi_loader: Separate device path into its own header
These functions are useful for the EFI app. As a first step towards
making these available outside lib/efi_loader, create a separate header
file and include it where needed. Add proper comments to the functions,
since many are missing at present.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tony Dinh [Fri, 23 May 2025 05:02:01 +0000 (22:02 -0700)]
ext4fs: Fix: Read outside partition error
Use lbaint_t for blknr to avoid overflow in ext4fs_read_file().
Background:
blknr (block number) used in ext4fs_read_file() could be increased to a
very large value and causes a wrap around at 32 bit signed integer max,
thus becomes negative. This results in an out-of-normal range for sector
number (during the assignment delayed_start = blknr) where delayed_start
sector is typed uint64 lbaint_t. This causes the "Read outside partition"
error.
This patch was tested on the Synology DS116 (Armada 385) board, and a
4TB Seagate HDD.
Weijie Gao [Tue, 6 May 2025 07:15:01 +0000 (15:15 +0800)]
env: mtd: fix usability with NAND flashes
1. As this is for MTD-based devices, the Kconfig dependency should be MTD
instead of only spi-nor flashes
2. Initialize saved_buf to avoid crash on free()
3. Remaining size should be set correctly to write_size
Fixes: 03fb08d4aef (env: Introduce support for MTD) Signed-off-by: Weijie Gao <weijie.gao@mediatek.com> Reviewed-by: Christian Marangi <ansuelsmth@gmail.com>
Olaf Baehring [Wed, 21 May 2025 11:03:40 +0000 (08:03 -0300)]
caam: Fix CAAM error on startup
In rare cases U-Boot returns an error message when intantiating the RNG
of the CAAM device:
“SEC0: RNG4 SH0 instantiation failed with error 0xffffffff”
This means, that even when the CAAM device reports a finished
descriptor, none is found in the output ring.
This might be caused by a missing cache invalidation before
reading the memory of the output ring
This patch moves the cache invalidation of the output ring from start of
the job to immediately after the notification from hardware where the
output ring will be read.
Signed-off-by: Olaf Baehring <olaf.baehring@draeger.com> Signed-off-by: Fabio Estevam <festevam@gmail.com>
- Initial SPL support for T-Head TH1520 SoC
- Improve usability of TH1520 with mainline SPL
- Support building RV32 & RV64 images
- riscv: Improve jh7110 support
Michael Bode [Wed, 21 May 2025 09:47:32 +0000 (11:47 +0200)]
board: bsh: imx6ulz_smm_m2: Add delay between DRAM read access
A small delay between DRAM read access with wrong parameters and
reconfiguration is necessary.
Without a delay between DRAM read access and a following reconfiguration
this reconfiguration fails for certain DRAM chips (Nanya).
Signed-off-by: Michael Bode <michael.bode@bshg.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
The commit dda454e933c6 ("serial: mxc: Support bulk enabling clocks")
breaks the booting of the BSH SMM S2 board. The analysis of the issue
revealed memory allocation failures during the registration of UART4
clocks as well as other peripherals. Increasing SYS_MALLOC_F_LEN to
0x10000 fixed the issue.
Dropping this option allows it to be set to the default value of
CONFIG_SYS_MALLOC_F_LEN, which is set by default to 0x10000 on
i.MX8M platforms.
Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Dario Binacchi [Tue, 20 May 2025 08:54:18 +0000 (10:54 +0200)]
configs: imx8mn_bsh_smm_s2: load U-Boot from raw NAND
Commit 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") breaks
the boot of the BSH SMM S2 board. Add options to load U-Boot from raw NAND
sector.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Dario Binacchi [Tue, 20 May 2025 08:54:17 +0000 (10:54 +0200)]
imx: spl_imx_romapi: support raw NAND sector
Commit 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") breaks
the boot of the BSH SMM S2 board. As stated in the dropped comment, "Some
boards use this value even though MMC is not enabled in SPL, for example
imx8mn_bsh_smm_s2".
Support load of the U-Boot image from raw NAND sector.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Dario Binacchi [Tue, 20 May 2025 08:54:16 +0000 (10:54 +0200)]
spl: Kconfig: support U-Boot load from raw NAND
Commit 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") breaks
the boot of the BSH SMM S2 board. As stated in the commit itself, "Some
boards use this value even though MMC is not enabled in SPL, for example
imx8mn_bsh_smm_s2".
Support load of the U-Boot image from raw NAND sector. This is equivalent
to load from MMC raw sector.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
arm: dts: imx6ulz-bsh-smm-m2: Fix reset using wdt-reboot driver
commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()")
introduced a regression that 'reset' command unable to reset
imx6ulz based BSH module's modules in the u-boot.
The function arch_spl_mmc_get_uboot_raw_sector() was never compiled,
even when the option CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION was
enabled. So rename the macro SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION to
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION.
Fixes: 2a00d73d081a ("spl: mmc: Try to clean up raw-mode options") Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Yao Zi [Fri, 16 May 2025 03:05:25 +0000 (03:05 +0000)]
riscv: dts: th1520: Complete clock tree
Describe the newly-supported clock controller of TH1520 in SoC
devicetree, replace dummy clocks with the controller-supplied ones and
add correct clocks for GPIO controllers.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Fri, 16 May 2025 03:05:23 +0000 (03:05 +0000)]
clk: thead: Port clock controller driver of TH1520 SoC
The driver is adapted from Linux kernel's version of clk-th1520-ap.c,
with only output clocks for external sensors, which are barely useful in
bootloaders, removed.
Same as the mainline driver, it currently lacks of ability to enable and
reconfigure PLLs, which could be implemented later.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Fri, 16 May 2025 03:05:22 +0000 (03:05 +0000)]
riscv: cpu: th1520: Initialize IOPMPs in SPL
TH1520 SoC ships several IOPMPs protecting various on-chip peripherals.
They must be configured before accessing the peripherals. Let's
initialize them in SPL harts_early_init().
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Tue, 13 May 2025 09:05:02 +0000 (09:05 +0000)]
board: thead: licheepi4a: Enable SPL support
Adjust Kconfig and defconfig and add SPL initialization code for
Lichee Pi 4A. Then enable SPL support which we've added for TH1520 SoC
earlier. The board devicetree is changed to use TH1520 binman
configuration to generate bootable images.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Tue, 13 May 2025 09:05:01 +0000 (09:05 +0000)]
riscv: dts: th1520: Add binman configuration
Add binman configuration for TH1520 SoC, whose BROM loads the image
combined into SRAM and directly jumps to it. The configuration creates
u-boot-with-spl.bin where the SPL code locates at the start and the DDR
firmware is shipped.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
projects / thirdparty / u-boot.git / log
