[00/26] TI J7 SoC HSM Rearch support series

Message ID	20201110090602.2255-1-t-kristo@ti.com
Headers	show Return-Path: <u-boot-bounces@lists.denx.de> From: Tero Kristo <t-kristo@ti.com> To: <u-boot@lists.denx.de>, <trini@konsulko.com>, <lokeshvutla@ti.com> CC: <praneeth@ti.com>, <d-gerlach@ti.com> Subject: [PATCH 00/26] TI J7 SoC HSM Rearch support series Date: Tue, 10 Nov 2020 11:05:36 +0200 Message-ID: <20201110090602.2255-1-t-kristo@ti.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: list Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" <u-boot-bounces@lists.denx.de>
Series	TI J7 SoC HSM Rearch support series \| expand [00/26] TI J7 SoC HSM Rearch support series [01/26] lib: rational: copy the rational fraction lib routines from Linux [02/26] ram: k3-j721e: fix clk_set_rate API usage [03/26] remoteproc: k3-r5: remove sysfw PM calls if not supported [04/26] common: fit: Update board_fit_image_post_process() to pass fit and node_offset [05/26] clk: fixed_rate: add API for directly registering fixed rate clocks [06/26] clk: fix clock tree dump to properly dump out every registered clock [07/26] clk: do not attempt to fetch clock pointer with null device [08/26] clk: add support for setting clk rate from cmdline [09/26] clk: sci-clk: fix return value of set_rate [10/26] clk: fix assigned-clocks to pass with deferring provider [11/26] clk: fix set_rate to clean up cached rates for the hierarchy [12/26] clk: add support for TI K3 SoC PLL [13/26] clk: add support for TI K3 SoC clocks [14/26] power: domain: Introduce driver for raw TI K3 PDs [15/26] cmd: ti: pd: Add debug command for K3 power domains [16/26] tools: k3_fit_atf: add DM binary to the FIT image [17/26] arm: mach-k3: Add platform data for j721e and j7200 [18/26] arm: mach-k3: add support for detecting firmware images from FIT [19/26] arm: mach-k3: j721e: force enable A72 core 0 during spl shutdown [20/26] arm: mach-k3: do board config for PM and RM only if supported [21/26] arm: mach-k3: common: Drop main r5 start [22/26] arm: mach-k3: sysfw-loader: pass boardcfg to sciserver [23/26] configs: j721e_evm_r5: Enable raw access power management features [24/26] configs: j721e_evm_r5: disable SCI PM drivers [25/26] configs: j721e_evm_r5: enable FIT image post processing [26/26] configs: j7200_evm_r5: Enable raw access power management features

Message ID

20201110090602.2255-1-t-kristo@ti.com

Headers

From: Tero Kristo <t-kristo@ti.com>
To: <u-boot@lists.denx.de>, <trini@konsulko.com>, <lokeshvutla@ti.com>
CC: <praneeth@ti.com>, <d-gerlach@ti.com>
Subject: [PATCH 00/26] TI J7 SoC HSM Rearch support series
Date: Tue, 10 Nov 2020 11:05:36 +0200
Message-ID: <20201110090602.2255-1-t-kristo@ti.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: u-boot-bounces@lists.denx.de
Sender: "U-Boot" <u-boot-bounces@lists.denx.de>

Series

TI J7 SoC HSM Rearch support series | expand

Message

Tero Kristo Nov. 10, 2020, 9:05 a.m. UTC

Hello,

On TI J7 SoCs the device manager firmware is now split into two
portions instead of the existing one which supported all services via a
single firmware image running on DMSC core. Now, the existing DMSC core
is dedicated for secure services only, and the PM and RM functionality
is moved under a separate firmware image running on MCU R5 core. This
is completely transparent for the firmware users, as the existing
messaging mechanism (TI-SCI) routes everything to proper destination,
except for anything that runs on MCU R5, and in our case it happens
to be R5 SPL bootloader.

To support the firmware split, R5 SPL implementation must be changed in
a way that it implements its own PM features, as these are needed during
boot time. This series thus implements a couple of new drivers, PLL
clock driver for the SoCs, and also a generic clock provider driver which
is used to attach device drivers to proper clock entries. Also
implemented is a power domain driver to power up/down IP blocks. R5
SPL bootloader also now needs to load and start the new DM firmware image
and this is handled in the series.

There are also a number of fixes attached to the series for fixing
issues noticed while implementing the new drivers, mostly on the generic
clock drivers side. I decided to keep the series as a single chunk for
now, as it probably makes it easier to see why certain things are done.
Let me know if you want me to split this series somehow.

-Tero

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Comments

Lokesh Vutla Nov. 16, 2020, 4:13 a.m. UTC | #1

On 10/11/20 2:35 pm, Tero Kristo wrote:
> Hello,
> 
> On TI J7 SoCs the device manager firmware is now split into two
> portions instead of the existing one which supported all services via a
> single firmware image running on DMSC core. Now, the existing DMSC core
> is dedicated for secure services only, and the PM and RM functionality
> is moved under a separate firmware image running on MCU R5 core. This
> is completely transparent for the firmware users, as the existing
> messaging mechanism (TI-SCI) routes everything to proper destination,
> except for anything that runs on MCU R5, and in our case it happens
> to be R5 SPL bootloader.

Can you update board/ti/j721e/README with the detail of the boot flow and build
steps?

Thanks and regards,
Lokesh

Tero Kristo Nov. 16, 2020, 12:13 p.m. UTC | #2

On 16/11/2020 06:13, Lokesh Vutla wrote:
> 
> 
> On 10/11/20 2:35 pm, Tero Kristo wrote:
>> Hello,
>>
>> On TI J7 SoCs the device manager firmware is now split into two
>> portions instead of the existing one which supported all services via a
>> single firmware image running on DMSC core. Now, the existing DMSC core
>> is dedicated for secure services only, and the PM and RM functionality
>> is moved under a separate firmware image running on MCU R5 core. This
>> is completely transparent for the firmware users, as the existing
>> messaging mechanism (TI-SCI) routes everything to proper destination,
>> except for anything that runs on MCU R5, and in our case it happens
>> to be R5 SPL bootloader.
> 
> Can you update board/ti/j721e/README with the detail of the boot flow and build
> steps?

Sure, I can craft additional patch for that purpose. Its good that j7 
has its separate doc actually, so am65x can stay in its current form.

-Tero

> 
> Thanks and regards,
> Lokesh
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Tom Rini Nov. 16, 2020, 3:53 p.m. UTC | #3

On Mon, Nov 16, 2020 at 02:13:03PM +0200, Tero Kristo wrote:
> On 16/11/2020 06:13, Lokesh Vutla wrote:
> > 
> > 
> > On 10/11/20 2:35 pm, Tero Kristo wrote:
> > > Hello,
> > > 
> > > On TI J7 SoCs the device manager firmware is now split into two
> > > portions instead of the existing one which supported all services via a
> > > single firmware image running on DMSC core. Now, the existing DMSC core
> > > is dedicated for secure services only, and the PM and RM functionality
> > > is moved under a separate firmware image running on MCU R5 core. This
> > > is completely transparent for the firmware users, as the existing
> > > messaging mechanism (TI-SCI) routes everything to proper destination,
> > > except for anything that runs on MCU R5, and in our case it happens
> > > to be R5 SPL bootloader.
> > 
> > Can you update board/ti/j721e/README with the detail of the boot flow and build
> > steps?
> 
> Sure, I can craft additional patch for that purpose. Its good that j7 has
> its separate doc actually, so am65x can stay in its current form.

And can we please find some time to convert all of these to rST and move
under doc/board/ ?  Thanks!