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