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

[Alexander Graf <agraf@suse.de>]

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 ;).

> 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