summaryrefslogtreecommitdiff
path: root/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
AgeCommit message (Collapse)Author
2023-04-12dm: dts: Convert driver model tags to use new schemaSimon Glass
Now that Linux has accepted these tags, move the device tree files in U-Boot over to use them. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2023-01-18rockchip: Support building the all output files in binmanSimon Glass
Add the required binman images to replace the Makefile rules which are currently used. This includes subsuming: - tpl/u-boot-tpl-rockchip.bin if TPL is enabled - idbloader.img if either or both of SPL and TPL are enabled - u-boot.itb if SPL_FIT is enabled - u-boot-rockchip.bin if SPL is used, either using u-boot.itb when SPL_FIT is enabled or u-boot.img when it isn't Note that the intermediate files are dropped with binman, since it producing everything in one pass. This means that tpl/u-boot-tpl-rockchip.bin is not created, for example. Note that for some 32-bit rk3288 boards, rockchip-optee.dtsi is included. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-12-19rockchip: puma: fix GPT table corruption when saving U-Boot environmentQuentin Schulz
The GPT table is taking the first 34 sectors, which amounts to 0x4400 bytes. Saving the environment below this address in storage will corrupt the GPT table. While technically the table ends at 0x4400, some tools (e.g. bmaptool) are rounding everything to the logical block size (0x1000), so it is safer to make it point to 0x5000 so that the environment could still persist when flashing a sparse image with bmaptool or similar tools. Obviously, the default 0x4000 environment size does not work anymore, so let's set it to 0x3000 so it does fill the gap between the GPT table (rounded to 0x1000) and the start of the idbloader.img. Fixes: 56f580d3eb8d ("rockchip: dts: rk3399-puma: put environment (in MMC/SD configurations) before SPL") Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2022-10-19rockchip: puma-rk3399: migrate to u-boot-rockchip-spi.binQuentin Schulz
Now that a single binary containing TPL/SPL correctly formatted for SPI flashes and U-Boot proper, can be generated by binman, let's do it. Also update the documentation to tell the user to use this newly generated file instead of manually generating and flashing the binaries. Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2022-10-19rockchip: puma-rk3399: migrate to u-boot-rockchip.binQuentin Schulz
The offset of the SPL payload on Puma is different than for other Rockchip devices in that it is stored at offset 256K instead of much further away in the MMC. Flashing one binary instead of two at different offsets is much more user friendly so let's migrate to it by modifying the offset in the Puma specific Device Tree. Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2022-10-19rockchip: puma-rk3399: migrate to TPLQuentin Schulz
Depending on the toolchain used to compile the SPL for Puma RK3399-Q7 module, the board does not boot because the resulting binary is too big to fit in SRAM. Let's add a TPL so that there's no need to fiddle with or hack the defconfig to have a working bootloader. This follows what's been done for the majority of other RK3399-based boards. See the original commit for the first migrations: bdc00080111f "rockchip: rk3399: update defconfig for TPL" Unfortunately, the offset in SPI-NOR for U-Boot proper needs to be modified, since the move from SPL to TPL+SPL for idbloader.img (and the "only the first 2KB per 4KB blocks are written" "hack" for rkspi format) increased the size above 256KB. Let's move it to 512KB to, hopefully, be safe. Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2022-10-19rockchip: puma-rk3399: allow non-SD-Card-loaded SPL to load U-Boot proper ↵Quentin Schulz
from SD-Card Trying to load U-Boot proper from SPL when SPL was not loaded from SD-Card is currently not working because the SDMMC pins aren't muxed correctly. It is assumed the BootROM is doing this for us when booting from SD-Card hence why it's not needed when booting TPL/SPL from SD-Card. The pinctrl properties are removed from the SPL DT property removal list and the pinctrl configuration nodes made available in the SPL DT, in addition to the pull-up configurations to allow loading U-Boot proper from SD-Card as a fallback mechanism for SPI-NOR and eMMC. Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2022-10-19rockchip: puma-rk3399: use gpio-hog instead of fixed-regulator for enabling ↵Quentin Schulz
eMMC/SPI-NOR On Haikou devkit, it is possible to disable eMMC and SPI-NOR to force booting from SD card or USB via rkdeveloptool by toggling a switch. This switch needs to be overridden in software to be able to access eMMC and SPI-NOR once the device has booted from SD Card. Puma SoM can override this pin via gpio3_d5. Until now, fixed regulator device was abused to model this, but since there's now support for GPIO hogs, let's use it. Since we want to be able to boot the SPL from SD Card but give it the ability to load U-Boot proper from a fallback medium such as eMMC and SPI-NOR, SPL support for GPIO hogs needs to be enabled too. Support for other kinds of regulators are not needed anymore, so let's disable them. Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2021-03-30rockchip: rk3399-puma: Restore correct VDD_LOG supply.Christoph Muellner
A commit from last year re-imported the DTS files form the upstream kernel. By doing so the VDD_LOG regulator in the board's DTS was dropped. Let's restore this, but move it into the u-boot overlay to prevent this issue in the future. Fixes: 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux") Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2021-01-21rockchip: puma-haikou: default to SPI bus 1 for SPI-flashHugh Cole-Baker
SPI flash on this machine is located on bus 1, default to using bus 1 for SPI flash and stop aliasing it to bus 0. Formerly the alias spi1 pointed to &spi5, use an alias spi5 for this instead. Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com> Suggested-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
2020-06-07rockchip: puma: reorganize devicetrees to actually work and match upstreamHeiko Stuebner
So far the puma dts files only just included the main puma dtsi without handling the actual baseboard and rk3399-puma.dtsi was very much detached from the variant in the mainline Linux kernel. Recent changes resulted in a strange situation with nonworking puma boards. Commit ab800e5a6f28 ("arm: dts: rockchip: puma: move U-Boot specific bits to u-boot.dtsi") moved the sdram include from rk3399-puma-ddrX.dts to new files rk3399-puma-ddrx-u-boot.dtsi which were never included anywhere though. Commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux") replaced the rk3399-puma.dtsi nearly completely, but in the kernel it definitly depends on a baseboard dts to actually enable peripherals like sd-slot, uarts, etc. So to untagle this and bring the whole thing more in line with mainline Linux, bring the rk3399-puma-haikou.dts over as well, drop the separate DDR-option devicetrees and instead replace them with a puma Kconfig option to select and include the needed DDR variant. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>