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
