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

[Lokesh Vutla <lokeshvutla@ti.com>]

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:
>> 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