The Q7 standard specifies a usb-id pin on the connector to distiuish
between host and device mode. Model this via the usb-id extcon binding.
While the pin is part of the Q7 standard, so part of the module, the
extcon stays disabled in the som dtsi and will only be enabled in a
baseboard using it.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20240422163951.2604273-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: eabb53f5dacfd643b5255f35bad30b8f914decdc ]
(cherry picked from commit 4843cec4092318ef7feb0999b0d34ef817465b33)
gpio_pwrctrl2 gets duplicated by both rk806_dvs1_null and rk806_dvs2_null
gpio_pwrctrl1 is unset. This typo appears in multiple files. Let's fix them.
Note: I haven't had the chance to test them all because I don't own all
of these boards (obviously). Please test if it's needed.
Signed-off-by: Jing Luo <jing@jing.rocks>
Link: https://lore.kernel.org/r/20240420130355.639406-1-jing@jing.rocks
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: d7f2039e5321636069baa77ef2f1e5d22cb69a88 ]
(cherry picked from commit cb2b6d1d19ed10fcaec5f5859c08a3355d1c66e0)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Ringneck was mistakenly set to allow up to 128KiB for the TPL code size
while PX30 SoC only has 16KiB of SRAM.
Therefore, let's use the default value of TPL_MAX_SIZE from the SoC
(which is 10KiB) so that the max code size is actually checked and
useful.
Fixes: c925be73a0 ("rockchip: add support for PX30 Ringneck SoM on Haikou Devkit")
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The ID of the PMIC is stored in the 2 16b registers but the only part
that matters right now is the 3 MSB, which make the 3 digits (in hex) of
the part number.
Right now, only RK808 was properly displayed, with this all currently
supported PMICs should display the proper part number.
Additionally, when the PMIC variant is not found, print that value
instead of the masked unshifted value as all PMICs we support for now
have their LSB ignored to represent the actual part number.
Tested on RK806 (RK3588 Jaguar), RK808 (RK3399 Puma) and RK809 (PX30
Ringneck).
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
On px30-ringneck the FIT payload is located at sector 0x200 compared to
the more Rockchip common sector 0x4000 offset:
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
Because FIT payload is located at sector 0x200 and the TPL+SPL is
located at sector 64, the combined size of TPL+SPL cannot take up more
than 224KiB:
(0x200 - 64) x 512 = 0x38000 (224 KiB)
Adjust SPL_PAD_TO to match the used 0x200 sector offset.
While at it, update the px30-ringneck-u-boot.dtsi to remove the now
unnecessary override of simple-bin:fit:offset since SPL_PAD_TO matches
with the current formula.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Since commit 6007b69d54 ("rockchip: rk3399-puma: Update SPL_PAD_TO
Kconfig option"), SPL_PAD_TO matches
(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512 and the default
value for simple-bin:fit:offset in rockchip-u-boot.dtsi is
SPL_PAD_TO, so let's remove this override.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
CONFIG_ENV_OFFSET already defaults to 0x3F8000, however it is stored in
lowercase hexdigits instead of uppercase like in the defconfig.
No change in behavior intended.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The default env size is 0x8000 when building for Rockchip SoCs with
support for environment stored in MMC.
Jaguar hasn't entered mass production just yet, so it's a breaking
change we can afford in the name of consistency.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
ArmSoM Sige7 is a Rockchip RK3588 based SBC (Single Board Computer) by
ArmSoM.
There are two variants depending on the DRAM size : 8G and 16G.
Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB memory LPDDR4x
Mali G610MC4 GPU
2x MIPI CSI 2 multiple lanes connector
64GB/128GB on board eMMC
uSD slot
1x USB 2.0 Type-A, 1x USB 3.0 Type-A, 1x USB 3.0 Type-C
1x HDMI 2.1 output
2x 2.5 Gbps Ethernet port
40-pin IO header including UART, SPI and I2C
USB PD over USB Type-C
Size: 92mm x 62mm
Kernel commit:
81c828a67c78 (arm64: dts: rockchip: Add ArmSom Sige7 board)
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The mmu600_pcie is connected with the five PCIe controllers.
The mmu600_php is connected with the USB3 controller, the GMAC
controllers, and the SATA controllers.
See 8.2 Block Diagram, in rk3588 TRM (Technical Reference Manual).
The IOMMUs are disabled by default, as further patches are needed to
program the SID/SSIDs in to the IOMMUs.
iommu: Default domain type: Translated
iommu: DMA domain TLB invalidation policy: strict mode
arm-smmu-v3 fc900000.iommu: ias 48-bit, oas 48-bit (features 0x001c1eaf)
arm-smmu-v3 fc900000.iommu: allocated 65536 entries for cmdq
arm-smmu-v3 fc900000.iommu: allocated 32768 entries for evtq
arm-smmu-v3 fc900000.iommu: msi_domain absent - falling back to wired irqs
Additionally, the IOMMU correctly triggers an IOMMU fault when
a PCIe device performs a write (since the device hasn't been
assigned a SID/SSID):
arm-smmu-v3 fc900000.iommu: event 0x02 received:
arm-smmu-v3 fc900000.iommu: 0x0000010000000002
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
While this doesn't provide much value as is, having the devices as
disabled in the device tree will allow developers to see that the rk3588
actually has IOMMUs on the SoC.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240502140231.477049-2-cassel@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: cd81d3a0695cc54ad6ac0ef4bbb67a7c8f55d592 ]
(cherry picked from commit ea9a34aa0d786cbf4b87f1ba528e69b07219738f)
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Migrate PX30/RK3326 boards that exists in Linux v6.8 to use OF_UPSTREAM.
firefly-px30 is not migrated to OF_UPSTREAM because there's no Device
Tree in the Linux kernel.
Differences between U-Boot's Odroid-Go2 and Linux's are now moved to the
-u-boot.dtsi, though I have a gut feeling that the existing cru
overrides aren't necessary (anymore?).
The U-Boot GPIO led-0 is on GPIO0_C1 but such is the pin of PWM3 which
is used for Linux's PWM led-2 so keep Linux's.
I also doubt vcc_cam is actually used, though the Odroid-Go2 Black
Edition uses this dcdc regulator for WiFi, so let's just move it to the
-u-boot.dtsi to play it safe.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
In the Device Tree, UART5 is the system UART, but in the defconfig it
currently is UART2. Let's sync the two by making the defconfig use UART5
as well.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
In order to be able to properly mux UART on PX30 EVB, the pinmux needs
to be done at runtime, so let's not remove the pinctrl nodes from the
SPL DTB.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This adds the default pinmux for UART2 and UART5 to the TPL/SPL DTB (if
not removed through the CONFIG_OF_SPL_REMOVE_PROPS symbol) as those two
controllers are always made available to all boards.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
U-Boot proper pre-reloc is currently running out of memory on PX30
Ringneck and it is thus impossible to boot into U-Boot CLI. It is
assumed the same problem can be seen on other PX30 boards though I
cannot guarantee it since I don't have access to them.
Fix this by migrating to the common bss and stack addresses for PX30,
which drastically increases the size of the pre-reloc allocation pool (8
times bigger now). The memory layout in SPL and U-Boot proper now
match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
R5 being a 32-bit processor can't understand the 64-bit mapping being
done in ospi node. Override the ospi node for 32-bit register ranges and
the fss node ( the parent node of ospi ) to map the ranges for the
updated child node correctly.
Reviewed-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
On DTR capable flashes like Micron Xcella the writes cannot start or end
at an odd address in DTR mode. Extra 0xff bytes need to be prepended or
appended respectively to make sure both the start and end addresses are
even.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Pull request efi-next-20240611
UEFI:
* Allow specifying a device-tree in an EFI load option
using the efidebug or eficonfig command.
* Let the EFI boot manager fall back to an OS provided device-tree
if no device-tree is specified.
As we now also store device-tree device-paths in load options rename
struct efi_initrd_dp to efi_lo_dp_prefix.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
If no device-tree is specified, try to load a device-tree from the boot
device use the $fdtfile concatenated to either of the paths '/dtb/', '/',
'/dtb/current/'.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
For finding distro supplied device-trees we need to know from which device
we are booting. This can be identified via the device-path of the binary.
Up to now efi_dp_from_lo() only could return the initrd or fdt device-path.
Allow returning the binary device-path, too.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We allow to specify the triple of binary, initrd, and device-tree in boot
options.
Add the code to actually load the specified device-tree.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We already support creating a load option where the device-path
field contains the concatenation of the binary device-path and
optionally the device path of the initrd which we expose via the
EFI_LOAD_FILE2_PROTOCOL.
Allow to append another device-path pointing to the device-tree
identified by the device-tree GUID.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We already support creating a load option where the device-path
field contains the concatenation of the binary device-path and
optionally the device path of the initrd which we expose via the
EFI_LOAD_FILE2_PROTOCOL.
Allow to append another device-path pointing to the device-tree
identified by the device-tree GUID.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Allow appending a device-path to a device-path that contains an end node
as separator. We need this feature for creating boot options specifying
kernel, initrd, and dtb.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary.
I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below. These changes have been check via https://github.com/u-boot/u-boot/pull/538.
Feedback is welcome.
Signed-off-by: Kalen Brunham <kalen.brunham@intel.com>
Quote from [1]:
"For devices launching with Android 13, the generic ramdisk is removed
from the boot image and placed in a separate init_boot image.
This change leaves the boot image with only the GKI kernel."
While at it, update wrong error handling message when vendor_boot
cannot be loaded.
[1]: https://source.android.com/docs/core/architecture/partitions/generic-boot
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
The boot_ramdisk and vendor_ramdisk must be both concatenated together.
Without this change, Android root is missing some of the necessary tools
to complete virtual AB OTA.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
commit 6e2228fb05 ("Merge patch series "Clean up arm linker scripts")
was cleaning up linker scripts for armv7 and v8 but was leaving
_end and __secure_stack_start/end.
commit d0b5d9da5d ("arm: make _end compiler-generated")
was moving _end to be compiler generated. _end is defined as c variable
in its own section to force the compiler emit relative a reference.
However, defining those in the linker script will do the same thing
since [0].
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols.
It's worth noting that _image_binary_end symbol is now redundant and
can be removed in the future.
- SPL
The .end section has been removed from the new binary
[ 5] .end
PROGBITS 00000000fffdf488 000000000002f488 0
0000000000000000 0000000000000000 0 1
[0000000000000003]: WRITE, ALLOC
$~ bloat-o-meter kria_old/spl/u-boot-spl krina_new/spl/u-boot-spl
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new delta
Total: Before=115980, After=115980, chg +0.00%
$~ readelf -sW kria_old/u-boot kria_new/u-boot | grep -w _end
12047: 000000000813a0f0 0 OBJECT GLOBAL DEFAULT 11 _end
12047: 000000000813a118 0 NOTYPE GLOBAL DEFAULT 11 _end
$~ readelf -sW kria_old/spl/u-boot-spl kria_new/spl/u-boot-spl | grep -w _end
1605: 00000000fffdf488 0 OBJECT GLOBAL DEFAULT 5 _end
1603: 00000000fffdf498 0 NOTYPE GLOBAL DEFAULT 4 _end
$~ readelf -sW old/u-boot new/u-boot | grep -w _end
8847: 0000000000103710 0 OBJECT GLOBAL DEFAULT 11 _end
8847: 0000000000103738 0 NOTYPE GLOBAL DEFAULT 11 _end
$~ readelf -sW old_v7/u-boot new_v7/u-boot | grep -w _end
10638: 000da824 0 OBJECT GLOBAL DEFAULT 10 _end
10637: 000da84c 0 NOTYPE GLOBAL DEFAULT 10 _end
- For both QEMU instances
$~ bloat-o-meter old/u-boot new/u-boot
add/remove: 0/0 grow/shrink: 1/0 up/down: 20/0 (20)
Function old new delta
version_string 50 70 +20
Total: Before=656915, After=656935, chg +0.00%
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When decompressing, it's possible that the algorithm only performs
a partial decompression.
This usually happens when CONFIG_SYS_BOOTM_LEN is too small for
the uncompressed image.
When that happens, image_decomp() returns an error and *load_end == load.
The error is then handled by handle_decomp_error().
handle_decomp_error() expects the number of uncompressed bytes in
uncomp_size but receives *load_end - load == load - load == 0.
Because of this, handle_decomp_error does not report the expected
"Image too large: increase CONFIG_SYS_BOOTM_LEN" error message.
Modify the image_decomp() logic to always report the decompressed size,
even when a partial decompression happened.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
