From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lokesh Vutla Date: Mon, 27 Aug 2018 15:37:21 +0530 Subject: [U-Boot] [PATCH 0/8] [1/3] Initial support Texas Instrument's AM654 Platform In-Reply-To: <8528e230-9d7d-6cb0-08c7-a8e207fa22d1@suse.de> References: <20180821143055.29012-1-lokeshvutla@ti.com> <61EC8465-1533-419C-B1E5-09626858DB13@suse.de> <8528e230-9d7d-6cb0-08c7-a8e207fa22d1@suse.de> Message-ID: <730b687e-98ff-bf71-c9e3-cb673771b108@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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