| Age | Commit message (Collapse) | Author |
|---|
|
fixes & cleanups"
Baocheng Su <baocheng.su@siemens.com> says:
This introduces a sysinfo driver which also permits SMBIOS support.
The first 10 patches of v2 have already been applied. The remaining is
solely the sysinfo driver. To maintain consistency and ease of searching
through the history, the series title remains unchanged.
Link: https://lore.kernel.org/r/20250218023614.52574-1-baocheng.su@siemens.com
|
|
This brings a sysinfo driver and DT entry for the IOT2050 board series.
It translates the board information passed from SE-Boot to SPL into
values that can be retrieved via the sysinfo API. Will is already used
to fill the SMBIOS table when booting via EFI.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
[Jan: split-off as separate patch, cleanup]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
|
|
This commit introduces a new API to the sysinfo module, allowing access
to data elements. This is particularly useful for handling data with
multiple instances, such as MAC addresses.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
|
|
During dma memcpy, bcdma descriptor gets allocated for each
transaction and not freed after completion of that transaction.
So, avoid the memory allocation for every transaction.
Add one descriptor per dma device and allocate it once in
resource setup. This descriptor can now be used for all
dma memcpy transactions optimally.
Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
|
|
serial_out_dynamic() takes a u8* addr and uses it for 8-bit or 32-bit
accesses, depending on the value of plat->reg_width. This results in a
pointer type mismatch that the compiler may even turn into an error:
drivers/serial/ns16550.c: In function ‘serial_out_dynamic’:
drivers/serial/ns16550.c:115:42: error: passing argument 1 of ‘out_be32’ from incompatible pointer type [-Wincompatible-pointer-types]
115 | out_be32(addr, value);
| ^~~~
| |
| u8 * {aka unsigned char *}
This error was observed on PowerPC.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
|
|
If there is an unallocated memory area before the last, filling parting
the size calculation for MTD_SIZE_REMAINING does not take this hole
into account.
Fix this by calculating the remaining size just based on total size
and partition offset.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
|
|
Neither bb_miiphy_buses nor bb_miiphy_buses_num are used anymore.
Drop both of them.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Instead of doing another lookup, trivially access the struct mii_dev
embedded in struct bb_miiphy_bus . No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
Instead of doing another lookup, trivially access the struct mii_dev
embedded in struct bb_miiphy_bus . No functional change.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The struct bb_miiphy_bus embeds struct struct mii_dev, which
already contains one copy of name field. Drop the duplicate
top level copy of name field.
The a38x code does static assignment of disparate names, use
snprintf(...) to fill in matching name in probe to avoid any
breakage.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Replace the name based look up in bb_miiphy_getbus() with trivial
container_of() call. This works because the struct bb_miiphy_bus
always embeds the matching struct mii_dev . This also makes the
code much simpler and more efficient.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
callbacks
Allocate bb_miiphy using bb_miiphy_alloc() and fill in callbacks
currently listed in bb_miiphy_buses[] array. This is a temporary
duplication of assignment to avoid breakage, which will be removed
in follow up patches. At this point, the bb_miiphy callbacks can
reach these accessors by doing container_of() on struct mii_dev.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
Allocate bb_miiphy using bb_miiphy_alloc() and fill in callbacks
currently listed in bb_miiphy_buses[] array. This is a temporary
duplication of assignment to avoid breakage, which will be removed
in follow up patches. At this point, the bb_miiphy callbacks can
reach these accessors by doing container_of() on struct mii_dev.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
Allocate bb_miiphy using bb_miiphy_alloc() and fill in callbacks
currently listed in bb_miiphy_buses[] array. This is a temporary
duplication of assignment to avoid breakage, which will be removed
in follow up patches. At this point, the bb_miiphy callbacks can
reach these accessors by doing container_of() on struct mii_dev.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Introduce bb_miiphy_alloc()/bb_miiphy_free() wrappers to allocate and free
struct bb_miiphy_bus. Make struct bb_miiphy_bus wrap struct mii_dev, which
will become useful later in bb_miiphy_bus accessors, which would be able
to access struct bb_miiphy_bus using container_of, even if the PHY stack
only passes in the inner struct mii_dev .
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Pull the bbmiiphy initialization code from designware_eth_probe() into
dedicated function, dw_bb_mdio_init(), just like all the other MDIO
initialization functions.
Keep check for "snps,bitbang-mii" in the designware_eth_probe(), so the
driver can initialize this MDIO only in case the property is present,
and initialize regular DW MDIO in case it is not present.
The dw_bb_mdio_init() allocates its own MDIO instance, because thus far
code gated behind "snps,bitbang-mii" did depend on allocation of MDIO bus
by the other two MDIO bus options and then rewrote the newly allocated
MDIO bus callbacks, which is wrong, instead allocate proper MDIO bus with
the correct callbacks outright.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
There is literally one single bbmiiphy bus in this driver,
remove the bus index handling.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
The .init callback is not called by any function, drop it.
There are no more users of the init callback, drop the entire
mechanism.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Move the bb_miiphy functions before MDIO registration. This is a
preparatory patch, the functions will be referenced around the MDIO
registration in the follow up patches. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
Move the bb_miiphy functions before MDIO registration. This is a
preparatory patch, the functions will be referenced around the MDIO
registration in the follow up patches. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
|
|
Move the bb_miiphy functions before MDIO registration. This is a
preparatory patch, the functions will be referenced around the MDIO
registration in the follow up patches. No functional change.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
This is unnecessary, the unset structure member is initialized to
NULL by default, drop the assignment.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The init function does nothing, the bb_miiphy_init() already checks
whether the .init callback is assigned, and if not, skips calling it.
Remove the empty init function. The entire init callback will be
removed in follow up patches.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
The init function does nothing, the bb_miiphy_init() already checks
whether the .init callback is assigned, and if not, skips calling it.
Remove the empty init function. The entire init callback will be
removed in follow up patches.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/24816
Please pull the SoCFPGA changes for next from u-boot-socfpga, containing
boot support for the Altera SoCFPGA Agilex 5 platform in U-Boot. The
changes include:
1. Board-specific configurations and setup required to enable Agilex 5
operation in U-Boot.
2. Integration of cache coherency unit (CCU) initialization routine,
including CCU conguration in DT.
3. Clock, firewall (configured in DT), SMMU, low level initialization
specific to Agilex 5.
4. Integration of memory initialization routine, including DDR setup.
This patch set has been tested on Agilex 5 devkit with QSPI boot
(UBI/UBIFS) and RAM boot (TFTP & ARM DS debugger).
|
|
Adding DDR driver support for Agilex5 series.
Signed-off-by: Tingting Meng <tingting.meng@altera.com>
|
|
PLL frequency would overshoot from the original target in
synchronous mode during low VCC voltage condition.
To resolve this issue, PLL is set to run on asynchronous mode
instead of enabling synchronous mode in the clock driver.
Signed-off-by: Muhammad Hazim Izzat Zamri <muhammad.hazim.izzat.zamri@altera.com>
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
|
|
Replace cm_wait_for_fsm() function with wait_for_bit_le32() function
which supports accurate timeout.
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
|
|
Some customers prefer to minimize the use of external oscillators,
especially when using the FPGA first configuration mode.
By enabling the configuration of the HPS internal oscillator as
the boot_clk source instead of the default external oscillator,
(HPS_OSC_CLK) in non-secure boot scenarios, this allows them
to eliminate the need for an additional oscillator device and
a dedicated HPS pin, simplifying board layout and routing.
Signed-off-by: Tingting Meng <tingting.meng@altera.com>
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
|
|
Prepare v2025.04-rc3
|
|
For eMMC v4 and newer that is smaller than 2 GiB, the JEDEC JESD84-B51
section 6.2.4 Configure partitions indicates that EXT_CSD SEC_COUNT
should not be used to determine device size, and instead device size
should be calculated from C_SIZE and C_SIZE_MULT.
This is not exactly accurate, the 2 GiB limit is not a hard line,
there are eMMC devices which are smaller than 2 GiB and still
require device size to be determined from EXT_CSD SEC_COUNT. The
hard line is instead OCR HCS bit, which indicates whether the device
is byte or sector addressed, the former applies to most devices
below 2 GiB, and the later applies mostly to devices above 2 GiB.
However, there are a couple of devices which are smaller than 2 GiB
and still set the OCR HCS bit to indicate they are sector addressed,
and therefore the size calculation for those devices should also
use EXT_CSD SEC_COUNT . Use mmc->high_capacity flag to discern the
devices instead of arbitrary 2 GiB limit. The mmc->high_capacity flag
reflects the OCR HCS bit state.
Fixes: 639b7827d1ca ("mmc: fix the condition for MMC version 4")
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
Memory region used by remote cores was set to non-cached region but
commit 7c9c6e192580 ("arm: mach-k3: Merge initial memory maps") makes
all memory region as cached, unified across K3 devices.
This causes inconsistency while booting remote cores on devices, due to
cache incoherency between remote core and boot code.
So to make this operation coherent, cache the address and len while
loading ELF program headers to memory and flush that region in the next
cycle of load.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
|
|
Defining CONFIG_MT8512 is unnecessary as now board for mediatek
target can be changed in config.
Use CONFIG_TARGET_MT8512 to replace CONFIG_MT8512.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
|
|
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX
and/or TX delay. Currently RX/TX delay is configured as enabled using
zero as delay value for the rgmii-rxid/txid/id modes.
Change to disable RX and/or TX delay and using zero as delay value.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX
and/or TX delay. Currently RX/TX delay is configured as enabled using
zero as delay value for the rgmii-rxid/txid/id modes.
Change to disable RX and/or TX delay and using zero as delay value.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width,
correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is
recalculated so it remain unchanged. Add missing GPIO3-B1 to GPIO3-B7
pinmux data to rk3328_mux_recalced_data as mux register offset for these
pins does not follow rockchip convention.
This matches changes in following Linux commits:
- e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins")
- 5ef6914e0bf5 ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins")
- 128f71fe014f ("pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add support to NXP GPIO expanders pcal6408, documented at [1], and
pcal6416, documented at [2].
[1] https://www.nxp.com/docs/en/data-sheet/PCAL6408A.pdf
[2] https://www.nxp.com/docs/en/data-sheet/PCAL6416A.pdf
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
|
|
The PCS exists only in GMAC1 and relates to SGMII interface and
is used to control the SGMII PHY.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
[trini: Adjust slightly for white space and to move 'start' to within if
block]
|
|
The following was reported by Covervity scan:
*** CID 541279: (TAINTED_SCALAR)
/drivers/led/led-uclass.c: 284 in led_get_function_name()
278 if (!ret) {
279 snprintf(uc_plat->name, LED_MAX_NAME_SIZE,
280 "%s:%s-%d",
281 cp ? "" : led_colors[color],
282 func ? func : "", enumerator);
283 } else {
>>> CID 541279: (TAINTED_SCALAR)
>>> Using tainted variable "color" as an index into an array "led_colors".
Fix it.
Addresses-Coverity-ID: 541279 (TAINTED_SCALAR)
Link: https://lists.denx.de/pipermail/u-boot/2025-February/580250.html
Signed-off-by: Heiko Schocher <hs@denx.de>
|
|
As per TRM[0] Section 8.7.1 "TPS6594-Q1 Registers", LDOx_Vout
bit 6-1, define the NVM voltage settings.
Along side table 8-4 of above TRM, shows voltage to value mapping.
Driver wrongly using bits 5-1 to calculate voltage, and to convert
voltage to value driver was using buck's calculation.
So fix those calculation.
[0]: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf
Fixes: 5d7dbd22cf7d ("power: regulator: tps65941: use function callbacks for conversion ops")
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
|
|
The struct contains an iomem pointer that we later remap and update.
Remove const from the struct definition.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2025.07 cycle:
This feature set includes improvements on the atmel-quadspi driver, a
fix for the nand driver, and improvements on the pinctrl driver to be
able to use the Linux DT (also sync on the DT side as well).
|
|
When 3-wire mode is claimed on the bus, use the MOSI (output) pin to
receive data. In this mode, since the transfer can only be either TX
or RX, return -EINVAL if both are required at the same time.
Signed-off-by: Hironori KIKUCHI <kikuchan98@gmail.com>
|
|
Judith Mendez <jm@ti.com> says:
Some K3 devices like am62x and am64x have a M4 processor in the MCU
voltage domain. This patch series introduces remoteproc M4 driver which
will be used to load firmware into and start the M4 remote core.
This series also adds support for R5F cores on am64x SoCs in patch 2 and
sets up environment to load FW in remote cores in patch 3,4,5.
This patch series also enables remoteproc drivers by default as per what
remoteproc sybsystem is supported per SoC, thus all remoteproc options
are now deleted in configs/* since they are no longer required.
This patch series was tested on am64x EVM, am62x SK, am62ax SK,
am62px SK boards.
Any additional tested by's are welcome since I was not able to
test any additional boards.
Tested by running the following commands in u-boot prompt:
=> setenv dorprocboot 1
=> run boot_rprocs
Link: https://lore.kernel.org/r/20250210202944.1071931-1-jm@ti.com
|
|
If SYS_K3_SPL_ATF is enabled, for K3 ARCH enable the
remoteproc ARM64 driver by default so that it does not
have to be defined in each board defconfig file.
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
|
|
AM64x SoCs have two R5F clusters in the main power domain.
Extend support for R5F remote proc driver on AM64x with compatible
strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Andrew Davis <afd@ti.com>
|
|
Some K3 devices like AM64, AM62 devices have a M4 processor in MCU
voltage domain.
Add a remote proc driver to support this subsystem to be able to load
and boot the M4 core.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[Ryan: Fix implicitly include warning]
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
[Judith: Cleanup driver, fix warnings, remove lreset logic]
Signed-off-by: Judith Mendez <jm@ti.com>
Tested-by: Daniel Schultz <d.schultz@phytec.de>
Reviewed-by: Andrew Davis <afd@ti.com>
|
|
Add CONFIG_BOOTCOUNT_ALTBOOTCMD so the developer is able to add
custom altbootcmd via Kconfig when they enable BOOTCOUNT. With this now
in Kconfig, we need to move it from environment files / config.h files
and in to the defconfig file.
This was done by generating u-boot-initial-env for all platforms before
the Kconfig change, to extract altbootcmd values and then again after to
compare the result.
[trini: Perform migration to defconfigs, reword commit message]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
From reading the S34ML02G1 and the SAM9X60 datasheets again, it seems
like we have to wait tREA after rising RE# before sampling the data.
Thus pulse time must be at least tREA.
Without this fix we got PMECC errors when reading, after switching to
ONFI timing mode 3 on SAM9X60 SoC with S34ML02G1 raw NAND flash chip.
The approach to set timings used before worked on sam9g20 and sama5d2
with the same flash (S34ML02G1), probably because those have a slower
mck clock rate and thus the resolution of the timings setup is not as
tight as with sam9x60.
The approach to fix the issue was carried over from at91bootstrap, and
has been successfully tested in at91bootstrap, U-Boot and Linux.
Link: https://github.com/linux4sam/at91bootstrap/issues/174
Cc: Li Bin <bin.li@microchip.com>
Signed-off-by: Alexander Dahl <ada@thorsis.com>
|
|
Pin detection on t20 depends on node name. With recent changes
in node naming, let's remove '_' to be safe about both '_' or
'-' use.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
|
