This commit introduces a new API,
request_firmware_into_buf_via_script(), to the fs_loader framework.
This function allows firmware to be loaded into memory using
a user-defined U-Boot script, providing greater flexibility for
firmware loading scenarios that cannot be handled by static file
paths or device/partition selection alone.
Key features:
- The API runs a specified U-Boot script (by name), which is responsible
for loading the firmware into memory by any means (e.g., load from MMC, USB, network, etc.).
- The script must set two environment variables: 'fw_addr'
(the memory address where the firmware is loaded) and
'fw_size' (the size of the firmware in bytes).
- The function validates these variables, copies the firmware into a newly
allocated buffer (using memdup), and returns the pointer
via the provided double pointer argument.
- The maximum allowed firmware size is checked to prevent buffer overflows.
- The environment variables are cleared after use to avoid stale data.
- Detailed error messages are provided for all failure conditions to aid debugging.
Usage example:
1. Define a U-Boot script in the environment that loads the firmware
and sets the required variables:
=> env set my_fw_script 'load mmc 0:1 ${loadaddr} firmware.bin &&
env set fw_addr ${loadaddr} && env set fw_size ${filesize}'
2. In your code, call the new API:
void *fw_buf = NULL;
int ret = request_firmware_into_buf_via_script(&fw_buf, 0x46000000, "my_fw_script");
if (ret < 0)
return ret;
This approach allows board integrators and users to customize the firmware
loading process without modifying the source code,
simply by changing the script in the U-Boot environment.
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[trini: Fix printf of size_t needing to use %zx]
Signed-off-by: Tom Rini <trini@konsulko.com>
Configure RMMI and M-PHY registers for HS mode required for selection of
bit rate series A or B. If it is not a calibrated part, then switch back
to SLOWAUTO_MODE and skip all these configurations.
Implemented below sequence as per the DWC RMMI databook.
1. Override RMMI CBRATESEL with the desired rate.
2. Set TX_CFGUPDT_0 to 1'b1 for one TX_CFGCLK_0 cycle.
3. Override PHY rx_req to 1, then poll on PHY rx_ack register till it
goes 1(both lanes).
4. Override PHY rx_req to 0, then poll on PHY rx_ack register till it
goes 0(both lanes).
5. Remove PHY rx_req override(both lanes).
6. Start the LS PMC.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250724044402.260149-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The existing compatible name for U-Boot's k3 system controller driver
i.e "ti,am625-system-controller" has been added to linux[1] device-tree.
This compatible in kernel is meant for configuring the Control Module
registers (CTRL_MMR0).
However in U-Boot, the matching driver was being used to load the system
firmware on the secure M-cores by the R5 SPL and therefore must be
updated to a different compatible to avoid conflicts.
Therefore, this patch renames all references of the compatible to
"ti,am654-tisci-rproc-r5". The "-r5" is appended so as to avoid any
future conflicts since r5 specific compatibles should only be useful for
U-Boot.
[1]: 5959618631fe ("dt-bindings: mfd: ti,j721e-system-controller: Add compatible string for AM654")
https://lore.kernel.org/r/20250421214620.3770172-2-afd@ti.com
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Avoid unlimited while loop by adding a timeout. The timeout is
calculated based on a minimal throughput of 256 KB/s.
The timeout is set at least to 2 seconds.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
File system such as YAFFS2 need to know the number of available
OOB bytes per page to be able to choose if they should locate their
metadata in the data area or in the spare area.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In zynqmp_pinconf_set if param is PIN_CFG_IOSTANDARD or
PIN_CONFIG_POWER_SOURCE and zynqmp_pm_pinctrl_get_config returns an
error then value will not be assigned to when its value is tested to be
not equal to arg. Add code to only test value not equal to arg if ret is
false.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Link: https://lore.kernel.org/r/20250807-pinctrl_misc-v1-4-eeb564a1b032@linaro.org
Signed-off-by: Michal Simek <michal.simek@amd.com>
tpm_tis_i2c_get_burstcount returns a size_t but also returns -EBUSY if
the TPM is surrently busy. As size_t is an unsigned type simply testing
for < 0 will not work so change the test for being equal to -EBUSY which
will work. Also remove the trivial comments.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When printing the contents of an size_t variable we need to use z prefix
to the format character in order to get the correct format type
depending on 32 or 64bit-ness.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When printing the contents of an size_t variable we need to use z prefix
to the format character in order to get the correct format type
depending on 32 or 64bit-ness.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Use GUSBCFG_FORCEHOSTMODE to detected the HOST forced mode as it is done
in the Linux driver drivers/usb/dwc2/core.c:dwc2_core_reset().
The host polling must be executed only if the current mode is host,
either due to the force HOST mode (which persists after core reset)
or the connector id pin.
The GUSBCFG_FORCEDEVMODE bits is used to force the device mode (for
example used on STM32MP1x platform) and when it is activated the DWC2 reset
failed with the trace:
"dwc2_core_reset: Waiting for GINTSTS_CURMODE_HOST timeout"
Fixes: c5d685b899 ("usb: dwc2: Unify flush and reset logic with v4.20a support")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Junhui Liu <junhui.liu@pigmoral.tech>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
When the usb node is defined dr_mode="otg" ehci_usb_phy_mode() is called
to determine the mode from status registers.
The IMX95RM does not currently define the USBNC STATUS register but it is
assumed to be an omission as the first three registers are defined.
It has been expirimentally verified that the USBNC_PHY_STATUS register
at offset 0x23C bit4 (USBNC_PHYSTATUS_ID_DIG) reads 0 when USB_ID is GND
and 1 when floating.
Use is_imx9() as this driver works for i.MX91, i.MX93 and i.MX95 and all
of these determine the role based on the USBNC_PHY_STATUS register.
Fixes: 801b5fafd3 "(usb: ehci-mx6: Add i.MX95 support")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Add initial support for i.MX95 USB.30 PHY, which is similar to
the i.MX8MQ and i.MX8MP USB PHY.
The i.MX95 USB3 PHY has a Type-C Assist block (TCA) consisting of two
functional blocks (XBar assist and VBus assist) and is documented
in the i.MX95 RM Chapter 163.3.8 Type-C assist (TCA) block.
Instead of relying on an external MUX for Type-C plug orientation the
XBar can handle the flip internally.
Add initial support for i.MX95 by:
- allowing the driver to be enabled i.MX95
- resetting the XBar
- configuring the TCA in System Configuration mode (which was determined
to be necessary to enable the PHY in device-mode)
Follow-on support will need to be added to steer the XBar based on
either board design (if only one pair is brought out) or if used with a
Type-C controller.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Tested-by: Alice Guo <alice.guo@nxp.com>
In nanddev_init mtd and memorg are assigned values that dereference nand
but this happens before a NULL check for nand. Move the assignments
after the NULL check.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
The driver currently does:
mtd->dev->parent = cadence->dev;
This works in Linux because `struct mtd_info` embeds a `struct device`,
so `mtd->dev` is always valid and its `.parent` can be set.
In U-Boot, however, `mtd->dev` is only a pointer to a `struct udevice`.
Dereferencing it before assignment is invalid, which breaks the device
hierarchy. As a result, consumers relying on `mtd->dev` (e.g. partition
parser, reset and re-init paths) operate on a dangling pointer. This
leads to failures during warm reset when the NAND device is accessed
again.
Fix by assigning the device pointer directly:
mtd->dev = cadence->dev;
This matches U-Boot’s device model, preserves a valid hierarchy, and
resolves the warm reset issue on Cadence NAND.
Fixes: ebc41cad ("drivers: mtd: nand: Add driver for Cadence Nand")
Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
The clk and clk_id members of struct omap_i2c are not used anywhere,
and AFAICT never have been.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>
The existing compatible name for U-Boot's k3 system controller driver
i.e "ti,am625-system-controller" has been added to linux[1] device-tree.
This compatible in kernel is meant for configuring the Control Module
registers (CTRL_MMR0).
However in U-Boot, the matching driver was being used to load the system
firmware on the secure M-cores by the R5 SPL and therefore must be
updated to a different compatible to avoid conflicts.
Therefore, this patch renames all references of the compatible to
"ti,am654-tisci-rproc-r5". The "-r5" is appended so as to avoid any
future conflicts since r5 specific compatibles should only be useful for
U-Boot.
[1]: 5959618631fe ("dt-bindings: mfd: ti,j721e-system-controller: Add compatible string for AM654")
https://lore.kernel.org/r/20250421214620.3770172-2-afd@ti.com
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Add early boot support for AM64 single cpu mode configuration.
In single CPU mode the 2nd core of the R5F cluster can't be used or
unavailable.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
serial_find_console_or_panic() may left cur_serial_dev unassigned if
REQUIRE_SERIAL_CONSOLE is not set. Setting GD_FLG_SERIAL_READY in
this situation confuses serial console code. It tries to use
unassigned driver instead of debug port and stops printing.
So check cur_serial_dev before setting GD_FLG_SERIAL_READY to allow
console to keep printing via debug port.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
In maxim_i2c_read the code mistakenly just returned the return value
from dm_i2c_read leaving the following code unreachable. Instead assign
ret to be the return value from dm_i2c_read so that the following code
can operate as expected.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
In dbsc5_read_vref_training the arrays dvw_min_byte0_table and
dvw_min_byte1_table have 128 elements per channel. The variable
vref_stop_index is limited to be a maximum of 128. This means that the
index used to access the arrays must use a test of '< vref_stop_index'
rather than '<= vref_stop_index' in order to prevent out of bounds
accesses to the arrays.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
TI's Ethernet switch needs system controllers enabled in R5SPL stage while
booting via Ethernet. Enable SPL_SYSCON config for
CONFIG_TI_AM65_CPSW_NUSS.
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
CPSW driver is defined as UCLASS_MISC driver which needs to be probed
explicitly. Define bind method for CPSW driver to scan and bind
ethernet-ports with UCLASS_ETH driver which will eventually probe CPSW
driver and avoid probing CPSW driver explicitly.
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
K3 Inline ECC mechanism can support up to 3 regions of inline ECC, add
this support for single controller.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
The existing approach does not account for interleaving in the DDRs when
setting up regions. There is support for MSMC to calculate the regions
for each DDR, so modify k3_ddrss_probe to set the regions accordingly
for multi-DDR systems.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Add support for calculation of the protected regions for each DDR in
multi-DDR systems. Since MSMC is the parent node of the individual DDRs
as well as responsible for their interleaving, it only makes sense for
MSMC to contain the logic for dividing the regions.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
In K3 multi-DDR systems, the MSMC is responsible for the interleave
mechanism across all the DDR controllers. Add support for MSMC to obtain
the number of controllers it's responsible for using the DT.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
As we increase the functionalities that the K3 DDRSS sub-system support,
it is becoming more evident that the same logic cannot apply to both
single as well as multiple DDR controller devices. Add
CONFIG_K3_MULTI_DDR to be used to differentiate between the two.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Instead of defaulting to choosing the entire DDR region when enabling
inline ECC, allow picking of a range within the DDR space using DT to
enable.
It expects such a node within the memory node, in the absence of which
we resort to enabling inline ECC for the entire DDR region:
inline_ecc: protected@9e780000 {
device_type = "ecc";
reg = <0x9e780000 0x0080000>;
bootph-all;
};
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
The reserved space needed for storing the parity remains the same no
matter the size of the region that is being protected. Add this as a
comment for better code understanding.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
To prevent checkpatch warning once we start using this macro more
frequently, shorten the length of it. While at it, also move the
structure k3_ddrss_ecc_region above k3_msmc so that future patches can
have it as a member of k3_msmc.
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
