| Age | Commit message (Collapse) | Author |
|---|
|
It's currently possible to make the bootloader crash on calling
clk_set_rate caused by the loop in clk_clean_rate_cache.
The loop assume that every child of the clock node are also clock
device but this is not always the case. For example it's common for a
clock to bind to a reset device or also expose a syscon if the clock
register map is also used to apply special configuration.
In such case, on accessing a device as a clock, the bootloader crash. To
correctly handle this, check if the child device is actually a clock and
ignore otherwise.
Fixes: 6b7fd3128f71 ("clk: fix set_rate to clean up cached rates for the hierarchy")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
|
|
SST(sst26wf016) flashes have multiple erase block sizes, including
8 KB, 32 KB, and 64 KB. Since a 64 KB sector erase cannot be performed
on all blocks, the 4 KB sector erase command should be used instead.
Enabling the SPI_FLASH_USE_4K_SECTORS configuration allows the use of
4 KB sector erases, but it may increase the erase operation time for large
memory flashes.
This reverts commit 34cd4a72fb2d113e2754c0d643618a8e3fa549ab
MEMORY ORGANIZATION:
The SST26WF016B/016BA SQI memory array is organized
in uniform, 4 KByte erasable sectors with the following
erasable blocks: eight 8 KByte parameter, two
32 KByte overlay, and thirty 64 KByte overlay blocks.
See Figure 3-1.
Top of Memory Block
┌──────────┐
│ 8 KByte │
├──────────┤
│ 8 KByte │
├──────────┤
│ 8 KByte │
├──────────┤
│ 8 KByte │
├──────────┤
│ 32 KByte │
├──────────┤
│ 64 KByte │
├──────────┤
│ 64 KByte │
├──────────┤
│ 64 KByte │
├──────────┤
│ 32 KByte │
├──────────┤
│ 8 KByte │
├──────────┤
│ 8 KByte │
├──────────┤
│ 8 KByte │
├──────────┤
│ 8 KByte │
└──────────┘
Bottom of Memory Block
┌────────────────────────────────┐
│ 64 KByte │
├────────────────────────────────┤
│ 64 KByte │
└────────────────────────────────┘
Expanded View:
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 4 KB │ │ 4 KB │ │ 4 KB │ │ 4 KB │
├──────┤ ├──────┤ ├──────┤ ├──────┤
│ . . . (continues) . . . │
└──────┘ └──────┘ └──────┘ └──────┘
2 Sectors for 8 KByte blocks
8 Sectors for 32 KByte blocks
16 Sectors for 64 KByte blocks
Link: https://ww1.microchip.com/downloads/en/DeviceDoc/20005013D.pdf
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
|
|
QSPI driver performs chip select operation before every read/write
access. During this operation, driver needs to enable and disable
the QSPI controller. This may cause data loss if there is inadvertent
halting of any ongoing read/write operation. To avoid this scenario,
waiting for the QSPI status to be idle before next read/write
operation is implemented.
Signed-off-by: Naresh Kumar Ravulapalli <nareshkumar.ravulapalli@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
|
|
Takahiro Kuwano <Takahiro.Kuwano@infineon.com> says:
Those are 3.0V, 256Mb/2Gb NOR Flash devices with Octal interface.
Same fanctionalities with 1.8V version that are already supported.
Link: https://lore.kernel.org/r/cover.1743575001.git.Takahiro.Kuwano@infineon.com
|
|
Infineon S28HL02GT is 3.0V, 2Gb Flash device with Octal interface.
It has the same functionalities with S28HS02GT.
Link: https://www.infineon.com/dgdl/Infineon-S28HS02GT_S28HS04GT_S28HL02GT_S28HL04GT_2Gb_4Gb_SEMPER_Flash_Octal_interface_1.8V_3.0V-DataSheet-v01_00-EN.pdf?fileId=8ac78c8c7e7124d1017f0631e33714d9
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
Infineon S28HL256T is 3.0V, 256Mb Flash device with Octal interface.
It has the same functionalities with S28HS256T.
Link:https://www.infineon.com/dgdl/Infineon-S28HS256T_S28HL256T_256Mb_SEMPER_Flash_Octal_interface_1_8V_3-DataSheet-v02_00-EN.pdf?fileId=8ac78c8c8fc2dd9c018fc66787aa0657
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
At the moment a mixture of ifdef(CONFIG_IS_ENABLED) and
CONFIG_IS_ENABLED(SPI_FLASH_BAR) is used in the spi-nor framework.
This leads to misbehaviour in the SPL as there is no Kconfig option
CONFIG_SPL_SPI_FLASH_BAR. This commit standardizes the use of
CONFIG_SPI_FLASH to get SPLs that load U-Boot proper from the
SPI flash to work again.
Fixes: 9bb02f7 (mtd: spi-nor: Fix the spi_nor_read() when config SPI_STACKED_PARALLEL is enabled)
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
|
|
Since the opcode SPINOR_OP_CHIP_ERASE (0xc7) is not supported
for the mt35xu01g/2g flashes, the NO_CHIP_ERASE flag has been added
to enable sector erase functionality instead.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
|
|
The mtd partition offset must be calculated first as it will be
referenced when calculating the mtd partition size.
Change-Id: Iccfd101b0a9597ac240c25670da638a82af28980
Fixes: 1ca97ee9039 (mtd: mtdpart: Support MTD_SIZE_REMAINING with unallocated memory area)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reported-by: Francesco Dolcini <francesco@dolcini.it>
|
|
As this driver needs to use the special sandbox <asm/malloc.h> header
rather than normal malloc, it must be careful of the includes it brings
in. It does not need <spi.h> for anything, so drop it.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Currently, the phy_config() API is invoked by the driver only once since it
has been probed. While this works in general, it doesn't allow the driver
to bring the PHY back to its default reset state. As a result, the driver
might not be able to recover the PHY from a bad state. To address this,
move phy_config() into the driver's start callback (am65_cpsw_start()).
Apart from providing the means to recover the PHY in the event of failure,
the implementation is in line with the idea of "reset and configure" that
is already followed by am65_cpsw_start() when it comes to programming the
CPSW MAC.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/25974
- Fix power-domain ref counting regression.
- Fix i.MX8MP USB clock regression.
- Fix i.MX8MM osc_32k regression in SPL.
- Finish converting clock-osc-24 back to osc_24 on i.MX.
- Several imx8mp capricorn updates.
- Update Stefano Babic's email address.
- Fix fsl_qspi bug by moving AHB read buffer config after LUT.
- Fix verdin imx95 sku 0089 pid4.
|
|
We have improvements to the reliability of H6 and H616 DRAM
initialisation, hopefully avoiding those occasional size misdetections
many people reported before.
Also there is some modernisation of the USB PHY code, to use DT provided
regulators and GPIOs, instead of relying on this being badly duplicated
in Kconfig. This also happens to fix broken USB operations for older
boards (using the A20 SoCs, for instance), which were clashing over
grabbing some GPIOs, leading to a driver bailout. There is also some
rework of the H6/H616 SPL clock code, to prepare it for being reused by
the upcoming Allwinner A523 support. This drops the usage of C structs
to model MMIO register frames, and replaces them by using an addition of
the base address with a macro defined offset. Also in preparation for
A523 there is one fix and one addition for the FEL code, to prepare for
the GICv3 interrupt controller that the new SoC uses. And since this is
a simple fix, and was ready, there is also the watchdog driver for that
new SoC. Finally tossing in an easy fix to some H616 defconfig files to
enable eMMC.
I also use the opportunity to enable proper page table protection
(observing read-only and no-execute attributes), support for which the
arm64 port recently gained. I didn't spot any issues on my arm64 board
tests, but it can be easily disabled or backed out again in case any
issues arise.
Full support for the two new SoC series (A133 and A523) we are working
on is not quite ready yet, but might follow still a bit later if
progress permits.
CI passed, and boot-tested on at least one board with a H616, H6, A64,
H3, A20, T113s.
|
|
The Allwinner MMC code uses a complex C struct, modelling the clock
device's register frame. We rely on sharing the member names across all
Allwinner SoCs, which is fragile.
Drop the usage of the struct in the MMC code, by using #define'd
register names and their offset, and then adding those names to the base
pointer. This requires to define those offsets for all SoCs, but since we
only use between four and six clock registers in the MMC code, this is
easily done.
This removes one common user of the clock register struct.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
The Allwinner A523 SoC moved the watchdog into a separate MMIO frame,
and also shifted the registers a bit: the control, config, and mode
register are located four bytes earlier.
Add the new compatible string, and connect it to the new struct
describing the new register layout.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
So far Allwinner boards controlled the USB OTG ID detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_id_det-gpios property.
Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.
This removes the need to name that GPIO in the defconfig file.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
|
|
So far Allwinner boards controlled the USB VBUS detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_vbus_det-gpios property.
Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.
This removes the need to name that GPIO in the defconfig file.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
|
|
Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove
it, along with the rest of the support for AXP virtual GPIOs.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
|
|
The device tree binding for the PHY provides VBUS supplies as regulator
references. Now that all boards have the appropriate regulator uclass
drivers enabled, the PHY driver can switch to using them. This replaces
direct GPIO usage, which in some cases needed a special DM-incompatible
"virtual" GPIO from the PMIC.
The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are
missing the "usb0_vbus-supply" property in their device tree. None of
them have the MUSB controller enabled in host or OTG mode, so they
should see no impact:
- Ainol_AW1_defconfig / sun7i-a20-ainol-aw1
- Ampe_A76_defconfig / sun5i-a13-ampe-a76
- CHIP_pro_defconfig / sun5i-gr8-chip-pro
- Cubieboard4_defconfig / sun9i-a80-cubieboard4
- Merrii_A80_Optimus_defconfig / sun9i-a80-optimus
- Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99
- Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078
- Yones_Toptech_BS1078_V2_defconfig /
sun6i-a31s-yones-toptech-bs1078-v2
- iNet_3F_defconfig / sun4i-a10-inet-3f
- iNet_3W_defconfig / sun4i-a10-inet-3w
- iNet_86VS_defconfig / sun5i-a13-inet-86vs
- iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2
- icnova-a20-swac_defconfig / sun7i-a20-icnova-swac
- sun8i_a23_evb_defconfig / sun8i-a23-evb
Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not
have "usb1_vbus-supply" in their device tree. Neither of them have USB
enabled at all, so again there should be no impact:
- Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3)
- sun8i_a23_evb_defconfig / sun8i-a23-evb
The following boards use a different pin for USB1 VBUS between their
defconfig and their device tree. Depending on which is correct, they
may be broken:
- Linksprite_pcDuino3_Nano_defconfig (PH11) /
sun7i-a20-pcduino3-nano (PD2)
- icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6)
Finally, this board has conflicting pins given for its USB2 VBUS:
- Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12)
Signed-off-by: Samuel Holland <samuel@sholland.org>
[Andre: use regulator_set_enable_if_allowed()]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
|
|
AXP PMICs have a pin which can either report the USB VBUS state, or
driving a regulator that supplies USB VBUS. Add a regulator driver for
controlling this pin. The selection between input and output is done via
the x-powers,drive-vbus-en pin on the PMIC (parent) node.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
|
|
Pass the clock controller udevice into clk_register_composite(),
so it can be passed further to any registered composite clocks
and used for look up of parent clock referenced in DT "clocks"
and "clock-names" properties by phandle and name pair.
Use the clock controller udevice in imx8m_clk_mux_set_parent()
to perform accurate look up of parent clock referenced in the
CCM driver by name. If the clock name that is being looked up
matches one of the names listed in the clock controller DT node
"clock-names" array property, then the offset of the name is
looked up in the "clocks" DT property and the phandle at that
offset is resolved to the parent clock udevice. The test to
determine whether a particular driver instance registered with
clock uclass matches the parent clock is done by comparing the
OF nodes of the clock registered with clock uclass and parent
clock resolved from the phandle.
Example:
drivers/clk/imx/clk-imx8mm.c:
static const char * const imx8mm_a53_sels[] = {"osc_24m", "arm_pll_out", ...
_____________|
arch/arm/dts/imx8mm.dtsi: |
clk: clock-controller@30380000 { v
clock-names = "osc_32k", "osc_24m", ...
|
v
clocks = <&osc_32k>, <&osc_24m>, ...
}; _______________________|
... |
/ { v
osc_24m: clock-osc-24m {
compatible = "fixed-clock";
...
};
Signed-off-by: Marek Vasut <marex@denx.de>
Reported-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Adam Ford <aford173@gmail.com> # imx8mp-beacon
|
|
Prevent enabling/disabling multiple times the same power domain to avoid
breakages due to the same power domains being referenced several times
by different device nodes.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
It is very surprising that such an uclass, specifically designed to
handle resources that may be shared by different devices, is not keeping
the count of the number of times a power domain has been
enabled/disabled to avoid shutting it down unexpectedly or disabling it
several times.
Doing this causes troubles on eg. i.MX8MP because disabling power
domains can be done in recursive loops were the same power domain
disabled up to 4 times in a row. PGCs seem to have tight FSM internal
timings to respect and it is easy to produce a race condition that puts
the power domains in an unstable state, leading to ADB400 errors and
later crashes in Linux.
Some drivers implement their own mechanism for that, but it is probably
best to add this feature in the uclass and share the common code across
drivers. In order to avoid breaking existing drivers, refcounting is
only enabled if the number of subdomains a device node supports is
explicitly set in the probe function. ->xlate() callbacks will return
the power domain ID which is then being used as the array index to reach
the correct refcounter.
As we do not want to break existing users while stile getting
interesting error codes, the implementation is split between:
- a low-level helper reporting error codes if the requested transition
could not be operated,
- a higher-level helper ignoring the "non error" codes, like EALREADY and
EBUSY.
CI tests using power domains are slightly updated to make sure the count
of on/off calls is even and the results match what we *now* expect. They
are also extended to test the low-level functions.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
DSI is the peripheral clock, while DSI_K is an internal kernel clock.
Even though they get the same register and same bit set to be gated,
resulting in the same behavior.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
When using CONFIG_FSL_QSPI_AHB_FULL_MAP the fsl_qspi_default_setup() sets
the BFGENCR register to use the LUT(SEQID_LUT_AHB) before the Look Up Table
is populated.
This result in a situation that after 'sf probe' command any memory
read from qspi using AHB will result in undefined behaviour (hang) untill
first 'sf read' op is executed.
Move the BFGENCR write to fsl_qspi_prepare_lut() to ensure that the setup
is consistent. AHB reads will use the default LUT(index 0) setup by previous
boot stage untill the first read op.
Signed-off-by: Pawel Kochanowski <pkochanowski@sii.pl>
|
|
The UART clocks were added around the same time some other clock
updates were happening, so converting clock-osc-24 back to osc_24
was missed on the UART clocks for imx8mm and imx8mn, so update
them here.
Fixes: b4734c9c333b ("clk: imx: Convert clock-osc-* back to osc_*")
Signed-off-by: Adam Ford <aford173@gmail.com>
Reported-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
|
|
Hrushikesh Salunke <h-salunke@ti.com> says:
TI's AM64 SoC has a single instance of Cadence PCIe Controller. This
series enables support for PCIe in AM64 SoC and to configure it in
Root-Complex mode of operation.
Link: https://lore.kernel.org/r/20250416120830.138965-1-h-salunke@ti.com
|
|
TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which
is Cadence PCIe Controller. Add support to configure PCIe0 in Root-
Complex mode of operation.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
Driver uses macro SZ_4G to configure inbound base address register.
The macro is used without including the header file in which it is
defined. Fix this.
Fixes: 59ad5480098 ("pci: Add TI K3 Cadence PCIe Controller")
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
|
|
Judith Mendez <jm@ti.com> says:
This patch series fixes MMC_HS_52 mode in am654_sdhci driver,
as well as HIGH_SPEED_ENA and UHS_MODE_SELECT for HS modes.
Also add TI_COMMON_CMD_OPTIONS to K3 Sitara board a53 defconfigs.
Link: https://www.ti.com/lit/er/sprz574a/sprz574a.pdf
Link: https://lore.kernel.org/r/20250417234334.3661321-1-jm@ti.com
|
|
This patch adds am654_sdhci_set_control_reg to am654_sdhci.
This is required to fix UHS_MODE_SELECT for TI K3 boards.
If any of HIGH_SPEED_ENA, V1P8_SIGNAL_ENA, UHS_MODE_SELECT
are set, then data will be launched on the pos-edge of the
clock.
Since K3 SoCs did not meet timing requirements for High Speed
SDR mode at rising clock edge, none of these three should be
set, therefore limit UHS_MODE_SELECT to only be set for modes
above MMC_HS_52.
This fixes MMC write issue on am64x evm at mode High Speed
SDR.
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
High Speed enable bit switches data launch from the falling
clock edge (half cycle timing) to the rising clock edge (full
cycle timing). For all SD UHS modes, data launch must happen
at the rising clock edge, so set HIGH_SPEED_ENA for SDR12 and
SDR25 modes. For all HS modes, data launch must happen at the
falling clock edge, so do not set HIGH_SPEED_ENA for MMC_HS_52.
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
This patch adds MMC_HS_52 to the timing data structure.
Previously, this bus mode tap settings were not populated and
were instead populated for MMC_HS which is a different bus mode
up to 26MHz. Since we intended these settings according to the
device data sheet[0] for MMC_HS_52 up to 52MHz, populate MMC_HS
tap settings for MMC_HS_52.
While we are here, fix typo in ti,itap-del-sel-mms-hs.
[0] https://www.ti.com/lit/ds/symlink/am625.pdf Table 7-79
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu
u-boot-dfu-20250425
Usb gadget:
- Fix ACM gadget release
- Allow ACM gadget restart after releasing it
- Add 'enabled' flag to usb_ep structure
DFU:
- Fix alt buffer clearing for DeveloperBox board
|
|
Adding quirk to disable STIG mode since cadence controller has
issue for read/write using the STIG mode. STIG mode is enabled
by default since 2023.04 for small read/write(<8bytes).
Updated STIG mode reading from dev_get_driver_data by assigning
to platdata struct before read quirks variable.
The STIG mode is disabled for normal read case and enabled
for QSPI Jedec ID read/write since it requires STIG read/write.
Porting from linux implementation
https://lore.kernel.org/all/20241204063338.296959-1-niravkumar
.l.rabara@intel.com/T/
Signed-off-by: Boon Khai Ng <boon.khai.ng@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
|
|
If eqos_free_pkt() is called after eqos_stop(), eqos_stop_resets() will
have been called already. This may prevent accessing the MMIO space to
update the RX descriptor tail pointer, so we must skip the descriptor
maintenance logic. This is okay because the descriptors and tail pointer
will all be rewritten anyway during the next call to eqos_start().
This hang was observed after a failed TFTP transaction:
eqos_recv(dev=000000047fb57330, flags=1):
eqos_recv: *packetp=000000c3ffb5c080, length=151
TFTP error: 'file <FILE> not found for <IP>' (1)
Not retrying...
eqos_stop(dev=000000047fb57330):
eqos_stop: OK
eqos_free_pkt(packet=000000c3ffb5c080, length=151)
<HANG>
Fixes: ba4dfef1469f ("net: add driver for Synopsys Ethernet QoS device")
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
This series introduces threads and uses them to improve the performance
of the USB bus scanning code and to implement background jobs in the
shell via two new commands: 'spawn' and 'wait'.
The threading framework is called 'uthread' and is inspired from the
barebox threads [2]. setjmp() and longjmp() are used to save and
restore contexts, as well as a non-standard extension called initjmp().
This new function is added in several patches, one for each
architecture that supports HAVE_SETJMP. A new symbol is defined:
HAVE_INITJMP. Two tests, one for initjmp() and one for the uthread
scheduling, are added to the lib suite.
After introducing threads and making schedule() and udelay() a thread
re-scheduling point, the USB stack initialization is modified to benefit
from concurrency when UTHREAD is enabled, where uthreads are used in
usb_init() to initialize and scan multiple busses at the same time.
The code was tested on arm64 and arm QEMU with 4 simulated XHCI buses
and some devices. On this platform the USB scan takes 2.2 s instead of
5.6 s. Tested on i.MX93 EVK with two USB hubs, one ethernet adapter and
one webcam on each, "usb start" takes 2.4 s instead of 4.6 s.
Finally, the spawn and wait commands are introduced, allowing the use of
threads from the shell. Tested on the i.MX93 EVK with a spinning HDD
connected to USB1 and the network connected to ENET1. The USB plus DHCP
init sequence "spawn usb start; spawn dhcp; wait" takes 4.5 seconds
instead of 8 seconds for "usb start; dhcp".
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=446674
[2] https://github.com/barebox/barebox/blob/master/common/bthread.c
Link: https://lore.kernel.org/r/20250418141114.2056981-1-jerome.forissier@linaro.org
|
|
Use the uthread framework to initialize and scan USB buses in parallel
for better performance. The console output is slightly modified with a
final per-bus report of the number of devices found, common to UTHREAD
and !UTHREAD. The USB tests are updated accordingly.
Tested on two platforms:
1. arm64 QEMU on a somewhat contrived example (4 USB buses, each with
one audio device, one keyboard, one mouse and one tablet)
$ make qemu_arm64_defconfig
$ make -j$(nproc) CROSS_COMPILE="ccache aarch64-linux-gnu-"
$ qemu-system-aarch64 -M virt -nographic -cpu max -bios u-boot.bin \
$(for i in {1..4}; do echo -device qemu-xhci,id=xhci$i \
-device\ usb-{audio,kbd,mouse,tablet},bus=xhci$i.0; \
done)
2. i.MX93 EVK (imx93_11x11_evk_defconfig) with two USB hubs, each with
one webcam and one ethernet adapter, resulting in the following device
tree:
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 100mA)
| GenesysLogic USB2.1 Hub
|
+-3 Vendor specific (480 Mb/s, 350mA)
| Realtek USB 10/100/1000 LAN 001000001
|
+-4 (480 Mb/s, 500mA)
HD Pro Webcam C920 8F7CD51F
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 100mA)
| USB 2.0 Hub
|
+-3 Vendor specific (480 Mb/s, 200mA)
| Realtek USB 10/100/1000 LAN 000001
|
+-4 (480 Mb/s, 500mA)
Generic OnLan-CS30 201801010008
Note that i.MX was tested on top of the downstream repository [1] since
USB doesn't work in the upstream master branch.
[1] https://github.com/nxp-imx/uboot-imx/tree/lf-6.6.52-2.2.0
commit 6c4545203d12 ("LF-13928 update key for capsule")
The time spent in usb_init() ("usb start" command) is reported on
the console. Here are the results:
| CONFIG_UTHREAD=n | CONFIG_UTHREAD=y
--------+------------------+-----------------
QEMU | 5628 ms | 2212 ms
i.MX93 | 4591 ms | 2441 ms
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
To prepare for the introduction of threads in the USB initialization
sequence, move code out of usb_init() into a new helper function:
usb_init_bus() and count the number of USB controllers initialized
successfully by using the DM device_active() function.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
https://source.denx.de/u-boot/custodians/u-boot-rockchip
CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/25909
Please pull the updates for rockchip platform:
- New SoC support: RK3528, RK3576
- New Board support: rk3528 Radxa E20C, rk3576 Firefly ROC-RK3576-PC;
- Add generic board for rk3288 and rk3399;
- rng driver binding update;
- misc updates on board level or header files;
|
|
https://source.denx.de/u-boot/custodians/u-boot-mmc
- Introducing back send_init_stream for omap_hsmmc
to perform the 74 clocks cycle sequence
- Move scmi regulator subnode hack to scmi_regulator
- Typo fix
|
|
Add rk_gmac_ops and other special handling that is needed for GMAC to
work on RK3576.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The rk3576 uses a different base-compatible, as starting with this
generation, the clock phase tuning is done via registers inside
the mmc controller and not from inside the CRU.
In U-Boot we do not tune at all, so no other code changes are
necessary.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add support for RK3576 to the rockchip sdhci driver.
It's pretty similar to its cousins found in the RK3568 and RK3588 and the
specific hs400-tx-tap number was taken from the vendor-u-boot.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add support for RK3576 compatible.
The RK3576 OTP uses the same read mechanism as the RK3588, just
with different values for offset and size.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add ddr driver for rk3576 to get the ram capacity.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The current DT bindings for the rk3576 clock use a different ID than the
one that is supposed to be written to the hardware registers.
Thus, we cannot use directly the id provided in the phandle, but rather
use a lookup table to correctly setup the hardware.
This follows the implementation done in the Linux-Kernel and also
how the rk3588 does this both in the Linux-Kernel as well as U-Boot.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
[adapted from mainline Linux code for u-boot]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add clock driver support for Rockchip RK3576 SoC.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
[adapted to mainline u-boot]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add support for the rk3576 variant of pinctrl.
Signed-off-by: Steven Liu <steven.liu@rock-chips.com>
[adapted to mainline u-boot]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Rockchip RK3528 has two Ethernet controllers based on Synopsys DWC
Ethernet QoS IP.
Add initial support for the RK3528 GMAC variant.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
