| Age | Commit message (Collapse) | Author |
|---|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-mmc
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-mmc/-/pipelines/614
- Add PMBUS regulator, thermal and test
- Add regulator helper to set voltage within an acceptable range
- Update dw_mmc to use in-spec voltage range for vqmmc
- Fix regulator_enable/disable() macros
- Clear LPUART OR STAT in tstc to avoid hang
- Add MAINTAINERS entry for SDHCI
|
|
get_maintainer in U-Boot is configured to include contributors and patch
reviewers from the git history in the CC list, going back 1 year if they
have contributed more than 5% of the patches.
This is well suited to some core U-Boot code that has a long history and
doesn't get much love from any dedicated maintainer but for newer code
and board code in general as well as defconfigs it can be frustrating
for some contributors who do not wish to be CC'd on patches as well as a
general issue when dead emails are included.
While it would be desirable to just remove the --git flag and encourage
those interested to configure lei or just add themselves to MAINTAINERS
it perhaps makes more sense to phase it out gradually.
As a first step, reduce the time period that will be checked in the git
history from 1 year to 6 months, this still offers plenty of leeway for
contributions to the last 1/2 U-Boot releases. In addition, bump up the
required percentage of contributions from 5% to 15% and reduce the limit
on the number of "git maintainers" (i.e. unique S-o-b/A-b/R-b tags) from
5 to 2.
These changes should reduce the size of CC lists while still including
recent active contributors.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
an unsigned int (mmc_dev_num) with ret, which can hold a negative error
code.
Addresses-Coverity-ID: CID 646439: Integer handling issues (INTEGER_OVERFLOW)
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
The software revision field in the combined board config binary header
was hardcoded to 1, preventing independent control from SBL SWREV
configured via ti-secure-rom's sw-rev property.
Add support for the optional 'sw-rev' DTS property in ti_board_config
nodes, which sets the SWREV byte in the header. Defaults to 1 for
backward compatibility.
Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The fdt checksign command accepts an optional address for an FDT
containing public keys. It currently installs that blob as gd->fdt_blob
before verifying the FIT configuration.
This breaks verification with DM-backed crypto drivers which have not
probed yet, since the later probe path expects gd->fdt_blob to remain
U-Boot's control FDT. For example, an ECDSA verifier can be bound from
the control FDT but fail to probe after fdt checksign points
gd->fdt_blob at the key-only DTB.
Add a FIT config verification helper that takes the key blob explicitly
and use it from fdt checksign. This keeps gd->fdt_blob unchanged while
still allowing the command to verify against an external key DTB.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
|
|
Now that we have everything available on git.u-boot-project.org, switch
URLs to that location.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Add dm unit tests that drive every pmbus subcommand handler against
the sandbox PMBus chip emulator:
dev (select by bus:addr and by regulator-name), list, info,
telemetry, status, dump, read, write, clear, vout, scan and help.
Tested using:
./u-boot -T -c "ut dm pmbus*"
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add a UCLASS_I2C_EMUL driver that emulates a PMBus 1.x compliant chip
behind the sandbox I2C bus, plus the test.dts wiring and sandbox
defconfig that bind it to the generic PMBus regulator
(compatible = "pmbus"). This design is a stub only: it lets the
follow-up dm unit test drive lib/pmbus.c, the generic regulator and
the pmbus CLI command with no real hardware.
The emulator models a flat per-command 16-bit register file and the
three identification block strings (MFR_ID / MFR_MODEL /
MFR_REVISION). READ_IIN and READ_POUT are deliberately left
unimplemented (the chip NAKs them) so the telemetry printer's
"(not supported)" path is exercised, mirroring a real buck that only
calibrates a subset of the sensor classes.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The driver is a thin UCLASS_THERMAL: its get_temp reads the
temperature of its parent regulator through the pmbus helper
(READ_TEMPERATURE_1), without any chip-specific code.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Wire board/nxp/common/vid.c into the <pmbus.h> framework so the legacy
NXP AVS path stops carrying its own duplicate copy of the PMBus
protocol and instead consumes the shared constants, decoders, and
transport helpers.
vid.c is the legacy NXP AVS/pre-kernel voltage-trim path for lx2160 CPUs.
It does PMBus to whichever core-rail voltage monitor the board carries:
LTC3882 or ISL68233 are selected with
CONFIG_VOL_MONITOR_LTC3882_*/CONFIG_VOL_MONITOR_ISL68233_*.
Before this change the file kept its own local PMBUS_CMD_* command-code
defines, its own inline LINEAR16 mantissa/exponent math, and called
into I2C through the I2C_READ/I2C_WRITE NXP wrappers in
board/nxp/common/i2c_common.{c,h} which is a parallel implementation of
exactly what <pmbus.h> + lib/pmbus.c provides.
The intent is to make vid.c an consumer of the new PMBus.
Compatibility with the former support:
- CLI unchanged: vdd_override and vdd_read keep their existing
semantics, return codes, and diagnostic output.
- I2C transport unchanged on the wire: the framework's pmbus_*
helpers call dm_i2c_read/dm_i2c_write: the same DM I2C
backing that vid.c's former I2C_READ/I2C_WRITE macros already
routed through on DM_I2C.
- Numeric decode is bit-equivalent: pmbus_reg2data_linear16() and
pmbus_data2reg_linear16() implement the PMBus 1.3 Part II
mantissa/exponent.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Per-chip UCLASS_REGULATOR driver for the MPS MPQ8785 / MPM3695 /
MPM3695-25 / MPM82504 family, layered on the shared pmbus_helper
adapter. Runs Linux's mpq8785_identify() VOUT_MODE switch
(LINEAR16 vs DIRECT m=64 R=1) at probe time, applies the optional
mps,vout-fb-divider-ratio-permille DT property, and walks the
documented MPS ADDR_VBOOT windows on MFR_ID failure so a
die-revision address shift just works.
Publishes the pmbus mps last|clear last|clear force vendor
extension subcommands (NVM PROTECTION_LAST read and clear) when
CMD_PMBUS is enabled.
Adapted from Linux code.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
PMBus regulators differ in numeric formats and quirks, not in how they
are driven. Share that common behaviour as a regulator-uclass adapter
so chip drivers and the pmbus CLI do not each reimplement the decode
and transport, and add a catch-all driver on compatible = "pmbus" for
compliant chips that have no dedicated driver yet.
Gated by CONFIG_DM_REGULATOR_PMBUS_HELPER and
CONFIG_DM_REGULATOR_PMBUS_GENERIC.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add U-Boot's PMBus 1.x layer: the decoder/transport library, the
pmbus CLI command and a generic DT binding.
The subsequent commits provide the UCLASS_REGULATOR adapter and per-chip
drivers.
U-Boot's PMBus support is not a hwmon clone of Linux's
drivers/hwmon/pmbus/. Linux owns the runtime side (polling, sysfs,
alert IRQs, fan loops). U-Boot owns the boot-time side in order to,
- identify the PMBus regulators a board carries: MFR_ID/
MFR_MODEL/MFR_REVISION + sanity checks.
- print telemetry (VIN/VOUT/IIN/IOUT/POUT/TEMP) so an
operator can confirm rail voltages and faults before the kernel
- decode any chip alerts (STATUS_VOUT/STATUS_IOUT/STATUS_INPUT/
STATUS_TEMPERATURE/STATUS_CML) so a boot log shows why the
previous boot failed or the board had been power cycled because
of an outage (typically over temperature or under current).
Out of scope by design: no periodic polling, no sysfs, no fan-speed
control loop, no PMBUS_VIRT_* sensor virtualisation, no caching.
If a use case needs any of those, the answer should be "wait until
Linux comes up". It shall remain a thin layer.
The constants and structural shape (command codes, status bit names,
sensor-class enum, format enum, struct pmbus_driver_info) are
mirrored from Linux drivers/hwmon/pmbus/pmbus.h verbatim. The
decoders/encoders are reimplemented from the PMBus 1.3
specification because the surrounding hwmon context (struct
pmbus_data, sysfs caching, hwmon publication) does not apply.
The main benefits:
- One framework + CLI for any board carrying PMBus regulators:
no per-board PMBus implementation required anymore.
- Boards call pmbus_print_telemetry() / pmbus_print_status_word()
directly from boot init for a snapshot, sharing all decode +
format-dispatch with the CLI.
- Linux-compatible constants and DT binding so porting an existing
drivers/hwmon/pmbus/ chip is mechanical.
- Boot-time AVS/VID rail trim reuses the same decoders and
encoders as the CLI and the regulator path: no duplicate math.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Clear the STAT register OR bit every time in .tstc callback, otherwise
a condition may occur when data are fed into the RX FIFO, the FIFO did
overflow, the OR bit is set and prevents any new data from being added
into the RX FIFO, the OR bit is never cleared, and watermark read back
is always 0. If this condition occurs, the .tstc callback will always
report no new characters, and the OR bit will never be cleared, so the
U-Boot shell will be unresponsive until next reboot or kernel boot.
This is easy to trigger on MX95, power on the system and send traffic
on UART from host to the MX95, the MX95 FIFO will overflow and the
U-Boot console will become unresponsive.
Fix this by clearing the OR bit early, in .tstc callback. This way,
even if an overflow occurs, there will be slight loss of RX data, but
the U-Boot console will not become unresponsive.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The commit 076265b75e61 ("compat: regulator: add enable/disable macros")
added regulator_enable/disable() macros to provide a closer analogue to
the Linux API.
These new macros wrap regulator_set_enable() that may return detailed
error codes and should typically not directly be called by drivers.
Change the macros to wrap regulator_set_enable_if_allowed() that masks
error codes consumers typically do not expect to closer match the
behavior of the Linux API.
Also move the macros outside the #if #else blocks to make the macros
available when !CONFIG_IS_ENABLED(DM_REGULATOR).
Fixes: 076265b75e61 ("compat: regulator: add enable/disable macros")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Use CONFIG_IS_ENABLED() instead of IS_ENABLED() when checking the
MMC_IO_VOLTAGE symbol so the Kconfig option is evaluated correctly for
xPL builds.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The Rockchip RK3399 SoC SDMMC IO domain supports 1.8V and 3.0V mode, and
the 3.0V mode is within SD Standards allowed 2.7V-3.6V range. However,
the commit 0b75109b6aaf ("mmc: dw_mmc: return error for invalid voltage
setting") help enforce strict 1.8V and 3.3V when setting vqmmc-supply
making mmc_set_signal_voltage() now fail for MMC_SIGNAL_VOLTAGE_330 and
leading to an improper switch to MMC_SIGNAL_VOLTAGE_180.
Use regulator_set_value_clamp() to set an SD Standards voltage range,
1.70V-1.95V and 2.7V-3.6V, I/O voltage instead of requiring an exact
regulator value to closer match Linux and to fix use of 3.3V signal
voltage on Rockchip RK3399 boards using MMC_IO_VOLTAGE=y.
Fixes: 0b75109b6aaf ("mmc: dw_mmc: return error for invalid voltage setting")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add regulator_set_value_clamp() that clamps a requested target voltage
to both caller-provided limits and the regulator constraints before
setting the regulator voltage value.
Return -EINVAL when the caller limits cannot be satisfied by the
regulator constraints or when the requested range is invalid.
This helper will initially be used to set vqmmc-supply voltage within an
acceptable range according to SD Standards, i.e. 1.70V-1.95V and
2.7V-3.6V.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add a MAINTAINERS entry for the Cadence SDHCI driver files
(drivers/mmc/sdhci-cadence*). The original authors
(Masahiro Yamada <yamada.masahiro@socionext.com> and
Kuan Lim Lee <kuanlim.lee@starfivetech.com>) email addresses are no
longer reachable. Add myself as maintainer since I am actively
maintaining and developing these files.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Alexey Charkov <alchark@flipper.net> says:
Btrfs in U-boot currently uses a custom callback for ls and doesn't
expose the standard opendir/readdir/closedir interface, making it harder
to use in generic code. One area where this would be useful is in
discovering BLS type 1 entries [1] on a Btrfs filesystem.
Add support for the standard interface, and implement ls in terms of it.
[1] https://lore.kernel.org/u-boot/20260604-bls-v1-0-4ce6d1ee4711@flipper.net/
Link: https://lore.kernel.org/r/20260626-btrfs-readdir-v2-0-7dd43f72d1b4@flipper.net
|
|
Now that generic callbacks for opendir/readdir/closedir are implemented,
the custom btrfs_ls() implementation is no longer needed, along with the
btrfs_iter_dir() callback iterator.
Use fs_ls_generic() instead.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Qu Wenruo <wqu@suse.com>
|
|
Add support for generic directory iteration with opendir(), readdir() and
closedir() in the btrfs filesystem driver.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Qu Wenruo <wqu@suse.com>
|
|
do_zboot_setup() invokes zboot_setup() twice: once with proper error
reporting, and again immediately afterwards with no diagnostic. The
second call re-runs the entire boot parameter setup on the
already-populated zero page, which is at best wasted work and at
worst leaves the structure in an unexpected state.
Drop the stray second invocation; the first call already covers both
success and failure handling.
Fixes: cb19931ee56 ("x86: zboot: Drop intermediate zboot_setup() function")
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
|
|
do_upl_read() guards against missing arguments with "argc < 1", but
argc always counts argv[0] (the command name) so that condition is
never true. The function then unconditionally dereferences argv[1],
which is out of bounds when the user runs "upl read" with no address
argument and feeds garbage into hextoul()/map_sysmem().
Use "argc < 2" so the address argument is actually required.
Fixes: 264f4b0b34c ("upl: Add a command")
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
|
|
When the user runs "ini <section>" without explicit address or size
arguments, do_ini() falls back to env_get("loadaddr") and
env_get("filesize") and passes the results straight to hextoul().
env_get() returns NULL for an undefined variable and hextoul() does
not tolerate a NULL pointer, so on a board without these variables
set the command dereferences NULL.
Fetch the strings into locals first, reject the NULL case with
CMD_RET_USAGE, and only then convert to numeric values.
Fixes: c167cc02033 ("Add a new "ini" command")
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
|
|
do_host_unbind()'s error handler for device_unbind() prints the
misleading message "Cannot attach file" and then calls device_unbind()
a second time on the same device, both of which look like copy-paste
mistakes left over from neighbouring code.
Remove the duplicate device_unbind() call and report the correct
failure with the device name.
Fixes: 952018117ab ("dm: sandbox: Switch over to using the new host uclass")
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
|
|
The error path of the destination blk_dwrite() prints srcblk, which
refers to the source device's block counter and is unrelated to the
write that just failed. This produces misleading diagnostics that
point at the wrong block on the wrong device when a clone aborts on
a write error.
Print destblk so the message identifies the block that actually
failed, mirroring the existing "Src read error @blk %ld" message
above which correctly uses srcblk.
Fixes: 4a4830cf915 ("cmd: add clone command")
Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com>
|
|
Prevent NULL pointer dereference with lockstep mode.
Since commit 21d03d60e909 ("j7200 defconfig: add rproc commands"),
issuing rproc init command with cluster configured in lockstep results
in a NULL pointer dereference.
This is because ti_sci_proc_request() is called on both cores on the
same cluster, without checking if they are populated.
To fix that, only request the core being probed, as there is no need to
request the other one.
Moreover, the old code was requesting both cores in lockstep mode, but
only releasing one:
it called k3_r5f_proc_request() with ti_sci_proc_release(), instead of
using k3_r5f_proc_request()/k3_r5f_proc_release() or
ti_sci_proc_request()/ti_sci_proc_release().
So, replacing k3_r5f_proc_request() by ti_sci_proc_request() restores
the intended behavior.
Fixes: 21d03d60e909 ("j7200 defconfig: add rproc commands")
Signed-off-by: Richard Genoud (TI) <richard.genoud@bootlin.com>
|
|
U-Boot does not support modules, so having tristate options is useless.
Therefore this patch does a blind replace of all tristate options to
bool tree-wide.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Romain Gantois <romain.gantois@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip/-/pipelines/597
- Add new rockchip custodian,
- Remove inactive rockchip custodian,
- Preemptively fix rk3528/rk356x DTS issue that will come with 7.1
upstream DTS sync,
- Fix typo in doc,
- Fix variable used before being set in rockchip_nfc,
- Fix asm-operand-widths clang warning for RK3528, RK3576 and RK3588,
- Work around HW undefined state for NVMEs on RK3588 Jaguar,
- Added support for new devices:
- LinkEase EasePi R1
- 9Tripod X3568 v4
|
|
The 9Tripod X3568 v4 is an RK3568-based SBC, just like the RK3568-EVB.
It always uses soldered connections between the X3568CV2/X3568CV3/X3568CV4 core board
and the X3568bv4 I/O board.
The differences between the core boards
- PCB size, layout
- CPU (RK3568B2/RK3568J)
- Memory type (DDR4/LPDDR4/LPDDR4X) and size
- eMMC size
- DSI/EDP resistor values
Although the components vary, they maintain full compatibility.
The X3568 board has multiple hardware revisions, and we currently support v4 (I/O board).
Specification:
- SoC: RockChip RK3568 ARM64 (4 cores)
- eMMC: 16-128 GB
- RAM: 2-16 GB
- Power: DC 12V 2A
- Ethernet: 2x YT8521SC RGMII (10/100/1000 Mbps)
- Wireless radio: 802.11b/g/n/ac/ax dual-band
- LED:
Power: AlwaysOn
User: GPIO
- Button:
VOL+: SARADC/0 <35k µV>
VOL-: SARADC/0 <450k µV>
Power/Reset: PMIC RK809
- CAN
CAN/1: 4-pin (PH 2.0)
- PWM
PWM/4: Backlight DSI/0 DSI/1
PWM/7: IR Receiver [may not install]
- UART:
UART/2: Debug TTL - 1500000 8N1 (1.25mm)
UART/3: TTL (PH 2.0)
UART/4: TTL (PH 2.0)
UART/8: AP6275S Bluetooth
UART/9: TTL (PH 2.0)
- I2C:
I2C/0: PMIC RK809
I2C/1: Touchscreen DSI/0 DSI/1
I2C/4: Camera
I2C/5: RTC@51 PCF8563
- I2S:
I2S/0: miniHDMI Sound
I2S/1: RK809 Audio Codec
I2S/3: AP6275S Bluetooth Sound
- SDMMC:
SDMMC/0: microSD (TF) slot
SDMMC/2: AP6275S SDIO WiFi card
- Camera: 1x CSI
- Video: miniHDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP)
- Audio: miniHDMI / MIC on-board / Speaker / SPDIF / 3.5mm Headphones / AP6275S Bluetooth
- USB:
USB 2.0 HOST x2
USB 2.0 HOST x3 (4-pin)
USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST) [slot may not install]
USB 3.0 HOST x1
USB 3.0 OTG/HOST x1
- SATA: 1x SATA 3.0 with Power/4-pin [slot may not install]
- PCIe: 1x PCIe 3.0 x2 (x4 connector) [power/clock/slot may not install]
Link:
- https://appletsapi.52solution.com/media/X3568V4%E5%BC%80%E5%8F%91%E6%9D%BF%E7%A1%AC%E4%BB%B6%E6%89%8B%E5%86%8C.pdf
- https://blog.gov.cooking/archives/research-ninetripod-x3568-v4-and-flash.html
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260709185101.2149485-1-coiaprant@gmail.com
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
As it is, an NVMe's built-in PERSTN pull-up fights against the
SoC's built-in pull-down which results in an undefined logic state
on the Samsung SSD 980 and likely others.
Fix that by forcing PERSTN low as early as possible, which is SPL.
Both Linux and U-Boot (via "pci enum") set the pin high later
as needed and the NVMe is detected fine.
Oscillocope shots ("x" means undefined logic state at around 1.5V):
Before:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____xxxxxxxxxxxxxxx_|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
After:
3V3 ____|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
PERSTN ____x_______________|‾‾‾‾‾
PCICLK ____∿∿∿∿∿∿∿∿∿∿∿∿___∿∿∿∿∿∿∿
^U-Boot ^ Linux
With this change, the power-up sequence conforms to PCIe specs,
except a remaining short PERSTN glitch. The glitch is about 400ms
long. It could be shortened by moving the logic to TPL, but
completely fixing it is only possible in hardware.
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260625-pub-jaguar-puma-ringneck-tiger-v2025-07_nvme-v2-1-c57bf1020d63@cherry.de
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
CONFIG_COUNTER_FREQUENCY is currently 24000000 for all SoCs, meaning it
fits in a 32b type. For 64b SoCs, it's an issue since the registers are
64b.
clang complains that we're trying to fit a 32b value into a 64b
register:
arch/arm/mach-rockchip/rk3528/rk3528.c:98:45: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths]
98 | asm volatile("msr cntfrq_el0, %0" : : "r" (CONFIG_COUNTER_FREQUENCY));
| ^
include/generated/autoconf.h:372:34: note: expanded from macro 'CONFIG_COUNTER_FREQUENCY'
372 | #define CONFIG_COUNTER_FREQUENCY 24000000
| ^
/home/qschulz/work/upstream/u-boot/arch/arm/mach-rockchip/rk3528/rk3528.c:98:32: note: use constraint modifier "w"
98 | asm volatile("msr cntfrq_el0, %0" : : "r" (CONFIG_COUNTER_FREQUENCY));
| ^~
| %w0
Even though cntfrq_el0[1] is only using the 32b LSB of its 64b, use the
'x' operand modifier[2] to force the value to be 64b and fix the
warning.
[1] https://developer.arm.com/documentation/ddi0601/2026-03/AArch64-Registers/CNTFRQ-EL0--Counter-timer-Frequency-Register?lang=en
[2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#AArch64-Operand-Modifiers
Suggested-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://patch.msgid.link/20260423-rk35-cnt-freq-v1-1-8f07677be5ca@cherry.de
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
LinkEase EasePi R1 [1] is a high-performance mini router.
Specification:
- Rockchip RK3568
- 2GB/4GB LPDDR4 RAM
- 16GB on-board eMMC
- 1x M.2 key for 2280 NVMe (PCIe 3.0)
- 1x USB 3.0 Type-A
- 1x USB 2.0 Type-C (for USB flashing)
- 2x 1000 Base-T (native, RTL8211F)
- 2x 2500 Base-T (PCIe, RTL8125B)
- 1x HDMI 2.0 Output
- 12v DC Jack
- 1x Power key connected to PMIC
- 2x LEDs (one static power supplied, one GPIO controlled)
[1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html
Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
Link: https://patch.msgid.link/20260625125818.18914-2-jjm2473@gmail.com
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
The oobfree[0].length calculation depends on the
rknand->metadata_size value, but this is calculated
after the function rk_nfc_ecc_init is called. Move this
calculation to a location before it's value is required.
Fixes: 1b3fcb3c0456 ("mtd: nand: raw: rockchip_nfc: add layout structure")
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Tested-by: Hüseyin BIYIK <boogiepop@gmx.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/12b6e0d5-637e-446e-9e4b-82c82e6fad40@gmail.com
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
https://git.u-boot-project.org/u-boot/custodians/hs/u-boot-i2c
i2c updates for 2026.10-rc1
- i2c: designware: fix i2c probe error
from Coben
It would be good to have some Testers...
- i2c: nx_i2c: updates from Peng
- Added License information
- use dev_read_addr_ptr()
- cmd: kconfig: i2c: add missing I2C API dependency
from Julien
|
|
Use correct defconfig name for evb-rk3288-rk808.
Fixes: f339d6a9c3c2 ("rockchip: Switch remaining rk3288 boards to upstream devicetree")
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/d0f7ce27-ad87-4910-be25-e867b5af4956@gmail.com
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
The <soc>-u-boot.dtsi OTP nodes for RK3528/RK356x use different names
compared to the OTP nodes that was merged in Linux v7.1. This causes
build issues when dts/upstream pulls in updated DTs, i.e.:
ERROR (duplicate_label): /soc/nvmem@ffce0000: Duplicate label 'otp'
on /soc/nvmem@ffce0000 and /soc/efuse@ffce0000
ERROR (duplicate_label): /nvmem@fe38c000: Duplicate label 'otp'
on /nvmem@fe38c000 and /efuse@fe38c000
Align the OTP node names in <soc>-u-boot.dtsi with the node names used
in upstream Linux v7.1 to avoid build issues when latest DTs are synced.
Also drop the unused RK356x id@a subnode as it has moved under a
nvmem-layout node in the merged upstream DT.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260707100918.3057718-1-jonas@kwiboo.se
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
Kever has been pulled into different responsibilities at Rockchip and
this means he has less to no time for his maintainership in U-Boot as
has been seen for about a year now. Let's try to improve the situation
and have Rockchip-related things merged again by adding myself as
another maintainer.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-12-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
Philipp hasn't been active for years so we thank Philipp for his work
over the years and update the MAINTAINERS entry to reflect the reality.
Reviewed-by: Tom Rini <trini@konsulko.com>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-11-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
rockusb is a Rockchip feature, so let's match *anything* with that in
the path.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-10-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
A few drivers are not using "rockchip" in their path so they aren't
currently detected by get_maintainer.pl as belonging to the ARM ROCKCHIP
entry, so let's fix that oversight by adding them individually. We could
use N: rk_ but I feel this isn't distinctive enough to avoid too many
false positive and I don't want to be keeping a list of things to not
match against.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-9-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
rkmtd is a Rockchip feature, so let's match *anything* with that in the
path.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-8-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
Rockchip has an RV11xx SoC series (RV1103, RV1106, RV1126) so let's
match *anything* in U-Boot which contains this string in the path and
not only the U-Boot Device Trees.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-7-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
Rockchip also manufactures PMICs and regulators typically under the
RK8xx naming scheme (e.g. RK806, RK808, RK860, etc.) so let's match
files with rk8 in their path.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-6-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
Most Rockchip SoCs have their name start with rk3xxx. Historically, the
second digit is for the generation of SoC, e.g. rk31xx was before
rk32xx, itself before rk33xx and now rk35xx (and the expected rk36xx end
of this year). We won't talk about the rk30xx timeline but it's also
prefixed the same way. So let's match *anything* in U-Boot which
contains rk3 in the path to simplify the MAINTAINERS entry and hopefully
catch as much as possible.
board/firefly/ and board/pine64/ only contain subdirectories and each of
them have rk3 in their name.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-5-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
PX5 is a Rockchip SoC, so let's match *anything* in U-Boot which
contains this string in the path. However, this matches a bit too much,
specifically the PPC-based kmsupx5_defconfig so we need to exclude it
explicitly.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-4-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
PX30 is a Rockchip SoC, so let's match *anything* in U-Boot which
contains this string in the path.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-3-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
|
It is a tool to be used with Rockchip SoCs so let's add it to the
MAINTAINERS entry for ARM ROCKCHIP.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260707-rk-custodian-v1-2-dbc9c696e613@0leil.net
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
|
