Remove <common.h> from all mach-rockchip and include/asm/arch-rockchip
files and when needed add missing include files directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
When Rockchip TPL blob is used, the memory areas that can be used for
DRAM is gotten from ATAGS passed through the DRAM at a specific address.
The DDR_MEM tag contains at most 10 areas, so we should default to 10 if
Rockchip TPL blob is used. Note that it is technically possible we need
more if one of those 10 areas overlaps with reserved memory area,
forcing us to split it in two. But a default doesn't need to handle all
cases, only most.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Allow RK3568 and RK3588 based boards to get the RAM bank configuration
from the ROCKCHIP_TPL stage instead of the current logic. This fixes
both an issue where 256MB of RAM is blocked for devices with >= 4GB
of RAM and where memory holes need to be defined for devices with
more than 16GB of RAM. In the event that neither SoC is used or the
ROCKCHIP_TPL stage is not used, fall back to existing logic.
The logic handles creating memory holes from reserved memory areas
defined in mem_map data struct in SoC C files, but only if the DRAM area
overlaps with one reserved memory area.
Since mem_map data struct is used, it should be rather straightforward
to add support for other SoCs if needed.
The logic is taken from Rockchip's U-Boot tag linux-5.10-gen-rkr4.1
(e08e32143dd).
Note that Rockchip's U-Boot/TF-A/OP-TEE modify the ATAGS at runtime as
well, but the DDR_MEM tag seems to be pretty much stable (though BL31
seems to be reserving only 1MB for itself at the moment).
u32 for ATAGS is used because it simplifies the pointer arithmetic and
it's expected that ATAGS are always below the 4GB limit allowed by u32.
Co-developed-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Port the RK3328 part of the Rockchip IO-domain driver from linux.
This differs from linux version in that pmu io iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supply that have been configured.
Enable by default on all RK3328 boards, skip rk3328-evb because this
target is typically also used on miscellaneous boards and boxes not
fully supported by U-Boot.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3328 SoC support ARMv8 Cryptography Extensions and use of the
ARMv8 crypto extensions help speed up FIT checksum validation in SPL.
Imply ARMV8_SET_SMPEN and ARMV8_CRYPTO to take advantage of the crypto
extensions for SHA256 when validating checksum of FIT images.
Also imply OF_LIVE to help speed up init of U-Boot proper.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sort imply statements under ROCKCHIP_RK3328 alphabetically and remove
ENABLE_ARM_SOC_BOOT0_HOOK, DEBUG_UART_BOARD_INIT and SYS_NS16550, they
are already implyed or selected by ARCH_ROCKCHIP.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Display TPL init information message only when TPL_BANNER_PRINT
configuration entry is set. This allows to disable information
message in case logs on UART are unwanted.
Update parent ifdef condition to check also CONFIG_TPL_SERIAL
to match logic of the non-PX30 TPL implementation.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Imply BOOTSTD_FULL for all RK356x boards to more closely follow RK3588.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Imply support for GbE PHY status parsing and configuration when support
for onboard ethernet is enabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK35xx SoCs contain a crypto engine block that can generate random
numbers.
Enable rng node in soc u-boot.dtsi and enable Kconfig options to take
advantage of the random generator.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sort imply statements under ROCKCHIP_RK3568 and ROCKCHIP_RK3588
alphabetically.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Move cru_rk3308.h and grf_rk3308.h to arch-rockchip to match path used
for all other Rockchip SoCs.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
When RK3308 boards run SPL from eMMC and fail to load FIT from eMMC due
to it being missing or checksum validation fails there can be a fallback
to read FIT from SD-card. However, without proper pinctrl configuration
reading FIT from SD-card may fail:
U-Boot SPL 2024.04-rc4 (Mar 16 2024 - 12:36:12 +0000)
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
Card did not respond to voltage select! : -110
mmc_init: -95, time 12
spl: mmc init failed with error: -95
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices (err=-6)
### ERROR ### Please RESET the board ###
Fix this by tagging related emmc and sdmmc pinctrl nodes with bootph
props. Also sort and move common nodes shared by all boards to the SoC
u-boot.dtsi.
Imply SPL_PINCTRL and SPL_DM_SEQ_ALIAS to apply correct pinconf before
trying to load FIT from a device.
Move u-boot,spl-boot-order to soc u-boot.dtsi and define both sdmmc and
emmc nodes as fallback.
Also fix boot from eMMC (SD NAND) on ROCK Pi S by using correct pinctrl.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3308 SoC contain a crypto engine block that can generate random
numbers.
Add rng node to soc u-boot.dtsi and enable Kconfig options to take
advantage of the random generator.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Like other Rockchip SoCs the RK3308 has cpu id programmed into OTP
memory. The rockchip_otp driver already support the RK3308 variant.
However, the device tree is missing a node to enable use of OTP.
Add the missing otp node to soc u-boot.dtsi, enable the rockchip_otp
driver and enable use of misc_init_r() to set ethaddr based on cpu id.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3308 SoC support ARMv8 Cryptography Extensions and use of the
ARMv8 crypto extensions help speed up FIT checksum validation in SPL.
Imply ARMV8_SET_SMPEN and ARMV8_CRYPTO to take advantage of the crypto
extensions for SHA256 when validating checksum of FIT images.
Imply SPL_FIT_SIGNATURE and LEGACY_IMAGE_FORMAT to enable FIT checksum
validation on all RK3308 boards.
Also disable CONFIG_SPL_RAW_IMAGE_SUPPORT in board defconfigs to ensure
SPL does not try to jump to code that failed checksum validation.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sort imply statements under ROCKCHIP_RK3308 alphabetically and remove
the config SPL_SERIAL statement from soc Kconfig file, it is already
implyed in arch Kconfig.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
When debugging the SPL boot order, the node ID of a device which hasn't
been found is printed but it can be quite hard to relate that to the
specific devicetree node. To aid debugging, print the node path instead of
the cryptic node ID.
Original debug message:
board_boot_order: could not map node @73c to a boot-device
With this patch applied this becomes e.g:
board_boot_order: could not map node /spi@ff1d0000/flash@0 to a boot-device
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Fix a simple spelling mistake in a comment.
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Add missing boot source id <-> device tree node path mapping for SPI NOR
flash on PX30, RK3288, RK3308, RK3368 and RV1126.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Rockchip BROM writes a boot source id at CFG_IRAM_BASE + 0x10, this id
indicates from what storage media TPL/SPL was loaded from.
SPL uses this id to determine what device "same-as-spl" represent when
determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.
However, SPL typically load a small part of TF-A into SRAM and on RK3399
this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.
For affected devices the u-boot,spl-boot-device would not be set when
booting from SPI flash and the flash@0 node was not explicitly listed
in the u-boot,spl-boot-order prop.
Here boot source id is 3 before FIT images is loaded, and 0 after:
U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +0000)
board_spl_was_booted_from: brom_bootdevice_id 3 maps to '/spi@ff1d0000/flash@0'
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
spl_decode_boot_device: could not find udevice for /mmc@fe330000
spl_decode_boot_device: could not find udevice for /mmc@fe320000
spl_perform_fixups: could not map boot_device to ofpath: -19
Use a static brom_bootsource_id_cache to save the boot source id after
an initial read from SRAM to fix this, this allow spl_perform_fixups()
to resolve correct boot source path for "same-as-spl" after SPL have
loaded TF-A related FIT images into memory.
With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1ee6710
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/spi@ff1d0000/flash@0";
stdout-path = "serial2:1500000n8";
u-boot,spl-boot-order = "same-as-spl", "/mmc@fe330000", "/mmc@fe320000";
};
Fixes: d57e16c7e712 ("rockchip: find U-boot proper boot device by inverting the logic that sets it")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Michal Simek <michal.simek@amd.com> says:
I looked as cleaning up some dependencies and I found that qconfig is
reporting some issues. This series is fixing some of them. But there are
still some other pending. That's why please go and fix them if they are
related to your board.
UTF-8: I am using uni2ascii -B < file to do conversion. When you run it in
a loop you will find some other issue with copyright chars or some issues
in files taken from the Linux kernel like DTs. They should be likely fixed
in the kernel first.
Based on discussion I am ignoring names too.
Some of Kconfigs are using utf-8 encoding because of used chars. Convert
all of them to ascii enconging. Based on discussion ASCII should be used in
general with the exception of names.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
All errors are generated by ./tools/qconfig.py -b -j8 -i whatever.
Error look like this:
drivers/crypto/Kconfig:9: warning: style: quotes recommended around
'drivers/crypto/nuvoton/Kconfig' in 'source drivers/crypto/nuvoton/Kconfig'
Signed-off-by: Michal Simek <michal.simek@amd.com>
image_copy_start/end are defined as c variables in order to force the compiler
emit relative references. However, defining those within a section definition
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 within
a section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated")
and
commit f84a7b8f54db ("ARM: Fix __bss_start and __bss_end in linker scripts")
were moving the bss_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so [0].
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable type with
the value being a fixed offset from the base of a section [1].
So let's start cleaning this up starting with the bss_start and bss_end
variables. Convert them into symbols within the .bss section definition.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
[1] https://sourceware.org/binutils/docs/ld/Expression-Section.html
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # Qualcomm sdm845
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
ADC support is implied by the Rockchip arch Kconfig but that means it
should be possible to disable ADC support and still be able to build.
However the weak implementation of rockchip_dnl_key_pressed() currently
blindly use functions from the ADC subsystem which do not exist when ADC
is not enabled, failing the build.
Therefore, let's encapsulate this logic with a check on the ADC symbol
being selected.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Currently, if the environment is stored on an MMC device, the device
number is hardcoded by CONFIG_SYS_MMC_ENV_DEV. This is problematic
because many boards can choose between booting from an SD card or a
removable eMMC. For example, the Rock64 defconfig sets
CONFIG_SYS_MMC_ENV_DEV=1, which corresponds to the SD card. If an eMMC
is used as the boot device and no SD card is installed, it is impossible
to save the environment.
To avoid this problem, we can choose the environment MMC device based on
the boot device. The theobroma-systems boards already contain code to do
this, so this commit simply moves it to the common Rockchip board file,
with some refactoring. I also removed another implementation of
mmc_get_env_dev() from tinker_rk3288 that performed MMC boot device
detection by reading a bootrom register.
This has been tested on a Rock64v2.
Signed-off-by: Ben Wolsieffer <benwolsieffer@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Move the call to gpt_capsule_update_setup() from the weak function
rk_board_late_init() into the main board_late_init() function.
Also change to use IS_ENABLED() instead for defined().
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Move ROCK Pi 4 specific board code from the shared evb_rk3399 target
into its own board target and update related defconfigs to use the new
TARGET_ROCKPI4_RK3399 option.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Change to use the common Product ID 0x0010 when the ums command is used.
This matches downstream vendor U-Boot and is a Product ID that tools
such as rkdeveloptool and RKDevTool will identify as MSC mode.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The board_usb_init() and board_usb_cleanup() functions is always
included when USB_GADGET and USB_GADGET_DWC2_OTG is enabled.
Prepare for a change to use DM_USB_GADGET with DWC2_OTG by adding an
extra ifdef condition. The extra separate ifdef for USB_GADGET prepare
for next patch that adds a g_dnl_bind_fixup() function.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Currently the following memory layout is typically used on RK3588:
[ 0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[ -X, 4M) - SPL pre-reloc stack (SPL_STACK)
[ 3.5M, 4M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ -X, 6M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 5M, 6M) - reloc malloc heap (SPL_STACK_R_MALLOC_SIMPLE_LEN)
[ 10M, +X) - U-Boot proper binary (TEXT_BASE)
[ -X, 12M) - U-Boot proper pre-reloc stack (CUSTOM_SYS_INIT_SP_ADDR)
[11.5M, 12M) - pre-reloc malloc heap (SYS_MALLOC_F_LEN)
[ 64M, +16K) - SPL bss (SPL_BSS_START_ADDR, SPL_BSS_MAX_SIZE)
SPL can safely load U-Boot proper + FDT to [10M, 11.5M) with this layout.
However, on ROCK 5A the SPL stacks is overlapping:
[ -X, 16M) - SPL pre-reloc stack (SPL_STACK)
[15.5M, 16M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ -X, 16M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 15M, 16M) - reloc malloc heap (SPL_STACK_R_MALLOC_SIMPLE_LEN)
Because bind and probe udevice instanses is allocated on the pre-reloc
malloc heap, there is going to be an overlap when reloc malloc heap
reaches close to 512 KiB of usage.
Migrate to use common bss, stack and malloc heap size and addresses to
mitigate these limitations and allow for a larger U-Boot proper size.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(Update for new boards defconfig)
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
With the stack and text base used by U-Boot SPL and proper on RK3399
there is a high likelihood of overlapping when U-Boot proper + FDT nears
or exceeded 1 MiB in size.
Currently the following memory layout is typically used on RK3399:
[ 0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[ 2M, +X) - U-Boot proper binary (TEXT_BASE)
[ -X, 3M) - U-Boot proper pre-reloc stack (CUSTOM_SYS_INIT_SP_ADDR)
[ -16K, 3M) - pre-reloc malloc heap (SYS_MALLOC_F_LEN)
[ -X, 4M) - SPL pre-reloc stack (SPL_STACK)
[ -16K, 4M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ 4M, +8K) - SPL bss (SPL_BSS_START_ADDR, SPL_BSS_MAX_SIZE)
[ -X, 64M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 63M, 64M) - reloc malloc heap (SPL_STACK_R_MALLOC_SIMPLE_LEN)
SPL can safely load U-Boot proper + FDT to [2M, 4M-16K) with this layout.
However, the stack at [-X, 3M) used during U-Boot proper pre-reloc is
restricting the safe size of U-Boot proper + FDT to be less than 1 MiB.
Migrate to use common bss, stack and malloc heap size and addresses to
fix this restriction and allow for a larger U-Boot proper image size.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
With the stack and text base used by U-Boot SPL and proper on RK3328
there is a high likelihood of overlapping when U-Boot proper + FDT nears
or exceeded 1 MiB in size.
Currently the following memory layout is typically used on RK3328:
[ 0, 256K) - SPL binary
[ 256K, 2M) - TF-A / reserved
[ 2M, +X) - U-Boot proper binary (TEXT_BASE)
[ -X, 3M) - U-Boot proper pre-reloc stack (CUSTOM_SYS_INIT_SP_ADDR)
[ -8K, 3M) - pre-reloc malloc heap (SYS_MALLOC_F_LEN)
[ -X, 4M) - SPL pre-reloc stack (SPL_STACK)
[ -8K, 4M) - pre-reloc malloc heap (SPL_SYS_MALLOC_F_LEN)
[ -X, 6M) - SPL reloc stack (SPL_STACK_R_ADDR)
[ 5M, 6M) - reloc malloc heap (SPL_STACK_R_MALLOC_SIMPLE_LEN)
[ 32M, +8K) - SPL bss (SPL_BSS_START_ADDR, SPL_BSS_MAX_SIZE)
SPL can safely load U-Boot proper + FDT to [2M, 4M-8K) with this layout.
However, the stack at [-X, 3M) used during U-Boot proper pre-reloc is
restricting the safe size of U-Boot proper + FDT to be less than 1 MiB.
Migrate to use common bss, stack and malloc heap size and addresses to
fix this restriction and allow for a larger U-Boot proper image size.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
On Rockchip the typical aarch64 boot steps are as follows:
- BROM load TPL to SRAM
- TPL init full DRAM
- use stack in SRAM at TPL_STACK addr
- use malloc heap on stack, size is TPL_SYS_MALLOC_F_LEN
- TPL jump back to BROM
- BROM load SPL to beginning of DRAM
- SPL init storage devices
- use bss in DRAM at SPL_BSS_START_ADDR, size is SPL_BSS_MAX_SIZE
- use stack in DRAM at SPL_STACK addr (or CUSTOM_SYS_INIT_SP_ADDR)
- use malloc heap on stack, size is SPL_SYS_MALLOC_F_LEN
- SPL load FIT images from storage to DRAM
- use stack in DRAM at SPL_STACK_R_ADDR
- use new malloc heap on stack, size is SPL_STACK_R_MALLOC_SIMPLE_LEN
- SPL jump to TF-A at 0x40000
- (optional) TF-A load OPTEE
- TF-A jump to U-Boot proper at TEXT_BASE
- U-Boot proper init pre-reloc devices
- use stack in DRAM at CUSTOM_SYS_INIT_SP_ADDR
- use malloc heap on stack, size is SYS_MALLOC_F_LEN
- U-Boot proper relocate to end of usable DRAM
- U-Boot proper init devices and complete boot
SPL have access to full DRAM, however, current configuration for text
base, stack addr and malloc heap size used at the different boot steps
are at risk of overlapping, e.g. when U-Boot proper + FDT grows close
to 1 MiB on RK3328/RK3399 or when pre-reloc and reloc stack and malloc
heap overlap on ROCK 5A.
Fix this by defining safe defaults for bss, stack and malloc size and
addresses. A range at around [60 MiB, 64 MiB) was chosen to be used for
bss and stack until U-Boot proper have been relocated to end of usable
DRAM. The range was primarily chosen to be able to accommodate SoCs with
a small amount of embedded DRAM, e.g. RK3308G has 64 MiB DRAM.
Overiew of the new common memory layout:
[ 0, 2M) - SPL / TF-A / reserved
[ 2M, +X) - U-Boot proper pre-reloc
[ -X, 64M) - bss, stack and malloc heap
During SPL pre-reloc phase:
[ 0, 256K) - SPL binary is loaded by BROM to beginning of DRAM
[ -X, 63M) - SPL pre-reloc stack
[ -32K, 63M) - SPL pre-reloc malloc heap
[63.5M, +32K) - SPL bss
After SPL reloc phase:
[ 0, 256K) - SPL binary
[ 256K, +X) - TF-A image is loaded by SPL
[ 2M, +X) - U-Boot proper + FDT image is loaded by SPL
[ -X, 62M) - SPL reloc stack
[ 60M, 62M) - SPL reloc malloc heap
[ -32K, 63M) - SPL init malloc heap, memory allocated during SPL
pre-reloc phase is still in use at reloc phase
[63.5M, +32K) - SPL bss
During U-Boot proper pre-reloc phase:
[ 0, 2M) - TF-A / reserved
[ 2M, +X) - U-Boot proper + FDT
[ -X, 63M) - U-Boot proper pre-reloc stack (shared addr with SPL)
[ -64K, 63M) - U-Boot proper pre-reloc malloc heap
After U-Boot proper has relocated to top of memory we should be able to
use 2M+ for loading kernel, initrd, scripts etc.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
TB-RK3588X board is a Rockchip Toybrick RK3588 based development board.
Specification:
Rockchip Rk3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB Memory LPDDR4x
Mali G610MC4 GPU
2× MIPI-CSI0 Connector
1x 2Lanes PCIe3.0 Connector
1x SATA3.0 Connector
32GB eMMC Module
2x USB 2.0, 2x USB 3.0
1x HDMI Output, 1x HDMI Input
2x Ethernet Port
Functions work normally:
[1] USB2.0 Host
[2] Ethernet0 with PHY RTL8211F
More information can be obtained from the following websites:
[1] https://t.rock-chips.com/en/wiki/EN/tb-rk3588x_en/index.html
[2] http://t.rock-chips.com/
Kernel commits:
8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for TB-RK3588X board")
7140387ff49d ("dt-bindings: arm: rockchip: Add Toybrick TB-RK3588X")
Reviewed-by: Weizhao Ouyang <weizhao.ouyang@arm.com>
Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
FIT checksum validation is very slow in SPL due to D-cache not being
enabled.
Enable caches in SPL on ARM64 SoCs to speed up FIT checksum validation,
from seconds to milliseconds.
This change enables caches in SPL on all Rockchip ARM64 boards, the
Kconfig options SPL_SYS_ICACHE_OFF and SPL_SYS_DCACHE_OFF can be used to
disable caches for a specific board or SoC if needed.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The rockchip-efuse driver supports the efuse found on RK3399. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.
Enable the driver and reading cpuid by default for RK3399.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
The rockchip-efuse driver supports the efuse found on RK3328. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.
Enable the driver and reading cpuid by default for RK3328.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Similar to RK35xx the BootRom in RK3328 can read all data and look for
idbloader at 0x8000, same as it does for SD and eMMC.
Use the rksd format and modify the mkimage offset to generate a bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This reverts commit 3523c07867b403d5b3b68812aebac8a5afa5be4c.
Booting from SPI was already allowed before this commit was first
introduced. A few lines further down the exact same code already existed
and still does.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The different macros use writel which is defined in asm/io.h, so let's
include the header so users of hardware.h do not need to include
asm/io.h as well.
While at it, remove asm/io.h includes wherever
asm/arch-rockchip/hardware.h is included already.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
hardware.h is only defining macros which are "wrappers" around writel().
writel() is however not available in hardware.h, <asm/io.h> needs to be
included. This means in order to use the wrappers in hardware.h, one
also needs to include the <asm/io.h> header.
However, this cannot be done currently because hardware.h is included in
include/configs files, which are implicitly included by every code file
by default, which makes the compilation of arch/arm/cpu/armv8/u-boot.lds
fail because ALIGN (the ARM assembly directive) got redefined by some
of the include files coming from <asm.io.h>.
Because nothing in the include/configs file actually use hardware.h,
let's remove the inclusion of hardware.h from the include/configs files
and explicitly add it wherever it is required.
This prepares for the next commit where <asm/io.h> will be included in
hardware.h.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
It's one thing to have the register mapped via a well-defined struct but
it's another to be able to make use of it. For that to happen, one needs
to cast the physical address memory of the beginning of the register
address space with the struct. Since this cannot change, let's hardcode
it in the include files so that users do not need to duplicate this line
of code in their own implementation.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.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.
This is the case for RK3588 Jaguar for example which has an SD card
connector without an SD card card detect signal and has SDMMC_DET
connected to ground.
Because enabling JTAG at runtime could be a security issue and also to
make sure that we have a consistent behavior on all boards by default,
let's disable this force_jtag feature.
However, let's make it easy to reenable it for debugging purposes by
hiding it behind a Kconfig symbol.
Note that soc_con[0] is reserved. But considering that it's way more
user-friendly to access soc_con1 from the TRM with soc_con[1] than
soc_con[0], and that soc_con0 would actually be located at 4 bytes
before soc_con1, let's just make soc_con0 part of the soc_con array.
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>
