[U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products.
The device is partitioned into three functional domains, each containing specific processing cores and peripherals: Some highlights in each domain are: - MAIN Domain: -------------- * Quad ARMv8 A53 cores split over two clusters * GICv3 compliant GIC500 * Configurable L3 Cache and IO-coherent architecture * DDR Subsystem (DDRSS) with Error Correcting Code (ECC) * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL * eQEP/eCAP, eHRPWM. * Multimedia capability with CAL, DSS7-UL, SGX544, McASP * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, GPIO
- MCU Domain: ------------- * Dual lock-step capable R5F uC for safety-critical applications * Flash subsystem with OSPI and Hyperbus interfaces * High data throughput capable distributed DMA architecture under MCU NAVSS * Dual ADCSS, Dual CAN-FD.
- WKUP Domain: -------------- * Centralized System Controller for Security, Power, and Resource management.
For further deails see AM65x Technical Reference Manual (SPRUID7, April 2018): http://www.ti.com/lit/pdf/spruid7
This is a complex SoC and the support to add this SoC is very huge. So I tried to split into 3 separate series: [1/3] Adding base SoC support [2/3] Base drivers that allow minimal boot. [3/3] EVM support with dts and defconfig changes.
This series adds base SoC support. The rest of the two series will be a follow up of this series.
On AM65x family devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, keeping safety in picture and to have faster boot time, the software boot architecture is designed as: https://pastebin.ubuntu.com/p/NxSvDbMtSk/ Any feedback is highly appreciated.
Andreas Dannenberg (1): arm: K3: am654: Unlock control module registers during init
Lokesh Vutla (7): arm: K3: Add initial support for TI's K3 generation of SoCs arm: K3: Add support for AM654 SoC definition arm: K3: Update _start instruction arm: K3: am654: Add support for boot device detection armv8: K3: am654: Add custom MMU support armv8: K3: am654: Introduce FIT generator script armv8: K3: am654: Add support for generating build targets
Kconfig | 2 +- MAINTAINERS | 1 + arch/arm/Kconfig | 8 ++ arch/arm/Makefile | 1 + arch/arm/include/asm/spl.h | 2 +- arch/arm/lib/vectors.S | 8 ++ arch/arm/mach-k3/Kconfig | 50 ++++++++ arch/arm/mach-k3/Makefile | 7 ++ arch/arm/mach-k3/am6_init.c | 123 +++++++++++++++++++ arch/arm/mach-k3/arm64-mmu.c | 45 +++++++ arch/arm/mach-k3/config.mk | 21 ++++ arch/arm/mach-k3/include/mach/am6_hardware.h | 44 +++++++ arch/arm/mach-k3/include/mach/am6_spl.h | 36 ++++++ arch/arm/mach-k3/include/mach/clock.h | 16 +++ arch/arm/mach-k3/include/mach/hardware.h | 12 ++ arch/arm/mach-k3/include/mach/spl.h | 12 ++ common/spl/Kconfig | 2 +- drivers/serial/ns16550.c | 5 +- scripts/Makefile.spl | 9 ++ tools/k3/k3_fit_atf.sh | 98 +++++++++++++++ 20 files changed, 497 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-k3/Kconfig create mode 100644 arch/arm/mach-k3/Makefile create mode 100644 arch/arm/mach-k3/am6_init.c create mode 100644 arch/arm/mach-k3/arm64-mmu.c create mode 100644 arch/arm/mach-k3/config.mk create mode 100644 arch/arm/mach-k3/include/mach/am6_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/am6_spl.h create mode 100644 arch/arm/mach-k3/include/mach/clock.h create mode 100644 arch/arm/mach-k3/include/mach/hardware.h create mode 100644 arch/arm/mach-k3/include/mach/spl.h create mode 100755 tools/k3/k3_fit_atf.sh
Add support for Texas Instruments' K3 Generation Processor families.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- Kconfig | 2 +- MAINTAINERS | 1 + arch/arm/Kconfig | 8 ++++++++ arch/arm/Makefile | 1 + arch/arm/mach-k3/Kconfig | 12 ++++++++++++ common/spl/Kconfig | 2 +- drivers/serial/ns16550.c | 5 +++-- 7 files changed, 27 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-k3/Kconfig
diff --git a/Kconfig b/Kconfig index db0f545e45..04ffc26753 100644 --- a/Kconfig +++ b/Kconfig @@ -447,7 +447,7 @@ config SYS_EXTRA_OPTIONS config SYS_TEXT_BASE depends on !NIOS2 && !XTENSA depends on !EFI_APP - default 0x80800000 if ARCH_OMAP2PLUS + default 0x80800000 if ARCH_OMAP2PLUS || ARCH_K3 default 0x4a000000 if ARCH_SUNXI && !MACH_SUN9I && !MACH_SUN8I_V3S default 0x2a000000 if ARCH_SUNXI && MACH_SUN9I default 0x42e00000 if ARCH_SUNXI && MACH_SUN8I_V3S diff --git a/MAINTAINERS b/MAINTAINERS index 8f237128b2..1971197ec0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -272,6 +272,7 @@ M: Tom Rini trini@konsulko.com S: Maintained T: git git://git.denx.de/u-boot-ti.git F: arch/arm/mach-davinci/ +F: arch/arm/mach-k3/ F: arch/arm/mach-keystone/ F: arch/arm/include/asm/arch-omap*/ F: arch/arm/include/asm/ti-common/ diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 63ec02403a..deed8103de 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -646,6 +646,12 @@ config ARCH_KEYSTONE imply CMD_SAVES imply FIT
+config ARCH_K3 + bool "Texas Instruments' K3 Architecture" + select SPL + select SUPPORT_SPL + select FIT + config ARCH_OMAP2PLUS bool "TI OMAP2+" select CPU_V7A @@ -1377,6 +1383,8 @@ source "arch/arm/mach-highbank/Kconfig"
source "arch/arm/mach-integrator/Kconfig"
+source "arch/arm/mach-k3/Kconfig" + source "arch/arm/mach-keystone/Kconfig"
source "arch/arm/mach-kirkwood/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index cac58bdc4d..cbcb357f3d 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -58,6 +58,7 @@ machine-$(CONFIG_ARCH_BCMSTB) += bcmstb machine-$(CONFIG_ARCH_DAVINCI) += davinci machine-$(CONFIG_ARCH_EXYNOS) += exynos machine-$(CONFIG_ARCH_HIGHBANK) += highbank +machine-$(CONFIG_ARCH_K3) += k3 machine-$(CONFIG_ARCH_KEYSTONE) += keystone # TODO: rename CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD machine-$(CONFIG_KIRKWOOD) += kirkwood diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig new file mode 100644 index 0000000000..552b84923e --- /dev/null +++ b/arch/arm/mach-k3/Kconfig @@ -0,0 +1,12 @@ +if ARCH_K3 + +choice + prompt "Texas Instruments' K3 based SoC select" + optional + +endchoice + +config SYS_SOC + default "k3" + +endif diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 0ad1e049a9..11c2c0133f 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -171,7 +171,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR default 0x140 if ARCH_MVEBU default 0x200 if ARCH_SOCFPGA || ARCH_AT91 default 0x300 if ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || OMAP44XX || \ - OMAP54XX || AM33XX || AM43XX + OMAP54XX || AM33XX || AM43XX || ARCH_K3 default 0x4000 if ARCH_ROCKCHIP help Address on the MMC to load U-Boot from, when the MMC is being used diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/ #endif
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), &com_port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \ + defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, &com_port->mdr1); #endif
On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote:
Add support for Texas Instruments' K3 Generation Processor families.
[snip]
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/ #endif
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), &com_port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, &com_port->mdr1);
#endif
K3 would also be using CONFIG_OMAP_SERIAL once https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in the next release) yes? I think 956252 needs a follow-up that changes the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this part of the series just becomes changing the default y line for OMAP_SERIAL.
On Friday 24 August 2018 07:40 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote:
Add support for Texas Instruments' K3 Generation Processor families.
[snip]
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/ #endif
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), &com_port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, &com_port->mdr1);
#endif
K3 would also be using CONFIG_OMAP_SERIAL once https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in the next release) yes? I think 956252 needs a follow-up that changes the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this
I did not make this change because ns16550 is also used by non-DM platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to OMAP_SERIAL would break non DM platforms. I guess I should still add || OMAP_SERIAL. Ill post a v2 for 956252.
Thanks and regards, Lokesh
On Fri, Aug 24, 2018 at 08:21:19PM +0530, Lokesh Vutla wrote:
On Friday 24 August 2018 07:40 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote:
Add support for Texas Instruments' K3 Generation Processor families.
[snip]
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/ #endif
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), &com_port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, &com_port->mdr1);
#endif
K3 would also be using CONFIG_OMAP_SERIAL once https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in the next release) yes? I think 956252 needs a follow-up that changes the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this
I did not make this change because ns16550 is also used by non-DM platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to OMAP_SERIAL would break non DM platforms. I guess I should still add || OMAP_SERIAL. Ill post a v2 for 956252.
What are the non-DM serial users at this point?
On Friday 24 August 2018 08:25 PM, Tom Rini wrote:
On Fri, Aug 24, 2018 at 08:21:19PM +0530, Lokesh Vutla wrote:
On Friday 24 August 2018 07:40 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote:
Add support for Texas Instruments' K3 Generation Processor families.
[snip]
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/ #endif
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), &com_port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, &com_port->mdr1);
#endif
K3 would also be using CONFIG_OMAP_SERIAL once https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in the next release) yes? I think 956252 needs a follow-up that changes the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this
I did not make this change because ns16550 is also used by non-DM platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to OMAP_SERIAL would break non DM platforms. I guess I should still add || OMAP_SERIAL. Ill post a v2 for 956252.
What are the non-DM serial users at this point?
omap4-evm and omap5-uevm are two TI boards which uses non-DM. I am not sure about non-TI boards with omap SoCs.
Thanks and regards, Lokesh
On Fri, Aug 24, 2018 at 08:44:50PM +0530, Lokesh Vutla wrote:
On Friday 24 August 2018 08:25 PM, Tom Rini wrote:
On Fri, Aug 24, 2018 at 08:21:19PM +0530, Lokesh Vutla wrote:
On Friday 24 August 2018 07:40 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:48PM +0530, Lokesh Vutla wrote:
Add support for Texas Instruments' K3 Generation Processor families.
[snip]
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 9c80090aa7..f48d82f051 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) ;
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier); -#if defined(CONFIG_ARCH_OMAP2PLUS) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_ARCH_K3) serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/ #endif
@@ -183,7 +183,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(ns16550_getfcr(com_port), &com_port->fcr); if (baud_divisor != -1) NS16550_setbrg(com_port, baud_divisor); -#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) +#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_ARCH_K3) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, &com_port->mdr1);
#endif
K3 would also be using CONFIG_OMAP_SERIAL once https://patchwork.ozlabs.org/patch/956252/ is applied (which I'll do in the next release) yes? I think 956252 needs a follow-up that changes the above hunks to be testing off CONFIG_OMAP_SERIAL instead so this
I did not make this change because ns16550 is also used by non-DM platforms. Since OMAP_SERIAL is DM specific, converting this #ifdef to OMAP_SERIAL would break non DM platforms. I guess I should still add || OMAP_SERIAL. Ill post a v2 for 956252.
What are the non-DM serial users at this point?
omap4-evm and omap5-uevm are two TI boards which uses non-DM. I am not sure about non-TI boards with omap SoCs.
OK. I guess please just make sure updating omap4/5 are on your TODO list somewhere, thanks!
The AM654 device is designed for industrial automation and PLC controller class platforms among other applications. Introduce base support for AM654 SoC.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- arch/arm/mach-k3/Kconfig | 31 ++++++++++++++++++++++++++ arch/arm/mach-k3/Makefile | 6 +++++ arch/arm/mach-k3/am6_init.c | 32 +++++++++++++++++++++++++++ arch/arm/mach-k3/include/mach/clock.h | 16 ++++++++++++++ 4 files changed, 85 insertions(+) create mode 100644 arch/arm/mach-k3/Makefile create mode 100644 arch/arm/mach-k3/am6_init.c create mode 100644 arch/arm/mach-k3/include/mach/clock.h
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 552b84923e..c532fbd061 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -4,9 +4,40 @@ choice prompt "Texas Instruments' K3 based SoC select" optional
+config SOC_K3_AM6 + bool "TI's K3 based AM6 SoC Family Support" + endchoice
config SYS_SOC default "k3"
+config NON_SECURE_MSRAM_SIZE + hex "Size of the MCU OC-MSRAM" + default 0x80000 + help + Describes the total size of the MCU MSRAM. This doesn't + specify the total size of SPL as ROM can use some part + of this RAM. Once ROM gives control to SPL then this + complete size can be usable. + +config MAX_DOWNLODABLE_IMAGE_SIZE + hex "Maximum size of the image" + default 0x58000 + help + Describes the maximum size of the image that ROM can download + from any boot media. + +config MCU_SCRATCHPAD_BASE + hex "Base address of Scratchpad RAM" + default 0x40280000 if SOC_K3_AM6 + help + Describes the base address of MCU Scratchpad RAM. + +config MCU_SCRATCHPAD_SIZE + hex "Size of Scratchpad RAM" + default 0x200 if SOC_K3_AM6 + help + Describes the size of MCU Scratchpad RAM. + endif diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile new file mode 100644 index 0000000000..356fc27b11 --- /dev/null +++ b/arch/arm/mach-k3/Makefile @@ -0,0 +1,6 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/ +# Lokesh Vutla lokeshvutla@ti.com + +obj-$(CONFIG_SOC_K3_AM6) += am6_init.o diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c new file mode 100644 index 0000000000..7a78e85938 --- /dev/null +++ b/arch/arm/mach-k3/am6_init.c @@ -0,0 +1,32 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * K3: Architecture initialization + * + * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla lokeshvutla@ti.com + */ + +#include <common.h> +#include <spl.h> + +#ifdef CONFIG_SPL_BUILD +void board_init_f(ulong dummy) +{ + /* Init DM early in-order to invoke system controller */ + spl_early_init(); + + /* Prepare console output */ + preloader_console_init(); +} + +u32 spl_boot_device(void) +{ + return BOOT_DEVICE_RAM; +} +#endif + +#ifndef CONFIG_SYSRESET +void reset_cpu(ulong ignored) +{ +} +#endif diff --git a/arch/arm/mach-k3/include/mach/clock.h b/arch/arm/mach-k3/include/mach/clock.h new file mode 100644 index 0000000000..c4dbacb128 --- /dev/null +++ b/arch/arm/mach-k3/include/mach/clock.h @@ -0,0 +1,16 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * K3: Common SoC clock definitions. + * + * (C) Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + */ +#ifndef __ASM_ARCH_CLOCK_H +#define __ASM_ARCH_CLOCK_H + +#include <config.h> + +/* Clock Defines */ +#define V_OSCK 24000000 +#define V_SCLK V_OSCK + +#endif /* __ASM_ARCH_CLOCK_H */
On Tue, Aug 21, 2018 at 08:00:49PM +0530, Lokesh Vutla wrote:
The AM654 device is designed for industrial automation and PLC controller class platforms among other applications. Introduce base support for AM654 SoC.
[snip]
+config NON_SECURE_MSRAM_SIZE
- hex "Size of the MCU OC-MSRAM"
- default 0x80000
- help
Describes the total size of the MCU MSRAM. This doesn'tspecify the total size of SPL as ROM can use some partof this RAM. Once ROM gives control to SPL then thiscomplete size can be usable.+config MAX_DOWNLODABLE_IMAGE_SIZE
- hex "Maximum size of the image"
- default 0x58000
- help
Describes the maximum size of the image that ROM can downloadfrom any boot media.+config MCU_SCRATCHPAD_BASE
- hex "Base address of Scratchpad RAM"
- default 0x40280000 if SOC_K3_AM6
- help
Describes the base address of MCU Scratchpad RAM.+config MCU_SCRATCHPAD_SIZE
- hex "Size of Scratchpad RAM"
- default 0x200 if SOC_K3_AM6
- help
Describes the size of MCU Scratchpad RAM.
These are very generic names. And are these really things that can be configured and changed by the user? MAX_DOWNLODABLE_IMAGE_SIZE is something we usually set in CONFIG_SPL_MAX_SIZE but I imagine the overall architecture means that perhaps that's not the exact variable we're talking about here.
On Friday 24 August 2018 07:41 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:49PM +0530, Lokesh Vutla wrote:
The AM654 device is designed for industrial automation and PLC controller class platforms among other applications. Introduce base support for AM654 SoC.
[snip]
+config NON_SECURE_MSRAM_SIZE
- hex "Size of the MCU OC-MSRAM"
- default 0x80000
- help
Describes the total size of the MCU MSRAM. This doesn'tspecify the total size of SPL as ROM can use some partof this RAM. Once ROM gives control to SPL then thiscomplete size can be usable.+config MAX_DOWNLODABLE_IMAGE_SIZE
- hex "Maximum size of the image"
- default 0x58000
- help
Describes the maximum size of the image that ROM can downloadfrom any boot media.+config MCU_SCRATCHPAD_BASE
- hex "Base address of Scratchpad RAM"
- default 0x40280000 if SOC_K3_AM6
- help
Describes the base address of MCU Scratchpad RAM.+config MCU_SCRATCHPAD_SIZE
- hex "Size of Scratchpad RAM"
- default 0x200 if SOC_K3_AM6
- help
Describes the size of MCU Scratchpad RAM.These are very generic names. And are these really things that can be configured and changed by the user? MAX_DOWNLODABLE_IMAGE_SIZE is
You are right. These are not configurable by user, but changes from SoC to SoC within K3 family. Will fix it in v2 by dropping the prompt string.
Thanks and regards, Lokesh
something we usually set in CONFIG_SPL_MAX_SIZE but I imagine the overall architecture means that perhaps that's not the exact variable we're talking about here.
On Fri, Aug 24, 2018 at 08:28:17PM +0530, Lokesh Vutla wrote:
On Friday 24 August 2018 07:41 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:49PM +0530, Lokesh Vutla wrote:
The AM654 device is designed for industrial automation and PLC controller class platforms among other applications. Introduce base support for AM654 SoC.
[snip]
+config NON_SECURE_MSRAM_SIZE
- hex "Size of the MCU OC-MSRAM"
- default 0x80000
- help
Describes the total size of the MCU MSRAM. This doesn'tspecify the total size of SPL as ROM can use some partof this RAM. Once ROM gives control to SPL then thiscomplete size can be usable.+config MAX_DOWNLODABLE_IMAGE_SIZE
- hex "Maximum size of the image"
- default 0x58000
- help
Describes the maximum size of the image that ROM can downloadfrom any boot media.+config MCU_SCRATCHPAD_BASE
- hex "Base address of Scratchpad RAM"
- default 0x40280000 if SOC_K3_AM6
- help
Describes the base address of MCU Scratchpad RAM.+config MCU_SCRATCHPAD_SIZE
- hex "Size of Scratchpad RAM"
- default 0x200 if SOC_K3_AM6
- help
Describes the size of MCU Scratchpad RAM.These are very generic names. And are these really things that can be configured and changed by the user? MAX_DOWNLODABLE_IMAGE_SIZE is
You are right. These are not configurable by user, but changes from SoC to SoC within K3 family. Will fix it in v2 by dropping the prompt string.
Well, the names are also fairly generic. Why not just #define SYS_K3_xxx ?
On K3 family SoCs, once the ROM loads image on R5, M3 resets R5 and expects to start executing from 0x0. In order to handle this ROM updates the boot vector of R5 such that first 64 bytes of image load address are mapped to 0x0.
In this case, it is SPL's responsibility to jump to the proper image location. So, update the PC with address of reset vector(like how other exception vectors are handled), instead of branching to reset.
Reviewed-by: Tom Rini trini@konsulko.com Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- arch/arm/lib/vectors.S | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index d629cb1dc2..2ca6e2494a 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -19,7 +19,11 @@ * for the non-boot0 case or by a boot0-header. */ .macro ARM_VECTORS +#ifdef CONFIG_ARCH_K3 + ldr pc, _reset +#else b reset +#endif ldr pc, _undefined_instruction ldr pc, _software_interrupt ldr pc, _prefetch_abort @@ -94,6 +98,7 @@ _start: ************************************************************************* */
+ .globl _reset .globl _undefined_instruction .globl _software_interrupt .globl _prefetch_abort @@ -102,6 +107,9 @@ _start: .globl _irq .globl _fiq
+#ifdef CONFIG_ARCH_K3 +_reset: .word reset +#endif _undefined_instruction: .word undefined_instruction _software_interrupt: .word software_interrupt _prefetch_abort: .word prefetch_abort
AM654 allows for booting from primary or backup boot media. Both media can be chosen individually based on switch settings. ROM looks for a valid image in primary boot media, if not found then looks in backup boot media. In order to pass this boot media information to boot loader, ROM stores a value at a particular address. Add support for reading this information and determining the boot media correctly.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com Signed-off-by: Andreas Dannenberg dannenberg@ti.com Signed-off-by: Vignesh R vigneshr@ti.com --- arch/arm/include/asm/spl.h | 2 +- arch/arm/mach-k3/Kconfig | 7 +++ arch/arm/mach-k3/am6_init.c | 54 +++++++++++++++++++- arch/arm/mach-k3/include/mach/am6_hardware.h | 23 +++++++++ arch/arm/mach-k3/include/mach/am6_spl.h | 36 +++++++++++++ arch/arm/mach-k3/include/mach/hardware.h | 12 +++++ arch/arm/mach-k3/include/mach/spl.h | 12 +++++ 7 files changed, 144 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/am6_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/am6_spl.h create mode 100644 arch/arm/mach-k3/include/mach/hardware.h create mode 100644 arch/arm/mach-k3/include/mach/spl.h
diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h index b9e8a4f5d5..e568af2561 100644 --- a/arch/arm/include/asm/spl.h +++ b/arch/arm/include/asm/spl.h @@ -8,7 +8,7 @@
#if defined(CONFIG_ARCH_OMAP2PLUS) \ || defined(CONFIG_EXYNOS4) || defined(CONFIG_EXYNOS5) \ - || defined(CONFIG_EXYNOS4210) + || defined(CONFIG_EXYNOS4210) || defined(CONFIG_ARCH_K3) /* Platform-specific defines */ #include <asm/arch/spl.h>
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index c532fbd061..117e5b4e4a 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -40,4 +40,11 @@ config MCU_SCRATCHPAD_SIZE help Describes the size of MCU Scratchpad RAM.
+config BOOT_PARAM_TABLE_INDEX + hex "Address of Array Index to be used within BOOT_PARAM_TABLE" + default 0x41c7fbfc if SOC_K3_AM6 + help + Address at which ROM stores the value which determines if SPL + is booted up by primary boot media or secondary boot media. + endif diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c index 7a78e85938..8a7cedf66f 100644 --- a/arch/arm/mach-k3/am6_init.c +++ b/arch/arm/mach-k3/am6_init.c @@ -7,11 +7,26 @@ */
#include <common.h> +#include <asm/io.h> #include <spl.h> +#include <asm/arch/hardware.h>
#ifdef CONFIG_SPL_BUILD +static void store_boot_index_from_rom(void) +{ + u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL; + + *boot_index = *(u32 *)(CONFIG_BOOT_PARAM_TABLE_INDEX); +} + void board_init_f(ulong dummy) { + /* + * Cannot delay this further as there is a chance that + * BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section. + */ + store_boot_index_from_rom(); + /* Init DM early in-order to invoke system controller */ spl_early_init();
@@ -19,10 +34,47 @@ void board_init_f(ulong dummy) preloader_console_init(); }
-u32 spl_boot_device(void) +static u32 __get_backup_bootmedia(u32 devstat) { + u32 bkup_boot = (devstat & CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >> + CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT; + + switch (bkup_boot) { +#define __BKUP_BOOT_DEVICE(n) \ + case BACKUP_BOOT_DEVICE_##n: \ + return BOOT_DEVICE_##n; + __BKUP_BOOT_DEVICE(USB); + __BKUP_BOOT_DEVICE(UART); + __BKUP_BOOT_DEVICE(ETHERNET); + __BKUP_BOOT_DEVICE(MMC2); + __BKUP_BOOT_DEVICE(SPI); + __BKUP_BOOT_DEVICE(HYPERFLASH); + __BKUP_BOOT_DEVICE(I2C); + }; + return BOOT_DEVICE_RAM; } + +static u32 __get_primary_bootmedia(u32 devstat) +{ + u32 bootmode = devstat & CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK; + + if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI) + bootmode = BOOT_DEVICE_SPI; + + return bootmode; +} + +u32 spl_boot_device(void) +{ + u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT); + u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL); + + if (bootindex == K3_PRIMARY_BOOTMODE) + return __get_primary_bootmedia(devstat); + else + return __get_backup_bootmedia(devstat); +} #endif
#ifndef CONFIG_SYSRESET diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h new file mode 100644 index 0000000000..b56aa60ec7 --- /dev/null +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h @@ -0,0 +1,23 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * K3: AM6 SoC definitions, structures etc. + * + * (C) Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + */ +#ifndef __ASM_ARCH_AM6_HARDWARE_H +#define __ASM_ARCH_AM6_HARDWARE_H + +#include <config.h> + +#define CTRL_MMR0_BASE 0x00100000 +#define CTRLMMR_MAIN_DEVSTAT (CTRL_MMR0_BASE + 0x30) + +#define CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK GENMASK(3, 0) +#define CTRLMMR_MAIN_DEVSTAT_BOOTMODE_SHIFT 0 +#define CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK GENMASK(6, 4) +#define CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT 4 + +/* MCU SCRATCHPAD usage */ +#define K3_BOOT_PARAM_TABLE_INDEX_VAL CONFIG_MCU_SCRATCHPAD_BASE + +#endif /* __ASM_ARCH_AM6_HARDWARE_H */ diff --git a/arch/arm/mach-k3/include/mach/am6_spl.h b/arch/arm/mach-k3/include/mach/am6_spl.h new file mode 100644 index 0000000000..7dd63247dc --- /dev/null +++ b/arch/arm/mach-k3/include/mach/am6_spl.h @@ -0,0 +1,36 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla lokeshvutla@ti.com + */ +#ifndef _ASM_ARCH_AM6_SPL_H_ +#define _ASM_ARCH_AM6_SPL_H_ + +#define BOOT_DEVICE_RAM 0x00 +#define BOOT_DEVICE_OSPI 0x01 +#define BOOT_DEVICE_QSPI 0x02 +#define BOOT_DEVICE_HYPERFLASH 0x03 +#define BOOT_DEVICE_SPI 0x04 +#define BOOT_DEVICE_I2C 0x05 +#define BOOT_DEVICE_MMC2 0x06 +#define BOOT_DEVICE_ETHERNET 0x07 +#define BOOT_DEVICE_USB 0x08 +#define BOOT_DEVICE_PCIE 0x09 +#define BOOT_DEVICE_UART 0x0a +#define BOOT_DEVICE_NAND 0x0c +#define BOOT_DEVICE_MMC1 0x0d +#define BOOT_DEVICE_MMC2_2 0x0e + +#define BACKUP_BOOT_DEVICE_RAM 0x0 +#define BACKUP_BOOT_DEVICE_USB 0x1 +#define BACKUP_BOOT_DEVICE_UART 0x2 +#define BACKUP_BOOT_DEVICE_ETHERNET 0x3 +#define BACKUP_BOOT_DEVICE_MMC2 0x4 +#define BACKUP_BOOT_DEVICE_SPI 0x5 +#define BACKUP_BOOT_DEVICE_HYPERFLASH 0x6 +#define BACKUP_BOOT_DEVICE_I2C 0x7 + +#define K3_PRIMARY_BOOTMODE 0x0 +#define K3_BACKUP_BOOTMODE 0x1 + +#endif diff --git a/arch/arm/mach-k3/include/mach/hardware.h b/arch/arm/mach-k3/include/mach/hardware.h new file mode 100644 index 0000000000..c6b8dae2bd --- /dev/null +++ b/arch/arm/mach-k3/include/mach/hardware.h @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla lokeshvutla@ti.com + */ +#ifndef _ASM_ARCH_HARDWARE_H_ +#define _ASM_ARCH_HARDWARE_H_ + +#ifdef CONFIG_SOC_K3_AM6 +#include "am6_hardware.h" +#endif +#endif /* _ASM_ARCH_HARDWARE_H_ */ diff --git a/arch/arm/mach-k3/include/mach/spl.h b/arch/arm/mach-k3/include/mach/spl.h new file mode 100644 index 0000000000..e72e006cbc --- /dev/null +++ b/arch/arm/mach-k3/include/mach/spl.h @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla lokeshvutla@ti.com + */ +#ifndef _ASM_ARCH_SPL_H_ +#define _ASM_ARCH_SPL_H_ + +#ifdef CONFIG_SOC_K3_AM6 +#include "am6_spl.h" +#endif +#endif /* _ASM_ARCH_SPL_H_ */
On Tue, Aug 21, 2018 at 08:00:51PM +0530, Lokesh Vutla wrote:
AM654 allows for booting from primary or backup boot media. Both media can be chosen individually based on switch settings. ROM looks for a valid image in primary boot media, if not found then looks in backup boot media. In order to pass this boot media information to boot loader, ROM stores a value at a particular address. Add support for reading this information and determining the boot media correctly.
[snip]
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index c532fbd061..117e5b4e4a 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -40,4 +40,11 @@ config MCU_SCRATCHPAD_SIZE help Describes the size of MCU Scratchpad RAM.
+config BOOT_PARAM_TABLE_INDEX
- hex "Address of Array Index to be used within BOOT_PARAM_TABLE"
- default 0x41c7fbfc if SOC_K3_AM6
- help
Address at which ROM stores the value which determines if SPLis booted up by primary boot media or secondary boot media.
I'm not sure this belongs in Kconfig. This isn't configurable really is it?
+static u32 __get_backup_bootmedia(u32 devstat) {
- u32 bkup_boot = (devstat & CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;- switch (bkup_boot) {
+#define __BKUP_BOOT_DEVICE(n) \
- case BACKUP_BOOT_DEVICE_##n: \
return BOOT_DEVICE_##n;
I really don't like defining the macro in the function like this. And in terms of style, I think I'd rather see it spelled out with case/return as is normally done.
On Friday 24 August 2018 07:41 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:51PM +0530, Lokesh Vutla wrote:
AM654 allows for booting from primary or backup boot media. Both media can be chosen individually based on switch settings. ROM looks for a valid image in primary boot media, if not found then looks in backup boot media. In order to pass this boot media information to boot loader, ROM stores a value at a particular address. Add support for reading this information and determining the boot media correctly.
[snip]
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index c532fbd061..117e5b4e4a 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -40,4 +40,11 @@ config MCU_SCRATCHPAD_SIZE help Describes the size of MCU Scratchpad RAM.
+config BOOT_PARAM_TABLE_INDEX
- hex "Address of Array Index to be used within BOOT_PARAM_TABLE"
- default 0x41c7fbfc if SOC_K3_AM6
- help
Address at which ROM stores the value which determines if SPLis booted up by primary boot media or secondary boot media.I'm not sure this belongs in Kconfig. This isn't configurable really is it?
Agreed. Will drop the prompt string in v2.
+static u32 __get_backup_bootmedia(u32 devstat) {
- u32 bkup_boot = (devstat & CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;- switch (bkup_boot) {
+#define __BKUP_BOOT_DEVICE(n) \
- case BACKUP_BOOT_DEVICE_##n: \
return BOOT_DEVICE_##n;I really don't like defining the macro in the function like this. And in terms of style, I think I'd rather see it spelled out with case/return as is normally done.
Sure. Will fix it in v2.
Thanks and regards, Lokesh
From: Andreas Dannenberg dannenberg@ti.com
By default the device control module registers are locked, preventing any writes to its registers. Unlock those registers as part of the init flow.
Signed-off-by: Andreas Dannenberg dannenberg@ti.com Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- arch/arm/mach-k3/am6_init.c | 39 ++++++++++++++++++++ arch/arm/mach-k3/include/mach/am6_hardware.h | 21 +++++++++++ 2 files changed, 60 insertions(+)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c index 8a7cedf66f..d7f1dff1db 100644 --- a/arch/arm/mach-k3/am6_init.c +++ b/arch/arm/mach-k3/am6_init.c @@ -12,6 +12,42 @@ #include <asm/arch/hardware.h>
#ifdef CONFIG_SPL_BUILD +static void mmr_unlock(u32 base, u32 partition) +{ + /* Translate the base address */ + phys_addr_t part_base = base + partition * CTRL_MMR0_PARTITION_SIZE; + + /* Unlock the requested partition if locked using two-step sequence */ + writel(CTRLMMR_LOCK_KICK0_UNLOCK_VAL, part_base + CTRLMMR_LOCK_KICK0); + writel(CTRLMMR_LOCK_KICK1_UNLOCK_VAL, part_base + CTRLMMR_LOCK_KICK1); +} + +static void ctrl_mmr_unlock(void) +{ + /* Unlock all WKUP_CTRL_MMR0 module registers */ + mmr_unlock(WKUP_CTRL_MMR0_BASE, 0); + mmr_unlock(WKUP_CTRL_MMR0_BASE, 1); + mmr_unlock(WKUP_CTRL_MMR0_BASE, 2); + mmr_unlock(WKUP_CTRL_MMR0_BASE, 3); + mmr_unlock(WKUP_CTRL_MMR0_BASE, 6); + mmr_unlock(WKUP_CTRL_MMR0_BASE, 7); + + /* Unlock all MCU_CTRL_MMR0 module registers */ + mmr_unlock(MCU_CTRL_MMR0_BASE, 0); + mmr_unlock(MCU_CTRL_MMR0_BASE, 1); + mmr_unlock(MCU_CTRL_MMR0_BASE, 2); + mmr_unlock(MCU_CTRL_MMR0_BASE, 6); + + /* Unlock all CTRL_MMR0 module registers */ + mmr_unlock(CTRL_MMR0_BASE, 0); + mmr_unlock(CTRL_MMR0_BASE, 1); + mmr_unlock(CTRL_MMR0_BASE, 2); + mmr_unlock(CTRL_MMR0_BASE, 3); + mmr_unlock(CTRL_MMR0_BASE, 6); + mmr_unlock(CTRL_MMR0_BASE, 7); + +} + static void store_boot_index_from_rom(void) { u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL; @@ -27,6 +63,9 @@ void board_init_f(ulong dummy) */ store_boot_index_from_rom();
+ /* Make all control module registers accessible */ + ctrl_mmr_unlock(); + /* Init DM early in-order to invoke system controller */ spl_early_init();
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h index b56aa60ec7..62bc7262a3 100644 --- a/arch/arm/mach-k3/include/mach/am6_hardware.h +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h @@ -17,6 +17,27 @@ #define CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_MASK GENMASK(6, 4) #define CTRLMMR_MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT 4
+#define WKUP_CTRL_MMR0_BASE 0x43000000 +#define MCU_CTRL_MMR0_BASE 0x40f00000 + +/* + * The CTRL_MMR0 memory space is divided into several equally-spaced + * partitions, so defining the partition size allows us to determine + * register addresses common to those partitions. + */ +#define CTRL_MMR0_PARTITION_SIZE 0x4000 + +/* + * CTRL_MMR0, WKUP_CTRL_MMR0, and MCU_CTR_MMR0 lock/kick-mechanism + * shared register definitions. + */ +#define CTRLMMR_LOCK_KICK0 0x01008 +#define CTRLMMR_LOCK_KICK0_UNLOCK_VAL 0x68ef3490 +#define CTRLMMR_LOCK_KICK0_UNLOCKED_MASK BIT(0) +#define CTRLMMR_LOCK_KICK0_UNLOCKED_SHIFT 0 +#define CTRLMMR_LOCK_KICK1 0x0100c +#define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a + /* MCU SCRATCHPAD usage */ #define K3_BOOT_PARAM_TABLE_INDEX_VAL CONFIG_MCU_SCRATCHPAD_BASE
On Tue, Aug 21, 2018 at 08:00:52PM +0530, Lokesh Vutla wrote:
From: Andreas Dannenberg dannenberg@ti.com
By default the device control module registers are locked, preventing any writes to its registers. Unlock those registers as part of the init flow.
Signed-off-by: Andreas Dannenberg dannenberg@ti.com Signed-off-by: Lokesh Vutla lokeshvutla@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
Add MMU mappings for AM654 SoC.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- arch/arm/mach-k3/Makefile | 1 + arch/arm/mach-k3/arm64-mmu.c | 45 ++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 arch/arm/mach-k3/arm64-mmu.c
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index 356fc27b11..e9b7ee5210 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -4,3 +4,4 @@ # Lokesh Vutla lokeshvutla@ti.com
obj-$(CONFIG_SOC_K3_AM6) += am6_init.o +obj-$(CONFIG_ARM64) += arm64-mmu.o diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c new file mode 100644 index 0000000000..41a9dbf899 --- /dev/null +++ b/arch/arm/mach-k3/arm64-mmu.c @@ -0,0 +1,45 @@ +/* + * K3: ARM64 MMU setup + * + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla lokeshvutla@ti.com + * (This file is derived from arch/arm/cpu/armv8/zynqmp/cpu.c) + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <asm/system.h> +#include <asm/armv8/mmu.h> + +/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */ +#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3) + +/* ToDo: Add 64bit IO */ +struct mm_region am654_mem_map[NR_MMU_REGIONS] = { + { + .virt = 0x0UL, + .phys = 0x0UL, + .size = 0x80000000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | + PTE_BLOCK_NON_SHARE | + PTE_BLOCK_PXN | PTE_BLOCK_UXN + }, { + .virt = 0x80000000UL, + .phys = 0x80000000UL, + .size = 0x80000000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | + PTE_BLOCK_INNER_SHARE + }, { + .virt = 0x880000000UL, + .phys = 0x880000000UL, + .size = 0x80000000UL, + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | + PTE_BLOCK_INNER_SHARE + }, { + /* List terminator */ + 0, + } +}; + +struct mm_region *mem_map = am654_mem_map;
On Tue, Aug 21, 2018 at 08:00:53PM +0530, Lokesh Vutla wrote:
Add MMU mappings for AM654 SoC.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
Add a script that is capable of generating a FIT image source file that combines ATF, SPL(64 bit) and DT. This combined image is used by R5 SPL and start ATF on ARMv8 core.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- tools/k3/k3_fit_atf.sh | 98 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100755 tools/k3/k3_fit_atf.sh
diff --git a/tools/k3/k3_fit_atf.sh b/tools/k3/k3_fit_atf.sh new file mode 100755 index 0000000000..ef84e3d182 --- /dev/null +++ b/tools/k3/k3_fit_atf.sh @@ -0,0 +1,98 @@ +#!/bin/sh +# +# script to generate FIT image source for K3 Family boards with +# ATF, OPTEE, SPL and multiple device trees (given on the command line). +# Inspired from board/sunxi/mksunxi_fit_atf.sh +# +# usage: $0 <dt_name> [<dt_name> [<dt_name] ...] + +[ -z "$ATF" ] && ATF="bl31.bin" + +if [ ! -f $ATF ]; then + echo "WARNING ATF file $ATF NOT found, resulting binary is non-functional" >&2 + ATF=/dev/null +fi + +[ -z "$TEE" ] && TEE="bl32.bin" + +if [ ! -f $TEE ]; then + echo "WARNING OPTEE file $TEE NOT found, resulting might be non-functional" >&2 + TEE=/dev/null +fi + +cat << __HEADER_EOF +/dts-v1/; + +/ { + description = "Configuration to load ATF and SPL"; + #address-cells = <1>; + + images { + atf { + description = "ARM Trusted Firmware"; + data = /incbin/("$ATF"); + type = "firmware"; + arch = "arm64"; + compression = "none"; + os = "arm-trusted-firmware"; + load = <0x70000000>; + entry = <0x70000000>; + }; + tee { + description = "OPTEE"; + data = /incbin/("$TEE"); + type = "tee"; + arch = "arm64"; + compression = "none"; + os = "tee"; + load = <0x9e800000>; + entry = <0x9e800000>; + }; + spl { + description = "SPL (64-bit)"; + data = /incbin/("spl/u-boot-spl-nodtb.bin"); + type = "standalone"; + os = "U-Boot"; + arch = "arm64"; + compression = "none"; + load = <0x80080000>; + entry = <0x80080000>; + }; +__HEADER_EOF + +for dtname in $* +do + cat << __FDT_IMAGE_EOF + $(basename $dtname) { + description = "$(basename $dtname .dtb)"; + data = /incbin/("$dtname"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + }; +__FDT_IMAGE_EOF +done + +cat << __CONF_HEADER_EOF + }; + configurations { + default = "$(basename $1)"; + +__CONF_HEADER_EOF + +for dtname in $* +do + cat << __CONF_SECTION_EOF + $(basename $dtname) { + description = "$(basename $dtname .dtb)"; + firmware = "atf"; + loadables = "tee", "spl"; + fdt = "$(basename $dtname)"; + }; +__CONF_SECTION_EOF +done + +cat << __ITS_EOF + }; +}; +__ITS_EOF
On Tue, Aug 21, 2018 at 08:00:54PM +0530, Lokesh Vutla wrote:
Add a script that is capable of generating a FIT image source file that combines ATF, SPL(64 bit) and DT. This combined image is used by R5 SPL and start ATF on ARMv8 core.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com
tools/k3/k3_fit_atf.sh | 98 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100755 tools/k3/k3_fit_atf.sh
diff --git a/tools/k3/k3_fit_atf.sh b/tools/k3/k3_fit_atf.sh new file mode 100755 index 0000000000..ef84e3d182 --- /dev/null +++ b/tools/k3/k3_fit_atf.sh
I know we have one thing in tools/omap/ but I'd rather see this as just tools/k3_fit_atf.sh
@@ -0,0 +1,98 @@ +#!/bin/sh +#
Missing SPDX tag.
On Friday 24 August 2018 07:41 PM, Tom Rini wrote:
On Tue, Aug 21, 2018 at 08:00:54PM +0530, Lokesh Vutla wrote:
Add a script that is capable of generating a FIT image source file that combines ATF, SPL(64 bit) and DT. This combined image is used by R5 SPL and start ATF on ARMv8 core.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com
tools/k3/k3_fit_atf.sh | 98 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100755 tools/k3/k3_fit_atf.sh
diff --git a/tools/k3/k3_fit_atf.sh b/tools/k3/k3_fit_atf.sh new file mode 100755 index 0000000000..ef84e3d182 --- /dev/null +++ b/tools/k3/k3_fit_atf.sh
I know we have one thing in tools/omap/ but I'd rather see this as just tools/k3_fit_atf.sh
will fix it in v2.
@@ -0,0 +1,98 @@ +#!/bin/sh +#
Missing SPDX tag.
Oops. will add it.
Thanks and regards, Lokesh
Update Makefile to generate - tispl.bin: First stage bootloader on ARMv8 core - u-boot.img: Second stage bootloader on ARMv8 core.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- arch/arm/mach-k3/config.mk | 21 +++++++++++++++++++++ scripts/Makefile.spl | 9 +++++++++ 2 files changed, 30 insertions(+) create mode 100644 arch/arm/mach-k3/config.mk
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk new file mode 100644 index 0000000000..eb604a418e --- /dev/null +++ b/arch/arm/mach-k3/config.mk @@ -0,0 +1,21 @@ +# +# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/ +# Lokesh Vutla lokeshvutla@ti.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +ifdef CONFIG_SPL_BUILD + +ifdef CONFIG_ARM64 +SPL_ITS := u-boot-spl-k3.its +$(SPL_ITS): FORCE + $(srctree)/tools/k3/k3_fit_atf.sh \ + $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@ + +ALL-y += tispl.bin +endif + +else +ALL-y += u-boot.img +endif diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 252f13826d..e494d185e4 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -144,6 +144,10 @@ quiet_cmd_mkimage = MKIMAGE $@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \ >$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
+quiet_cmd_mkfitimage = MKIMAGE $@ +cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(SPL_ITS) -E $@ \ + $(if $(KBUILD_VERBOSE:1=), MKIMAGEOUTPUT) + MKIMAGEFLAGS_MLO = -T omapimage -a $(CONFIG_SPL_TEXT_BASE)
MKIMAGEFLAGS_MLO.byteswap = -T omapimage -n byteswap -a $(CONFIG_SPL_TEXT_BASE) @@ -407,3 +411,8 @@ $(obj)/$(SPL_BIN).multidtb.fit.gz: $(obj)/$(SPL_BIN).multidtb.fit
$(obj)/$(SPL_BIN).multidtb.fit.lzo: $(obj)/$(SPL_BIN).multidtb.fit @lzop -f9 $< > $@ + +ifdef CONFIG_ARCH_K3 +tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE + $(call if_changed,mkfitimage) +endif
On Tue, Aug 21, 2018 at 08:00:55PM +0530, Lokesh Vutla wrote:
Update Makefile to generate
- tispl.bin: First stage bootloader on ARMv8 core
- u-boot.img: Second stage bootloader on ARMv8 core.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
Am 21.08.2018 um 16:30 schrieb Lokesh Vutla lokeshvutla@ti.com:
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products.
The device is partitioned into three functional domains, each containing specific processing cores and peripherals: Some highlights in each domain are:
- MAIN Domain:
- Quad ARMv8 A53 cores split over two clusters
- GICv3 compliant GIC500
- Configurable L3 Cache and IO-coherent architecture
- DDR Subsystem (DDRSS) with Error Correcting Code (ECC)
- Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
- Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
- eQEP/eCAP, eHRPWM.
- Multimedia capability with CAL, DSS7-UL, SGX544, McASP
- Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
- MCU Domain:
- Dual lock-step capable R5F uC for safety-critical applications
- Flash subsystem with OSPI and Hyperbus interfaces
- High data throughput capable distributed DMA architecture under MCU NAVSS
- Dual ADCSS, Dual CAN-FD.
- WKUP Domain:
- Centralized System Controller for Security, Power, and Resource
management.
For further deails see AM65x Technical Reference Manual (SPRUID7, April 2018): http://www.ti.com/lit/pdf/spruid7
This is a complex SoC and the support to add this SoC is very huge. So I tried to split into 3 separate series: [1/3] Adding base SoC support [2/3] Base drivers that allow minimal boot. [3/3] EVM support with dts and defconfig changes.
This series adds base SoC support. The rest of the two series will be a follow up of this series.
On AM65x family devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, keeping safety in picture and to have faster boot time, the software boot architecture is designed as: https://pastebin.ubuntu.com/p/NxSvDbMtSk/ Any feedback is highly appreciated.
I don't quite understand why you'd need to have an SPL after ATF on the A53? At that point you should already have DRAM initialized and can just skip straight to U-Boot proper, no?
Alex
Hi Alex,
On Sunday 26 August 2018 11:41 AM, Alexander Graf wrote:
Am 21.08.2018 um 16:30 schrieb Lokesh Vutla lokeshvutla@ti.com:
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products.
The device is partitioned into three functional domains, each containing specific processing cores and peripherals: Some highlights in each domain are:
- MAIN Domain:
- Quad ARMv8 A53 cores split over two clusters
- GICv3 compliant GIC500
- Configurable L3 Cache and IO-coherent architecture
- DDR Subsystem (DDRSS) with Error Correcting Code (ECC)
- Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
- Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
- eQEP/eCAP, eHRPWM.
- Multimedia capability with CAL, DSS7-UL, SGX544, McASP
- Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
- MCU Domain:
- Dual lock-step capable R5F uC for safety-critical applications
- Flash subsystem with OSPI and Hyperbus interfaces
- High data throughput capable distributed DMA architecture under MCU NAVSS
- Dual ADCSS, Dual CAN-FD.
- WKUP Domain:
- Centralized System Controller for Security, Power, and Resource
management.
For further deails see AM65x Technical Reference Manual (SPRUID7, April 2018): http://www.ti.com/lit/pdf/spruid7
This is a complex SoC and the support to add this SoC is very huge. So I tried to split into 3 separate series: [1/3] Adding base SoC support [2/3] Base drivers that allow minimal boot. [3/3] EVM support with dts and defconfig changes.
This series adds base SoC support. The rest of the two series will be a follow up of this series.
On AM65x family devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, keeping safety in picture and to have faster boot time, the software boot architecture is designed as: https://pastebin.ubuntu.com/p/NxSvDbMtSk/ Any feedback is highly appreciated.
I don't quite understand why you'd need to have an SPL after ATF on the A53? At that point you should already have DRAM initialized and can just skip straight to U-Boot proper, no?
Agreed, on a first look it doesn't seem right to run SPL after ATF. But after a lot of discussions internally (considering all the use cases) we agreed upon this boot flow based on the following reasons: 1) Need to move away from R5 asap, so that we want to start *any* firmware on the r5 cores like.... autosar can be loaded to receive CAN response and other safety operations to be started. This operation is very time critical and is applicable for all automotive use cases. (Considering this, loading SPL is faster than loading U-boot) 2) U-Boot on A53 should start other remotecores for various applications. This should happen before running Linux. 2) In production boot flow, we might not like to use full u-boot, instead use Flacon boot flow to reduce boot time. 3) Boot flow should be consistent across all k3 family of devices which might be targeting different markets.
Thanks and regards, Lokesh
Alex
Hi Lokesh,
On 27.08.18 11:31, Lokesh Vutla wrote:
Hi Alex,
On Sunday 26 August 2018 11:41 AM, Alexander Graf wrote:
Am 21.08.2018 um 16:30 schrieb Lokesh Vutla lokeshvutla@ti.com:
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products.
The device is partitioned into three functional domains, each containing specific processing cores and peripherals: Some highlights in each domain are:
- MAIN Domain:
- Quad ARMv8 A53 cores split over two clusters
- GICv3 compliant GIC500
- Configurable L3 Cache and IO-coherent architecture
- DDR Subsystem (DDRSS) with Error Correcting Code (ECC)
- Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
- Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
- eQEP/eCAP, eHRPWM.
- Multimedia capability with CAL, DSS7-UL, SGX544, McASP
- Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
- MCU Domain:
- Dual lock-step capable R5F uC for safety-critical applications
- Flash subsystem with OSPI and Hyperbus interfaces
- High data throughput capable distributed DMA architecture under MCU NAVSS
- Dual ADCSS, Dual CAN-FD.
- WKUP Domain:
- Centralized System Controller for Security, Power, and Resource
management.
For further deails see AM65x Technical Reference Manual (SPRUID7, April 2018): http://www.ti.com/lit/pdf/spruid7
This is a complex SoC and the support to add this SoC is very huge. So I tried to split into 3 separate series: [1/3] Adding base SoC support [2/3] Base drivers that allow minimal boot. [3/3] EVM support with dts and defconfig changes.
This series adds base SoC support. The rest of the two series will be a follow up of this series.
On AM65x family devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, keeping safety in picture and to have faster boot time, the software boot architecture is designed as: https://pastebin.ubuntu.com/p/NxSvDbMtSk/ Any feedback is highly appreciated.
I don't quite understand why you'd need to have an SPL after ATF on the A53? At that point you should already have DRAM initialized and can just skip straight to U-Boot proper, no?
Agreed, on a first look it doesn't seem right to run SPL after ATF. But after a lot of discussions internally (considering all the use cases) we agreed upon this boot flow based on the following reasons:
- Need to move away from R5 asap, so that we want to start *any*
firmware on the r5 cores like.... autosar can be loaded to receive CAN response and other safety operations to be started. This operation is very time critical and is applicable for all automotive use cases. (Considering this, loading SPL is faster than loading U-boot)
I think this is a very reasonable explanation. It should probably be part of whatever document you provide to people that explains the boot flow ;).
- U-Boot on A53 should start other remotecores for various
applications. This should happen before running Linux.
This can happen without SPL just the same, no?
- In production boot flow, we might not like to use full u-boot,
instead use Flacon boot flow to reduce boot time.
Also an interesting argument. Same comment as 1).
- Boot flow should be consistent across all k3 family of devices which
might be targeting different markets.
I don't know if I fully understand this part.
Alex
On Monday 27 August 2018 03:22 PM, Alexander Graf wrote:
Hi Lokesh,
On 27.08.18 11:31, Lokesh Vutla wrote:
Hi Alex,
On Sunday 26 August 2018 11:41 AM, Alexander Graf wrote:
Am 21.08.2018 um 16:30 schrieb Lokesh Vutla lokeshvutla@ti.com:
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products.
The device is partitioned into three functional domains, each containing specific processing cores and peripherals: Some highlights in each domain are:
- MAIN Domain:
- Quad ARMv8 A53 cores split over two clusters
- GICv3 compliant GIC500
- Configurable L3 Cache and IO-coherent architecture
- DDR Subsystem (DDRSS) with Error Correcting Code (ECC)
- Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
- Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
- eQEP/eCAP, eHRPWM.
- Multimedia capability with CAL, DSS7-UL, SGX544, McASP
- Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
- MCU Domain:
- Dual lock-step capable R5F uC for safety-critical applications
- Flash subsystem with OSPI and Hyperbus interfaces
- High data throughput capable distributed DMA architecture under MCU NAVSS
- Dual ADCSS, Dual CAN-FD.
- WKUP Domain:
- Centralized System Controller for Security, Power, and Resource
management.
For further deails see AM65x Technical Reference Manual (SPRUID7, April 2018): http://www.ti.com/lit/pdf/spruid7
This is a complex SoC and the support to add this SoC is very huge. So I tried to split into 3 separate series: [1/3] Adding base SoC support [2/3] Base drivers that allow minimal boot. [3/3] EVM support with dts and defconfig changes.
This series adds base SoC support. The rest of the two series will be a follow up of this series.
On AM65x family devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, keeping safety in picture and to have faster boot time, the software boot architecture is designed as: https://pastebin.ubuntu.com/p/NxSvDbMtSk/ Any feedback is highly appreciated.
I don't quite understand why you'd need to have an SPL after ATF on the A53? At that point you should already have DRAM initialized and can just skip straight to U-Boot proper, no?
Agreed, on a first look it doesn't seem right to run SPL after ATF. But after a lot of discussions internally (considering all the use cases) we agreed upon this boot flow based on the following reasons:
- Need to move away from R5 asap, so that we want to start *any*
firmware on the r5 cores like.... autosar can be loaded to receive CAN response and other safety operations to be started. This operation is very time critical and is applicable for all automotive use cases. (Considering this, loading SPL is faster than loading U-boot)
I think this is a very reasonable explanation. It should probably be part of whatever document you provide to people that explains the boot flow ;).
Sure will add it in my v2.
- U-Boot on A53 should start other remotecores for various
applications. This should happen before running Linux.
This can happen without SPL just the same, no?
This is for justifying that there should be atleast one bootloader to be on ARM64. basically I am avoiding the case "R5-SPL -> ATF -> Linux" to happen.
- In production boot flow, we might not like to use full u-boot,
instead use Flacon boot flow to reduce boot time.
Also an interesting argument. Same comment as 1).
- Boot flow should be consistent across all k3 family of devices which
might be targeting different markets.
I don't know if I fully understand this part.
Ill probably drop this one to reduce the confusion :)
Thanks and regards, Lokesh
participants (3)
-
Alexander Graf -
Lokesh Vutla -
Tom Rini