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 <lokeshvu...@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)
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
