Re: [U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform
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 : 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) > > 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. > >> 2) 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. > >> 2) 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). > >> 3) 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform
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 : >>> >>> 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) 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 ;). > 2) 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? > 2) 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). > 3) 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform
Hi Alex, On Sunday 26 August 2018 11:41 AM, Alexander Graf wrote: > > >> Am 21.08.2018 um 16:30 schrieb Lokesh Vutla : >> >> 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 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform
> Am 21.08.2018 um 16:30 schrieb Lokesh Vutla : > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[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 -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
