[EXTERNAL] Re: [PATCH V2 0/9] board: k3: Sync rm-cfg with TIFS v11.02.09 firmware

[Sparsh Kumar]

On 21/04/26 8:46 pm, Ernest Van Hoecke wrote:
> On Wed, Feb 25, 2026 at 09: 17: 03PM +0530, Sparsh Kumar wrote: > On 
> 25/02/26 8: 40 pm, Tom Rini wrote: > > On Wed, Feb 25, 2026 at 06: 54:  
> 16PM +0530, Sparsh Kumar wrote: > > > > > This series updates the 
> Resource Management
> ZjQcmQRYFpfptBannerStart
> This message was sent from outside of Texas Instruments.
> Do not click links or open attachments unless you recognize the source 
> of this email and know the content is safe.
> Report Suspicious
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK! 
> tJdi1lwHPC1bga2NF3tIVrcuzWKosV1nyLqwWw3W9oiThr2cg3_QFMBFOt-- 
> e_D6WG7bRsTVT0QRq3fBi6wrfylqlm3Aj1v28uBtLAjlNJLSssbTwvOWqfU$>
> ZjQcmQRYFpfptBannerEnd
> 
> On Wed, Feb 25, 2026 at 09:17:03PM +0530, Sparsh Kumar wrote:
>> On 25/02/26 8:40 pm, Tom Rini wrote:
>> > On Wed, Feb 25, 2026 at 06:54:16PM +0530, Sparsh Kumar wrote:
>> > 
>> > > This series updates the Resource Management (RM) configuration files
>> > > for AM62 family devices to align with the TIFS v11.02.09 firmware.
>> > > 
>> > > Background
>> > > ----------
>> > > With the latest TIFS firmware (v11.02.09), an additional virtual
>> > > interrupt and event is reserved for MCU cores to DM usage on am62x,
>> > > am62ax, and am62px devices. This series brings the rm-cfg and
>> > > tifs-rm-cfg files in sync with these firmware changes across both
>> > > TI reference boards and vendor boards.
>> > > 
>> > > These changes are backward compatible with older TIFS firmware versions.
>> > > 
>> > > Additionally, the am62x platform was originally introduced without a
>> > > tifs-rm-cfg.yaml file, unlike other platforms in the AM62 family.
>> > > This series addresses that gap and enables tifs-rm-cfg in binman for
>> > > am625-sk and am62p-sk platforms.
>> > > 
>> > > Changes
>> > > -------
>> > > TI reference boards (patches 1-4):
>> > >    - Update rm-cfg.yaml for am62x, am62ax, am62px
>> > >    - Sync am62px tifs-rm-cfg.yaml with TIFS firmware template
>> > >    - Add missing tifs-rm-cfg.yaml for am62x
>> > >    - Enable tifs-rm-cfg in binman for am625-sk and am62p-sk
>> > > 
>> > > Vendor boards (patches 5-9):
>> > >    - beagleplay (am62x-based)
>> > >    - phytec phycore_am62x
>> > >    - toradex verdin-am62
>> > >    - phytec phycore_am62ax
>> > >    - toradex verdin-am62p
>> > > 
>> > > Note: For vendor boards, this series only updates the rm-cfg.yaml files
>> > > with the required interrupt reservation. The tifs-rm-cfg.yaml files
>> > > cannot be updated without access to the corresponding SysConfig files,
>> > > as both rm-cfg.yaml and tifs-rm-cfg.yaml must remain in sync.
>> > 
>> > Do I read this right, and the vendor boards will now be broken?
>> > 
>> Hello Tom,
>> 
>> No, the vendor boards will not be broken by these changes.
>> 
>> While it is generally recommended to keep rm-cfg.yaml and tifs-rm-cfg.yaml
>> in sync, the specific changes in this series do not require corresponding
>> tifs-rm-cfg.yaml updates for vendor boards:
>> 
>>   1. AM62ax and AM62px: The global events reservation change in rm-cfg.yaml
>> has no corresponding entry in tifs-rm-cfg.yaml, so no sync is needed.
>>   2. AM62x: The virtual interrupt change would ideally need a similar update
>> in tifs-rm-cfg.yaml, but none of the vendor boards have this file. This
>> series introduces tifs-rm-cfg.yaml only for TI reference board to align with
>> other K3 devices.
>>
> 
> Hi Sparsh,
> 
> I'm evaluating whether we (Toradex) should start including this
> tifs-rm-cfg.yaml file. Could you expand on when this is required?
> 
>  From the documentation I gather that the tifs config is a cut-down
> version of rm-cfg.yaml, only meant for TIFS consumption.
> Furthermore, doc/board/ti/k3.rst mentions:
>      Devices with a split firmware will have two firmwares loaded into the
>      device at different times during the bootup process. TI’s Foundational
>      Security (TIFS), needed to operate the Security Management Subsystem,
>      will either be loaded by ROM or the WKUP U-Boot SPL, then once the
>      wakeup U-Boot SPL has completed, the second Device Management (DM)
>      firmware can be loaded on the now free core in the wakeup domain.
> 
> Is this a necessity for secure boot, or how is it used?
> 
> Thanks for the help and kind regards,
> Ernest
> 

Hi Ernest,

Apologies for the delayed response.

The M4 core that runs TIFS has far less memory available (176KB) than 
the WKUP/DM R5 core. To keep the memory footprint as small as possible 
we trim the full RM board configuration down to only the entries that 
TIFS needs and store the result in `tifs‑rm‑cfg.yaml`.

A couple of important points:

1. Both `rm‑cfg.yaml` and `tifs‑rm‑cfg.yaml` are generated automatically.
    We use the K3 Resource Configuration Tool (formerly the K3 Resource 
Partitioning Tool) to generate the files from the SysConfig file and 
then copy the generated YAML files into U‑Boot. No manual editing is 
involved.

2. By using a smaller board‑config file we free up RAM on the M4, 
preserving space for future features or extensions.

3. Secure‑boot relevance - The `tifs‑rm‑cfg.yaml` does not play any 
direct role in the secure‑boot process; it is simply a streamlined copy 
of `rm‑cfg.yaml` that contains only the TIFS‑specific resources.

Please let me know if any part of this explanation is unclear or if you 
need more detail on a specific step. Happy to elaborate!

-- 
Best Regards,
Sparsh