Wadim Egorov <w.egorov@phytec.de> says:
Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.
Apply overlays for phyCORE-AM62x and phyCORE-AM64x SoMs.
Future K3 SoMs will be able to reuse this logic and overlays.
Link: https://lore.kernel.org/r/20241030164815.1763506-1-w.egorov@phytec.de
Include SoM dt-overlays for DT control so we can include them
into our u-boot FIT image.
While at it also resync after savedefconfig.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Sometimes this breaks, so add a build to keep it working. Since sandbox
enables a lot of options, it is a good board to use. The new config is
created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to
run those tests.
Create a new build which will be picked up by CI. Update the maintainer
entry as well.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
The lib_test_uuid_to_le and lib lib_test_dynamic_uuid tests fail on
32-bit systems. But we never caught this in our CI because we never
ran any of our C unit tests on 32-bit.
Enable CONFIG_UNIT_TEST on qemu_arm_defconfig.
hextoul() cannot convert a string to a 64-bit number on a 32-bit system.
Use the new function hextoull() instead.
Link: https://lore.kernel.org/r/20241103224223.195255-1-heinrich.schuchardt@canonical.com
The lib_test_uuid_to_le test fails on 32-bit systems. But we never caught
this in our CI because we never ran any of our C unit tests on 32-bit.
Enable CONFIG_UNIT_TEST on qemu_arm_defconfig.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
QEMU already has an lwip variant of a defconfig. That defconfig
is also configured with mbedTLS by default. So let's enable the
remaining config options to enable wget for https:// as well
and test that codepath in the CI
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add manufacturing environment into STM32MP15xx DH electronics DHSOM
configuration. This environment is part of every board build, but only
takes effect on systems booted with the dh,stm32mp15xx-dhcor-testbench
device tree, i.e. systems populated with factory build of U-Boot.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Deduplicate defconfigs for all DH STM32MP1xx DHSOM systems by factoring
out the common parts into generic stm32mp_dhsom.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all DH STM32MP1xx DHSOM systems.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Deduplicate defconfigs for all DH STM32MP15xx DHSOM systems by factoring
out the common parts into generic stm32mp15_dhsom.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all DH STM32MP15xx DHSOM systems.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Use RTC available in HW on Kria SOM without using emulation that's why
configure it properly and disable emulated one.
Power on reset value of RTC Calibration register without battery backup is
not matching with crystal frequency which leads to RTC time drift. That's
why write CALIB_WRITE register with crystal frequency (0x7FFF). There is
also an option to write zero so that Linux will set default value (0x7FFF)
in driver probe but calibration 0 is not permited by DT schema.
Co-developed-by: Srinivas Goud <srinivas.goud@amd.com>
Signed-off-by: Srinivas Goud <srinivas.goud@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/9b684faeec85381b9b8fe796aaebc2ee79f17b8e.1729663761.git.michal.simek@amd.com
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is
provided in the TPL Device Tree, this will trigger a system reset
similar to what's currently been done in SPL whenever the RK3399 "warm"
boots. Because there's currently only one user of sysreset-gpio logic,
and TPL is enabled on that board, so let's migrate the logic and that
board to do it in TPL.
There are three reasons for moving this earlier:
- faster boot time as we don't need to reach SPL to be able to reset the
system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works
around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from
SPL, the following log can be observed:
"""
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
Channel 0: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
Channel 1: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
256B stride
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100)
Trying to boot from MMC2
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
"""
possibly hinting at an issue within the SPL when loading the fitImage
from MMC2 instead of the normal course of events (a system reset).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Disable DISPLAY_BOARDINFO_LATE as the early boardinfo print of Model
should be enough.
U-Boot 2025.01-rc1 (Nov 02 2024 - 16:04:16 +0000)
Model: Generic RK3566/RK3568
DRAM: 8 GiB (effective 7.7 GiB)
Core: 250 devices, 24 uclasses, devicetree: separate
MMC: mmc@fe2b0000: 1, mmc@fe310000: 0
Loading Environment from nowhere... OK
In: serial@fe660000
Out: serial@fe660000
Err: serial@fe660000
Model: Generic RK3566/RK3568
Hit any key to stop autoboot: 0
=>
Enable CMD_MISC to make it easier to inspect data in OTP.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The FriendlyElec NanoPi R2S Plus is a single-board computer based on
Rockchip RK3328 SoC. It features e.g. 1 GB DDR4 RAM, 32 GB eMMC,
SD-card, 2x GbE LAN, optional M.2 SDIO Wi-Fi and 2x USB 2.0 host.
Features tested on a NanoPi R2S Plus 2309:
- SD-card boot
- eMMC boot
- Ethernet
- USB gadget
- USB host
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add support for Cool Pi GenBook, it works as a carrier board
connect with CM5 SOM.
Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080
Tested by Armbian boot on USB disk.
Change-Id: I4d9b8572dc7c400077dde666633f3fea1b47dd03
Signed-off-by: Andy Yan <andyshrk@163.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Qnap TS433 is a 4-bay NAS based around the RK3568.
Two SATA bays are connected to the RK3568's own SATA controllers while
the other two are connected to a JMicron SATA controller living on the
PCIe bus.
It provides one 2.5Gb and one 1Gb ethernet port as well as 3 usb ports.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
For upstream Linux kernel we use below DTBs for HiHope boards:
- r8a774a1-hihope-rzg2m-ex.dtb
- r8a774e1-hihope-rzg2h-ex.dtb
- r8a774b1-hihope-rzg2n-ex.dtb
Update the CONFIG_OF_LIST to match the above. Now that we have switched
upstream DTS, drop deleting the nodes and also rename the
r8a774*-u-boot.dtsi files to r8a774*-ex-u-boot.dtsi to match the OF_LIST
files so that the `bootph-all` property gets applied to required nodes
in upstream DTS.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Currently we set CONFIG_SYS_MMC_ENV_DEV=1 which is wrong:
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default environment
This issue was introduced when we switched to using upstream Linux device
trees for the hihope boards which named the MMC devices differently.
Correct to dev 0 so that the U-Boot environment can be loaded from the
correct storage device.
Fixes: 18fb23b131 ("ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs")
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Enable OF_UPSTREAM to use upstream DT and add nxp/imx/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Signed-off-by: Marek Vasut <marex@denx.de>
The commit 7576ab2fac ("riscv: Add support for AMD/Xilinx MicroBlaze V")
added support for 32bit version. 64bit version is also available that's why
wire it up too.
DT is providing description for generic QEMU target.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Align smode defconfig with upstream QEMU. It could be the part of commit
9d688e6da5 ("riscv: mbv: Align DT with QEMU").
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
To restore MMC boot, enable SPL_SYS_MMCSD_RAW_MODE and recover
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION.
Fixes: 2a00d73d08 ("spl: mmc: Try to clean up raw-mode options")
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Leo Yan <leo.yan@arm.com> says:
This patch series is to refine the booting on Arm Total Compuate
platform.
It changes to use the info passed in DTB for initialization DRAM info,
and dynamically initializes the booting envoironment variables.
Another big change is to use an envoironment file for boot commands,
based on it, the series extends to support multiple block devices
(MMC and virtio). And the env file is extended for booting Debian.
The last commit is to update memory mapping info based on the DRAM info
passed via DT binding.
Link: https://lore.kernel.org/r/20241025171821.624702-1-leo.yan@arm.com
The boot command for Total Compute has many aspects and changes from time
to time. So move it to an .env file where it can be a proper script.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Deduplicate common Renesas defconfig by factoring out the common
parts into generic renesas_rcar_defconfig and including those using
the #include <configs/...> preprocessor macro in the current set of
board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config are
identical for all Renesas systems.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Deduplicate defconfigs for all Renesas R-Car 64bit systems by factoring
out the common parts into generic renesas_rcar64.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all Renesas R-Car 64bit systems.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Deduplicate defconfigs for all Renesas R-Car Gen4 systems by factoring
out the common parts into generic renesas_rcar4.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all Renesas R-Car Gen4 systems.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Deduplicate defconfigs for all Renesas R-Car Gen3 systems by factoring
out the common parts into generic renesas_rcar3.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all Renesas R-Car Gen3 systems.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Deduplicate defconfigs for all Renesas R-Car Gen2 systems by factoring
out the common parts into generic renesas_rcar2.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all Renesas R-Car Gen2 systems.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Emcraft Systems NavQ+ kit is a mobile robotics platform
based on NXP i.MX8 MPlus SoC.
The following interfaces and devices are enabled:
- eMMC
- Gigabit Ethernet (through eQOS interface)
- SD-Card
- UART console
The device tree file is taken from upstream Linux Kernel
through OF_UPSTREAM
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Jan Kiszka <jan.kiszka@siemens.com> says:
This adds support for the new IOT2050 SM variant, introduces a sysinfo
driver which also permits SMBIOS support and switches the board to
OF_UPSTREAM. There are some further fixes for the boards included as well.
Not yet included is configuration support for DMA isolation via the PVU as
this depends on not yet merged DT bindings and another overlay.
[trini: This is just the first 10 patches in the series for now]
Link: https://lore.kernel.org/r/cover.1729577070.git.jan.kiszka@siemens.com
Main differences between the new variant and Advanced PG2:
1. Arduino interface is removed. Instead, an new ASIC is added for
communicating with PLC 1200 signal modules.
2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
available.
3. DP interface is tailored down. Instead, to communicate with the
PLC 1200 signal modules, a USB 3.0 type B connector is added but the
signal is not USB.
4. DDR size is increased to 4 GB.
5. Two sensors are added, one tilt sensor and one light sensor.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
[Jan: rebased over OF_UPSTREAM]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up the devicetree rework that is in progress at [1].
Link: https://lore.kernel.org/all/20241002-private-unequal-33cfa6101338@spud/ [1]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Align U-Boot with QEMU amd-microblaze-v-virt platform to be able to wire
it with CI.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Padmarao Begari <padmarao.begari@amd.com>
This requires some tweaking of the defconfig and
board_fit_config_name_match so that the new sources are taken into
account.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
We can simply use the default DT, Basic PG1, because no nodes that are
different between the variants play a role for SPL. Will help with the
migration to OF_UPSTREAM.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
When moving from vendor U-Boot to the upstream U-Boot it is necessary to
reset the environment.
Provide the 'env erase' sub-command.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Enable GPIO command and DWAPB_GPIO driver for LicheePi4A board.
Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
Add support for Arm sbsa [1] v0.3+ that is supported by QEMU [2].
Unlike other Arm based platforms the machine only provides a minimal
FDT that contains number of CPUs, ammount of memory and machine-version.
The boot firmware has to provide ACPI tables to the OS.
Due to this design a full DTB is added here as well that allows U-Boot's
driver to properly function. The DTB is appended at the end of the U-Boot
image and will be merged with the QEMU provided DTB.
In addition provide documentation how to use, enable binman to fabricate both
ROMs that are required to boot and add ACPI tables to make it full compatible
to the EDK2 reference implementation.
The board was tested using Fedora 40 Aarch64 Workstation. It's able
to boot from USB and AHCI or network.
Tested and found working:
- serial
- PCI
- xHCI
- Bochs display
- AHCI
- network using e1000e
- CPU init
- Booting Fedora 40
1: Server Base System Architecture (SBSA)
2: https://www.qemu.org/docs/master/system/arm/sbsa.html
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Rename 'ahci_mvebu' to 'ahci_generic' and select it by default.
The AHCI driver contains no SoC specific code and only expects the
base address to be passed, thus rename it to ahci_generic and add the
DT compatible string "generic-ahci".
Update existing defconfigs to use the new Kconfig name as well.
TEST: Booted on QEMU sbsa using the generic-ahci node.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>
Acked-by: Tony Dinh <mibodhi@gmail.com>
Update defconfig to enable features included in pending upstream DT and
implement board_fit_config_name_match() to load correct DT for LTS and
non-LTS version of the NanoPC-T6.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
