The R35 rotation edit used PUT 77.=77 against a stale line number and
overwrote CONFIG_USB=y with a duplicate VIDEO block, leaving the USB
menuconfig unset: no USB controller, no usb command, no keyboard.
Restore CONFIG_USB=y (deduplicate VIDEO) and verify the full USB set
in .config after the defconfig re-run.
Also flip the console rotation from 1 (90 degrees clockwise) to 3
(270 degrees clockwise): rot=1 read upside down on the device with
the keyboard attached.
The BOE TV101WUM-NL6 panel is mounted rotated 270 degrees in the
krane chassis (rotation property on the panel node in the upstream
DT). With the keyboard attached the tablet is used in landscape, so
set video rot=1 and enable CONFIG_CONSOLE_ROTATION: the uclass then
binds the rotated vidconsole1 driver, which writes glyphs rotated by
90 degrees clockwise into the native 1200x1920 portrait scanout and
uses the swapped console geometry (240 columns x 75 rows).
The framebuffer geometry and the depthcharge scanout path are
unchanged; only the console text placement rotates.
DM scans only the immediate subnodes of a bound node; recursion into
children happens when a bound bus driver runs dm_scan_fdt_dev. Nothing
in U-Boot binds the "mediatek,mtu3" ssusb@11201000 node, so its xhci
child (usb@11200000) was never bound, no UCLASS_USB device existed and
usb start() reported "No USB controllers found".
Add "simple-mfd" to the ssusb compatible in the -u-boot.dtsi overlay
so the generic simple-bus driver binds the node and scans its children.
The pogo keyboard is a USB HID device behind the GL610 hub on
usb@11200000. Enable the USB stack (USB, DM_USB, USB_XHCI_HCD,
USB_XHCI_MTK, USB_STORAGE, CMD_USB), the MTK T-PHY (PHY_MTK_TPHY),
USB_KEYBOARD and CONFIG_USE_PREBOOT (preboot defaults to "usb start"
with USB_KEYBOARD) so the bus is enumerated before the prompt.
The upstream mt8183.dtsi models the SSUSB block for the Linux mtu3
dual-role driver: the IPPC register space and the phys live on the
parent mtu3 node while the xhci child has only its "mac" register.
U-Boot binds the "mediatek,mtk-xhci" child directly and expects
mac+ippc and a phys list on that node, so add a board
-u-boot.dtsi overlay (auto-included after the upstream dts) that
supplies them. No upstream DT files are modified.
stdin=serial,usbkbd routes the prompt through the USB keyboard once
the usb_kbd stdio device is registered.
Diagnostic only, to be reverted before upstreaming: board_early_init_f
(orange), dram_init_banksize (blue), board_early_init_r (red) paint
bands into the depthcharge scanout to localize the early crash.
Add a display driver for the MT8183 kukui family of ChromeOS devices
(e.g. the Lenovo IdeaPad Duet, google,krane), where the display
pipeline is already initialized and running when the payload is
handed off by depthcharge. depthcharge's display_cleanup() stops the
overlay engines and turns the backlight off before the jump, so the
driver only revives the pipeline: it re-enables the OVL0 engines
(OVL_EN @ +0x000c and OVL0_2L_EN @ +0x100c, offsets from depthcharge's
device-era mtk_ddp.c), drives the backlight GPIOs high (DISP_PWM,
pin 43, and EN_LCD_BL, pin 176, through the GPIO controller dout block
at 0x10005000+0x100), and renders the console into the live scanout
surface.
The geometry comes from the coreboot table framebuffer record, which
sits at the fixed kukui address 0xffed9000; when its physical_address
is 0 (what upstream coreboot 4.14 publishes on kukui), the live
scanout address is taken from the OVL layer 0 address register
(+0x0f40), which the firmware leaves in place across the handoff.
The driver binds to the existing ovl0 device tree node
(mediatek,mt8183-disp-ovl) and requires no display initialization.
Device trees imported from Linux (dts/upstream) include their
dt-bindings headers from dts/upstream/include, but the dtc preprocessor
search order places U-Boot's legacy in-tree include/ first. When a SoC
has both a legacy dt-bindings header (used by non-upstream in-tree
device trees) and an upstream one, the legacy copy shadows the upstream
one and silently misresolves the clock/reset/power macros whose
numbering changed between generations.
Prefer dts/upstream/include when building with CONFIG_OF_UPSTREAM. The
upstream imported device trees are written against the upstream
bindings, and no current OF_UPSTREAM user builds legacy in-tree device
trees.
Add support for the Lenovo IdeaPad Duet (google,krane sku176), an
MT8183 ChromeOS tablet from the kukui family. The board boots through
coreboot + depthcharge, which load U-Boot as an arm64 Image at an
arbitrary 2 MiB-aligned DRAM slot; keep CONFIG_POSITION_INDEPENDENT
like the pumpkin target.
The board shares the pumpkin's board file, renamed to mt8183.c since it
is generic for the SoC. The defconfig uses the upstream devicetree from
dts/upstream (CONFIG_OF_UPSTREAM) and drops the pumpkin-specific USB
gadget/fastboot support for now.
SWIG 4.5.0 removed Python 2 compatibility macros (PyInt_*, PyString_*)
from its runtime header pyhead.swg (see commit 79f7a2b7cb7d). Replace
them with their Python 3 C API equivalents:
- PyString_FromString -> PyUnicode_FromString
- PyString_AsString -> PyBytes_AsString
- PyInt_AsLong -> PyLong_AsLong
The replacements are safe since the macros were already aliased to
these exact functions in SWIG's Python 3 code path.
This is a backport of dtc commit 5008d1d6a356 ("pylibfdt: Replace
removed SWIG Python 2 compatibility macros").
Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
Reviewed-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
Tested-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
With commit 607d45d1e3 ("power: pmic: tps65219: fail if regulators
node is missing"), the driver requires the PMIC node to have regulator
nodes.
Since we don't have bootph tags in the regulator child nodes, the
resulting DTB doesn't have any regulator child nodes for the SPL phase
leading to boot failures. Therefore this patch explicitly adds the
bootph-all tag to all regulator nodes for the beagleplay.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
The uclass_get_device() return-value check was inverted, resulting in a
synchronous abort when -ENODEV was returned.
Signed-off-by: Graeme Smecher <gsmecher@t0.technology>
Reviewed-by: Simon Glass <sjg@chromium.org>
AMD/Xilinx changes for v2026.10-rc3
Versal Gen 2:
- Add support for 2VM3654 device
- Add missing MAINTAINERS fragment
AMD:
- Fix fwu dfu_string generation not to alter with generic DFU
Firmware/ufs:
- UFS interface cleanup
- Remove ZynqMP firmware dependency from UFS
zynqmp_gqspi:
- Fix quad mode bus conflict
MB-V:
- shrink SPL size and enforce size limits
- remake ELF from BIN
dhcp_fine_tmr() was called every 10ms, but lwIP expects it to be
called every DHCP_FINE_TIMER_MSECS (500ms).
Since the fine timer ticks are currently 50 times faster than lwIP
expects, the client burns through the bounded exponential backoff
sequence for the DHCPREQUEST messages in 2.44 seconds rather than 122
seconds, after which it uses a new xid and returns to sending
DHCPDISCOVER messages. If there is enough latency in the server, the
client could receive an ACK response within DHCP_TIMEOUT_MS (10
seconds), but reject it because it has already moved on with another
xid after 2.44 seconds.
We have seen this occur with our boards. When our rack of 16 boards
get powered on together, they all request for an address from the
network switch's DHCP server in near lock-step and we see that only a
few of the boards actually obtain a lease. Fixing the timing to 500ms
allowed all of the boards to obtain a lease consistently.
Fixes: 98ad145db6 ("net: lwip: add DHCP support and dhcp commmand")
Signed-off-by: Luca Jones <ljones@t0.technology>
The M-PHY and SRAM readiness poll loops move out of the UFS controller
driver and into the firmware backend, exposed as blocking waits with
a caller-owned timeout budget. This keeps the UFS driver backend-agnostic
and lets an other backends offload the wait to the platform in a single
call instead of round-tripping every poll.
set_sram_bypass() now performs the SRAM_CSR read-modify-write in the
firmware layer.
Hook up functions are also update to reflect their usage.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/26bc9aa2c02921690e126ab3401f7974ef04ad6e.1785394153.git.michal.simek@amd.com
Move the controller/PHY reset and SRAM-bypass sequence from
hce_enable_notify(PRE_CHANGE) into ufs_versal2_init().
The reset sequence releases the host controller from reset, and the UFS
core reads the capability and version registers right after .init() and
before ufshcd_hba_enable() (the only caller of hce_enable_notify()).
Doing the reset in .init() ensures those registers are read after the
controller is out of reset, and keeps the driver aligned with Linux.
ufs_versal2_phy_init() stays in POST_CHANGE.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/6b4cbfa6cc58bef86da86971e4b27726a4e510f0.1785394153.git.michal.simek@amd.com
Setup BOARD_SIZE_LIMIT to 128KB (131072 bytes) for ZynqMP mini/qspi
configurations and enable CONFIG_SKIP_RELOCATE as there is no need
for relocation.
For configurations running from OCM (xilinx_zynqmp_mini_defconfig and
xilinx_zynqmp_mini_qspi_defconfig), move TEXT_BASE from 0xFFFC0000 to
0xFFFE0000. The initial 128KB of OCM (0xFFFC0000-0xFFFDFFFF) is used
for data buffer.
Memory layout in OCM (256KB total):
- 0xFFFC0000 - 0xFFFDFFFF: Data buffer (128KB)
- 0xFFFE0000 - 0xFFFFFFFF: U-Boot code + stack (128KB)
- TEXT_BASE at 0xFFFE0000 (code grows up)
- EARLY SP at 0xFFFE0000 (stack grows down)
EARLY SP is released when new stack location is calculated before U-Boot
prompt that's why no conflict with Data buffer location.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/6d91337d971fa9e22f6f57371f8bc656ea6bb4a3.1784722595.git.michal.simek@amd.com
Starting the GENFIFO after each CMD and ADDR entry creates a gap
between the address phase (TX) and data phase (RX). For read commands
without dummy cycles, the controller is still driving DQ2/DQ3 HIGH
when the flash switches to output mode, causing a bus conflict.
Split the GENFIFO helper into a write-only variant and a
start-and-wait variant. Queue CMD, ADDR and dummy entries without
starting the GENFIFO. The data phase appends its entry and starts
the queued sequence, keeping the address-to-data transition
continuous.
Since genfifo_cmd() no longer triggers after each entry, operations
without a data phase have no trigger path. Call start_gen_fifo()
from exec_op() before deasserting chip select to execute the queued
CMD and ADDR entries.
Fixes: 22cca1730e ("spi: zynqmp_gqspi: Add support for ZynqMP qspi driver")
Signed-off-by: Suraj Kakade <suraj.hanumantkakade@amd.com>
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260709083757.1851446-1-suraj.hanumantkakade@amd.com
Commit 371a6c1744 ("board: xilinx: Add capsule and FWU support") and
commit 818c06faa1 ("board: amd: Add capsule and FWU support")
introduced a separate set_dfu_alt_info() for the FWU multi-bank case
(Versal and Versal Gen 2 respectively) which set the dfu_alt_info
environment variable directly, while configure_capsule_updates() handled
the non-FWU case by filling update_info.dfu_string.
Fold the FWU multi-bank generation (fwu_gen_alt_info_from_mtd() over the
nor0 MTD partitions) into fwu_platform_hook() and drop the
standalone set_dfu_alt_info().
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/33c118b8177f8d0dc182a6f4c5cffedca4e02448.1782986903.git.michal.simek@amd.com
The GIC redistributor base address depends on the part: the 2VM3654
device has 4 APU cores and 3 GIC ITS blocks, which shifts the
redistributor region up compared to the base 8 core / single ITS part.
A single U-Boot binary must therefore pick the right base at runtime
instead of relying on the compile-time GICR_BASE used by the generic
lowlevel_init().
Add a SoC specific lowlevel_init() that reads the PMC TAP IDCODE and
selects GICR_BASE_2VM3654 for the 2VM3654 device, otherwise keeps the
default GICR_BASE. CONFIG_ARMV8_MULTIENTRY is not supported on Versal
Gen 2 so the generic slave handling is intentionally dropped.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/4c0dc2b6e29d300db15be0844879ab4d028d98a9.1783493630.git.michal.simek@amd.com
The register address and bootmode defines in this header are useful from
early assembly (e.g. lowlevel_init reading PMC_TAP_IDCODE), but the file
could not be included from .S because the C-only declarations were not
guarded.
Reorder the header so all plain address/value defines are visible to both
C and assembly, and move every C-only construct (the linux/bitops.h
include, the register structs, the base pointer-cast macros and the
platform enum) into a single #ifndef __ASSEMBLY__ block.
No functional change for C consumers.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/de4de47ea457b285c5870e7ba25b4baf554561e7.1783493630.git.michal.simek@amd.com
Rockchip SoCs can automatically switch between jtag and sdmmc based on
the following rules:
- all the SDMMC pins including SDMMC_DET set as SDMMC function in GRF,
- force_jtag bit in GRF is 1,
- SDMMC_DET is low (no card detected),
Note that the BootROM may mux all SDMMC pins in their SDMMC function or
not, depending on the boot medium that were tried.
Because SDMMC_DET pin is not guaranteed to be used as an SD card card
detect pin, it could be low at boot or even switch at runtime, which
would enable the jtag function and render the SD card unusable.
Or boards using cd-gpios may switch the SDMMC_DET pin to GPIO function,
which would enable the jtag function and render the SD card unusable.
With commit d0a838bdc6 ("Subtree merge tag 'v7.1-dts' of dts repo [1]
into dts/upstream") there are now RK3576 boards that have changed to use
cd-gpios for the SDMMC_DET pin, e.g. NanoPi R76S, that may have issues
detecting SD card unless force_jtag is disabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260803184314.2240153-3-jonas@kwiboo.se
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
Hardware of various vendors, but very notably Rockchip, often uses
32-bit registers where the upper 16-bit half of the register is a
write-enable mask for the lower half.
Add hw_bitfield.h with two macros: FIELD_PREP_WM16, and
FIELD_PREP_WM16_CONST. The latter is a version that can be used in
initializers, like FIELD_PREP_CONST.
Import hw_bitfield.h from Linux commit 21368fcbb124 ("bitmap: introduce
hardware-specific bitfield operations"), first introduced in v6.18-rc1.
This contains two changes compared to the Linux version:
- include of linux/limit.h was dropped
- use of const_true() in FIELD_PREP_WM16_CONST() was dropped
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Link: https://patch.msgid.link/20260803184314.2240153-2-jonas@kwiboo.se
Signed-off-by: Quentin Schulz <u-boot@0leil.net>
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/946
- Add support for vendor protocol IDs 0x81 for SCMI
- Fix LDO selector boundaries and make the driver fail gracefully when
the
- regulators DT node is absent for TPS65219 PMIC/Regulator:
- Fix a hotplug issue with pci_iommu_extra on Layerscape platforms for
PCIe Layerscape.
- Fix a GIC LPI table corruption on LS1028A boards with 2 GiB of RAM
caused by an unbounded TF-A DRAM bank loop and an integer underflow
when gd->arch.resv_ram is inadvertently left at zero due to empty DRAM
banks.
- Also includes a minor DT cosmetic cleanup.
The TF-A DRAM bank setup currently assumes that the number of
banks reported by TF-A matches the number of entries available in
gd->bd->bi_dram[]. Limit the loop by CONFIG_NR_DRAM_BANKS so that
a platform with fewer configured DRAM banks does not write past the
array.
The reserved RAM setup also checks higher DRAM banks before falling
back to bank 0. When a higher bank is empty and board_reserve_ram_top()
returns 0, the old test succeeds for a zero-sized bank. This can set
gd->arch.resv_ram to 0.
On systems with CONFIG_GIC_V3_ITS this value is later used by
ls_gic_rd_tables_init() to place the GIC LPI tables:
gd->arch.resv_ram - GIC_LPI_SIZE
If gd->arch.resv_ram is 0, the subtraction underflows and the GIC LPI
tables are placed at an invalid high address.
Skip empty banks when selecting the reserved RAM area and fail GIC LPI
table setup if no reserved RAM address was established.
This fixes LS1028A systems with 2 GiB of RAM, where TF-A reports only
one populated DRAM bank.
Tested on an LS1028ARDB with TF-A modified to report 2 GiB of RAM, and
on a custom LS1028A-based board equipped with 2 GiB of RAM.
Signed-off-by: Patryk Biel <pbiel7@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Fix typo in enum scmi_config_type in include/scmi_protocols.h.
The enum value SCMI_PIN_DEFUALT was misspelled and should be
SCMI_PIN_DEFAULT to match the correct English spelling. This fixes
potential compilation issues and improves code clarity for any code
that references this enum value
Fixes: 0cb160f1b6 ("scmi: pinctrl: add pinctrl driver for SCMI")
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
According to the TPS65219 datasheet, selectors 0x38 through 0x3f
saturate at 3.4 V for LDO1 and LDO2.
For LDO3 and LDO4, selectors 0x00 through 0x0c saturate at
1.2 V, while selectors 0x36 through 0x3f saturate at 3.3 V.
The driver currently uses 0x56, 0x12, and 0x54 as selector boundary
values. These values do not match the selector boundaries defined by
the datasheet.
Use the correct selector boundary values of 0x38, 0x0c, and 0x36
for interpolation.
Fixes: b5cfa0c7ca ("power: add driver for the TPS65219 PMIC")
Signed-off-by: Kumara Bhimeswararao Matsa <bhimesh.matsa@gmail.com>
Acked-by: Maarten Brock <maarten.brock@sttls.nl>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
We can have many pci hotplug groups, each introduced
by a "pci@<addr>" token such as,
pci_iommu_extra=pci@0x3600000,1.0.0,hp,pci@0x3700000,1.0.0,hp,
pci@0x3800000,1.0.0,hp,pci@0x3900000,1.0.0,hp
Without this fix, we have the error:
Added iommu map for hotplug 1.0.0
ERROR: invalid action in extra iommu entry
ERROR: invalid action in extra iommu entry
ERROR: invalid action in extra iommu entry
Fixes: 2a5bbb13cc ("pci: layerscape: add a way of specifying additional iommu mappings")
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
vhaudiquet
Jaipaul CheernamandTom Rini
Anshul DalalandTom Rini
Graeme SmecherandJerome Forissier
Luca JonesandJerome Forissier
Michal Simek
Sandeep Gundlupet RajuandMichal Simek
Suraj KakadeandMichal Simek
Jonas KarlmanandQuentin Schulz
Patryk BielandPeng Fan
Udit KumarandPeng Fan
Kumara Bhimeswararao MatsaandPeng Fan
Vincent JardinandPeng Fan