[U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform

[Lokesh Vutla]

Hi Alex,

On Sunday 26 August 2018 11:41 AM, Alexander Graf wrote:
> 
> 
>> Am 21.08.2018 um 16:30 schrieb Lokesh Vutla <lokeshvutla at 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
> 
>