| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/20260625-pub-jaguar-puma-ringneck-tiger-v2025-07_nvme-v2-1-c57bf1020d63@cherry.de
Signed-off-by: Quentin Schulz <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Mikhail Kshevetskiy <[email protected]> says:
This patch series add pin controller and gpio driver support for EN7523/
AN7581/AN7583 SoCs. The driver based on official linux airoha pinctrl
and gpio driver with Matheus Sampaio Queiroga changes.
The original Matheus Sampaio Queiroga driver can be taken from the repo:
https://sirherobrine23.com.br/airoha_en7523/kernel/src/branch/airoha_en7523_pinctrl
Additionally in the EN7523 case the patches removes existing gpio dts
nodes and replaces them with pinctrl node. It should not be very
dangerous, because:
* No official EN7523 gpio support present in U-Boot
* Legacy Linux EN7523 GPIO driver is mostly abandoned
* The same driver is planned for upstream linux/openwrt
This patchset includes bitfield.h patches created for Linux kernel by
Geert Uytterhoeven. It suits U-Boot fine. I preserve original author and
original commit messages. Please note me, if there is a better way.
The patches were tested on EN7523/AN7581/AN7583 boards.
Link: https://lore.kernel.org/r/[email protected]
|
|
This patch adds pinctrl/gpio dts nodes for airoha pinctrl driver.
It also removes legacy gpio nodes.
It should not be very dangerous, because:
* No official EN7523 gpio support present in U-Boot
* The same driver is planned for upstream linux/openwrt
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
Reviewed-by: David Lechner <[email protected]>
|
|
Fix indentation issues where spaces were used instead of tabs in several
ZynqMP device tree overlay files. Device tree files should use tabs for
indentation to maintain consistency with the kernel coding style.
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/0dc7b65ebd48676719ace15a505ecec2f324822a.1782726386.git.michal.simek@amd.com
|
|
Add missing newline available in Linux already.
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/ab6f006ee87efb54ee17f24a12c9f31aafc2f2ae.1782726386.git.michal.simek@amd.com
|
|
ina226 IIO driver doesn't need to be enabled by default in Linux that's why
disable iio-hwmon nodes to avoid warnings about it.
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/deb2e92d5030a31dbb91b36fa77de3ad2de38a71.1782726386.git.michal.simek@amd.com
|
|
Add fixed RTC clock nodes at 32.768 kHz for ZynqMP. The RTC driver uses
this clock to calculate the calibration value, replacing the deprecated
calibration device tree property.
Signed-off-by: Harini T <[email protected]>
Reviewed-by: Tomas Melin <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/8838c8c4fcd0dfe151bcee2a6c4da51df81e23cb.1782726386.git.michal.simek@amd.com
|
|
zynqmp_mmio_read() and zynqmp_mmio_write() selected between direct MMIO
and the firmware (PM_MMIO_READ/WRITE) interface with an in-function
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) / current_el() check. Generic arch
code should not carry firmware-specific ifdefs, and with SCMI the access
method changes again.
Split the accessors like the multiboot and bootmode hooks: the weak
default in arch/arm/mach-zynqmp does the direct MMIO access (used in SPL,
at EL3 and when no firmware is present), while firmware-zynqmp.c provides
a strong definition that issues the firmware call and falls back to the
direct access in SPL/EL3 where the SMC path is unavailable. The raw MMIO
primitives zynqmp_mmio_rawread() and zynqmp_mmio_rawwrite() are exported
for the shared fallback, and the read-modify-write helper now uses the
raw read instead of routing through the firmware-aware accessor.
The firmware-vs-MMIO decision is selected at link time, so adding SCMI
later only requires a third strong definition with no changes to generic
code.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/d532df144d2c8e34be835bad6d0de3b26befdf01.1782219202.git.michal.simek@amd.com
|
|
versal_net_get_bootmode() open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl() in board code. Like
the Versal change, move the whole function behind an overridable hook so
generic board code stays free of firmware specifics and is ready for
SCMI.
The weak versal_net_get_bootmode() in arch/arm/mach-versal-net does the
plain MMIO read via versal_net_bootmode_reg() and decodes it (used at EL3
and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/be67e9c6d0bc36840a46594413886d2003967c64.1782219202.git.michal.simek@amd.com
|
|
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal-net where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/8757111cb254543d61541fb030d51f62c3c555a8.1782219202.git.michal.simek@amd.com
|
|
soc_detection() and soc_name_decode() read the PMC_TAP version/idcode
registers and decode the platform. This is SoC information rather than
board policy, and a firmware interface could provide it instead, so it
does not belong in board code.
Move both functions, together with the shared platform_id and
platform_version state, into arch/arm/mach-versal2 where they still
override the weak stubs in the Xilinx common board code. The board file
drops the now unused linux/bitfield.h include.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/c332ab27f66f1c808f32a4bcb453d9e8da543331.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the system timestamp counter directly
with readl()/writel() in board code. This is SoC register setup rather
than board policy, and similar code exists across the Xilinx SoCs.
Move it into zynqmp_timer_setup() in arch/arm/mach-zynqmp so the board
hook only keeps the EL3 guard and calls the helper. The asm/arch/clk.h
include (for zynqmp_get_system_timer_freq()) moves to cpu.c along with
the code.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/2d8f2419fab314b4ff8fd53b846e1dd6151586d3.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_net_timer_setup() in arch/arm/mach-versal-net so the
board hook only keeps the EL3 guard and calls the helper.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/10dd9f35d03be0402ce13475f20b2cd3761189a6.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal2_timer_setup() in arch/arm/mach-versal2 so the board
hook only keeps the EL3 guard and calls the helper.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/08e835a183c39de6f666375ac390eee6a8f3f12e.1782219202.git.michal.simek@amd.com
|
|
board_early_init_r() programmed the IOU switch clock and the system
timestamp counter directly with readl()/writel() in board code. This is
SoC register setup rather than board policy, and the same block is
duplicated across the Xilinx SoCs.
Move it into versal_timer_setup() in arch/arm/mach-versal so the board
hook only keeps the EL3 guard and calls the helper.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/2234d746ab5b8240e88b1a629d51f93751ee3b60.1782219202.git.michal.simek@amd.com
|
|
versal_get_bootmode() lived in board code and open-coded the
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call
zynqmp_pm_get_bootmode_reg() and a direct readl(). To keep generic board
code free of firmware specifics and SoC register details and ready for
SCMI, move the whole function, including the alt-shift and mask decoding,
behind an overridable hook.
The weak versal_get_bootmode() in arch/arm/mach-versal does the plain
MMIO read via versal_bootmode_reg() and decodes it (used at EL3 and
without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled,
firmware-zynqmp.c provides a strong definition that reads the register
through the firmware call, falling back to the direct read at EL3 where
the SMC path to firmware is unavailable. This preserves the existing
firmware-based bootmode behaviour while removing the firmware interface
from board code; the now unused zynqmp_firmware.h include is dropped.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/d60073feed8da8d3aff9eabee6ab132e0bbd0f8e.1782219202.git.michal.simek@amd.com
|
|
versal_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal_multi_boot_reg() so the firmware override does not duplicate it.
versal_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface for the multiboot register. The firmware-vs-MMIO decision is
selected at link time, and adding SCMI later only requires a third strong
definition with no board-code changes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/199ef6a1411c54f154fe4a43b5fef166b9927f7a.1782219202.git.michal.simek@amd.com
|
|
versal2_get_bootmode() lived in board code and accessed the CRP boot
mode register with a direct readl(). To keep generic board code free of
SoC register details and ready for firmware/SCMI based access, move the
whole function, including the alt-shift and mask decoding, into
arch/arm/mach-versal2 as a __weak default.
Board code now simply calls versal2_get_bootmode(). When a firmware
based implementation is available and tested it can provide a strong
definition that overrides the weak one at link time; until then only the
weak MMIO version is built.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/f3274ec77218373bc0452f6795a3ad6016be0058.1782219202.git.michal.simek@amd.com
|
|
versal2_multi_boot() in board code selected between the firmware call
zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an
IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not
carry firmware-specific ifdefs, and this becomes harder to maintain once
SCMI introduces yet another access method.
Introduce an overridable accessor versal2_pmc_multi_boot(). The weak
default lives in arch/arm/mach-versal2 and performs the plain MMIO read
(used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE
is enabled, firmware-zynqmp.c provides a strong definition that issues the
firmware call, falling back to the direct read at EL3 where the SMC path
to firmware is unavailable. The shared MMIO read is factored into
versal2_multi_boot_reg() so the firmware override does not duplicate it.
versal2_multi_boot() keeps the generic JTAG/QEMU workaround and simply
calls the accessor, so board code no longer references the firmware
interface and the now unused zynqmp_firmware.h include is dropped. The
firmware-vs-MMIO decision is selected at link time, and adding SCMI later
only requires a third strong definition with no board-code changes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/0033a1fa8efb4ae0c3ac6a6f5c5c1b4e0f22f02c.1782219202.git.michal.simek@amd.com
|
|
The Versal and Versal Gen 2 mach sys_proto.h headers lacked an include
guard. mach-versal/sys_proto.h additionally defines enum tcm_mode, so
including it twice in one translation unit fails to build with a
redeclaration error.
This is about to happen in firmware-zynqmp.c, which needs the SoC
prototypes unconditionally for the upcoming weak/strong multiboot and
bootmode accessors. Add the standard _ASM_ARCH_SYS_PROTO_H guard, as
already used by mach-zynqmp, so the header can be included more than once.
Signed-off-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/1bf5b1d49abb271c2c5e7135837b740179b95553.1782219202.git.michal.simek@amd.com
|
|
AM011 Versal ACAP TRM, Table 43, defines:
- 0x006_0000_0000 - 0x007_FFFF_FFFF PCIe region 1
- 0x008_0000_0000 - 0x00F_FFFF_FFFF DDR controller 0 region 1
- 0x040_0000_0000 - 0x04F_FFFF_FFFF HBM0
- 0x050_0000_0000 - 0x05F_FFFF_FFFF HBM1
- 0x060_0000_0000 - 0x06F_FFFF_FFFF HBM2
- 0x070_0000_0000 - 0x07F_FFFF_FFFF HBM3
- 0x080_0000_0000 - 0x0BF_FFFF_FFFF PCIe region 2
- 0x0C0_0000_0000 - 0x0FF_FFFF_FFFF DDR controller 0 region 2
The old static normal-memory mapping spans PCIe, while DDR coverage is
already populated later from the DRAM banks discovered by mem_map_fill().
Drop the stale static mapping so the MMU table matches the Versal address
map. Also matting was using wrong attributes.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/6fad36f9e7abdfee2fd29943f3a5b63d1421eaf9.1781179823.git.michal.simek@amd.com
|
|
DDR coverage is already populated later from the DRAM banks discovered by
mem_map_fill(). Drop the stale static mappings so the MMU table matches
address map more closely.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/156e48d8228acfeba8866618038b48cd51490ea7.1781179823.git.michal.simek@amd.com
|
|
There is no reason to have non zynqmp-sc compatible string for overlays
which can be applied only with SCs.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/4192927ae769e74e4ddbc1cc9814ed0305b64a5d.1780991287.git.michal.simek@amd.com
|
|
The "label" property is not documented for the dlg,slg7xl45106. Nor is
it common to use for GPIO controllers. So drop it.
Signed-off-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/32c5b160de5b8e5ffb91366cbafac0b5fd5c834a.1780991287.git.michal.simek@amd.com
|
|
Fix descriptions that don't match their filenames:
- zynqmp-sc-vpk180-revB.dtso: described as revA instead of revB
- zynqmp-sck-kv-g-revB.dtso: described as revA instead of revB
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/456e4ff541c60355aa3d35627ec481263113349e.1780991287.git.michal.simek@amd.com
|
|
Add fixed supply regulators for the onboard USB hub (USB2744) used on
Kria platforms.
The USB hub requires two always-on power rails:
- vdd: 3.3V main supply
- vdd2: auxiliary supply
Model these rails as fixed regulators and reference them from the hub
node to accurately describe the hardware.
Signed-off-by: Shaikh Mohammed Suhan <[email protected]>
Reviewed-by: Radhey Shyam Pandey <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/541ee484c0f73fda630022528ddc56d01a481bca.1780991287.git.michal.simek@amd.com
|
|
Add CMA (Contiguous Memory Allocator) reserved-memory regions to all
Xilinx arm64 board device trees to support runtime FPGA programming.
The CMA pool uses dynamic allocation constrained to the low 2 GB DDR region
via alloc-ranges so that the kernel places it within the 32-bit addressable
space.
CMA sizes are chosen per silicon family to accommodate the maximum PL
bitstream/PDI size:
- Kria K24 SOM: 64 MB
- ZynqMP boards: 128 MB
For Kria K24 SOM the CMA inherited from K26 is overridden to 64 MB.
For Kria SOMs, the CMA node is added to the SOM DTS only, not to
carrier board overlays.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/837e21582e886f1be9f95901109745ac5a8b2a25.1780991287.git.michal.simek@amd.com
|
|
Describe flash and NAND MTD partitions using the fixed-partitions
compatible under a dedicated partitions subnode. U-Boot only creates
slave MTD devices from this binding in add_mtd_partitions_of(), so
mtd list can show named partitions.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/a9e72b2c62e1b2e5c485302a861e5bae55ec2b83.1780991287.git.michal.simek@amd.com
|
|
The #phy-cells property is meant for generic PHY providers
(Documentation/devicetree/bindings/phy/phy-bindings.txt) and is not a
valid property for ethernet-phy nodes. Its presence triggers a
dt-validate warning:
ethernet-phy@x (ethernet-phy-id001c.c816): Unevaluated properties
are not allowed ('#phy-cells' was unexpected)
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/d50e4ed12227609f3f827acde885c1d37782b8a9.1780991287.git.michal.simek@amd.com
|
|
Enable nvmem support for MAC address retrieval from EEPROM for
ethernet@ff0b0000.
Add nvmem-cells and nvmem-cell-names to the GEM0 node, and define a
mac-address@20 cell under the EEPROM node on I2C0.
This allows U-Boot to read the MAC address from EEPROM at offset 0x20.
Signed-off-by: Trapti Damodar Balgi <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/49490b1d510f27f47e71e86c7d1f29478111ef81.1780991287.git.michal.simek@amd.com
|
|
Update the gpio-line-names property to reflect the latest GPIO mapping,
including PMOD and VCCO labels.
Signed-off-by: Trapti Damodar Balgi <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/c204b6474c821a0b46b94fa87ee69a6693fd8686.1780991287.git.michal.simek@amd.com
|
|
|
|
In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Vishal Mahaveer <[email protected]> says:
Collecting SYSFW traces from DMSC firmware is broken on the current
codebase. These changes enables MAIN_UART1 for collecting SYSFW traces
when the trace option is enabled in the boardcfg.
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable MAIN UART1 in the R5 SPL device tree to collect system SYSFW
debug traces during early boot.
Signed-off-by: Vishal Mahaveer <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
The upstream device tree changed the serial alias for MAIN UART1 from
serial3 to serial1. Update the board initialization code to match this
change by modifying the UCLASS_SERIAL sequence number lookup.
This ensures proper pin control configuration for the UART used by
system firmware (SYSFW).
Signed-off-by: Vishal Mahaveer <[email protected]>
Fixes: d2edabfa8de5 ("arm: mach-k3: am642: Load SYSFW binary and config from boot media")
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
The commit 55a342176984 ("common: Add an option to relocate on ram top")
changed so that dram_init_banksize() is called before gd->ram_top has
been initialized. This change broke Rockchip DRAM banks configuration
due to gd->ram_top now being 0 when dram_init_banksize() is called.
This makes first DRAM bank size calculation overflow and end up with
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0xffffffffffe00000
instead of the expected (for 2 GiB)
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0x000000007fe00000
or (for 4 GiB)
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0x00000000f7e00000
on e.g. RK3399 boards.
Change to not depend on gd->ram_top having to be pre-calculated before
dram_init_banksize() is called, also move the related method
board_get_usable_ram_top() closer to more easily get an overview of
their interdependence, to restore working DRAM bank initialization.
Fixes: 55a342176984 ("common: Add an option to relocate on ram top")
Signed-off-by: Jonas Karlman <[email protected]>
Reported-by: Ilias Apalodimas <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]> # on Radxa ROCK
|
|
Ryan Chen <[email protected]> says:
AST2700 is the 8th generation of Integrated Remote Management
Processor introduced by ASPEED Technology Inc. It is a Board
Management Controller (BMC) SoC family with a dual-die architecture:
SoC0 ("CPU" die with four ARM Cortex-A35 application cores) and
SoC1 ("IO" die with peripherals) each SoC have its own SCU PLLs,
clock dividers and reset domains.
Link: https://lore.kernel.org/r/[email protected]
|
|
Set the acpi_ops structure as static const where applicable. The
The structure is not accessible from outside of drivers and is not
going to be modified at runtime. The structure may be unused in a
couple of drivers depending on their configuration, mark those
sites with __maybe_unused .
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a SDRAM controller driver for the AST2700, derived from the
existing AST2700 controller code used by the Ibex SPL but adapted
to run from ARM U-Boot proper on the Cortex-A35 cores.
The DDR4/DDR5 controller and its DesignWare PHY are programmed by
the Ibex SPL before ARM U-Boot proper takes over. This driver
reads back the configuration left by the SPL, probes the
controller, and exposes ram_info (base and size, with the VGA
carve-out subtracted) via UCLASS_RAM so that dram_init() can
populate gd->ram_size.
The PHY firmware-load entry points (dwc_ddrphy_phyinit_userCustom_*)
are kept compiled but call a __weak fmc_hdr_get_prebuilt() stub
when ARM U-Boot proper is the caller; the real implementation is
provided by the Ibex SPL via the same fmc_hdr.h descriptor format
(here added for the ARM build).
Adds the supporting register-layout headers under
arch/arm/include/asm/arch-aspeed/:
- sdram.h: SDRAM controller and DWC PHY register definitions
- scu.h: SCU bits referenced by the SDRAM driver
- fmc_hdr.h: prebuilt-blob descriptor (binary-compatible with
arch/riscv/include/asm/arch-ast2700/fmc_hdr.h used
by the Ibex SPL)
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add initial device tree support for the ASPEED AST27xx family, the
8th-generation Baseboard Management Controller (BMC) SoCs.
AST27xx SOC Family
- https://www.aspeedtech.com/server_ast2700/
- https://www.aspeedtech.com/server_ast2720/
- https://www.aspeedtech.com/server_ast2750/
The AST27xx features a dual-SoC architecture consisting of two ties,
referred to as SoC0 and SoC1 - interconnected through an internal
property bus. Both SoCs share the same address decoding scheme,
while each maintains independent clock and reset domains.
- SoC0 (CPU die): contains a dual-core Cortex-A35 cluster and two
Cortex-M4 cores, along with high-speed peripherals.
- SoC1 (I/O die): includes the BootMCU (responsible for system
boot) and its own clock/reset domains low-speed peripherals.
The device tree describes the SoC0 and SoC1 domains and their peripheral
layouts.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add initial support for the ASPEED AST2700, an arm64 (Cortex-A35)
Baseboard Management Controller (BMC) SoC. AST2700 is Aspeed's 8th
generation BMC and uses a dual-die architecture: SoC0 (the "CPU"
die) hosts the four Cortex-A35 cores and its own SCU at 0x12c02000,
while SoC1 (the "IO" die) hosts the peripherals and its own SCU at
0x14c02000.
This commit adds:
- ASPEED_AST2700 Kconfig option and the ast2700 mach subdir
(mach Makefile, ast2700/Kconfig, board/aspeed/evb_ast2700/*)
- arm64 MMU map covering the SoC device window and the DRAM
region at 0x4_0000_0000 (up to 8 GiB)
- lowlevel_init.S for early CPU bring-up
- cpu-info: print SoC ID (AST2700/2720/2750 A0/A1/A2 variants)
and reset cause (cold reset, EXT reset, WDT reset)
- board_common: dram_init via UCLASS_RAM, AHBC timeout init
- platform: env_get_location() that selects SPI/eMMC based on
the IO-die HW strap; arch_misc_init() that exposes
${boot_device} and ${verify} to the boot script
- SCU0/SCU1 register layout header (scu_ast2700.h)
- configs/evb-ast2700_defconfig and include/configs/evb_ast2700.h
for the AST2700 EVB board
The defconfig depends on ast2700-evb.dts, which is introduced in
a subsequent patch; this commit must be applied with the
remaining series for evb-ast2700_defconfig to build.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add v2x_status and ele_info commands to print useful information
for development and debug purpose.
Signed-off-by: Ye Li <[email protected]>
|
|
Add V2X Get State API to return V2X states for debug purpose
Signed-off-by: Ye Li <[email protected]>
|
|
The LDB clock sources don't have to be the same, so allow DI1 clock to
be configured separately.
Unlikely to be significant, but the reason will become apparent in the
following commit.
Signed-off-by: Brian Ruley <[email protected]>
|
|
During development or various dangerous experiments, it may
be necessary to override the trip points. Allow users to do
that. However, do keep in mind that this may damage the SoC.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add initial U-Boot support for Aquila iMX95 SoM.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: Franz Schnyder <[email protected]>
Reviewed-by: Francesco Dolcini <[email protected]>
|
