[meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Franz Schnyder]

From: Franz Schnyder <franz.schnyder@toradex.com>

The `ti-eth-fw-j784s4` firmware is added in the generic J784s4 SoC
include, which is therefore used for all the J784s4-based machines.
That firmware seems to be developed specifically for the EVM, as it
takes control of pins used for the Ethernet board setup on the EVM. On
non-EVM boards, like the Aquila-AM69, those signals are used for other
functions, so enabling the firmware in the SoC include is too broad
and breaks functionality.

Move the machine-essential recommend from the SoC include
to the EVM configuration.

Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
 meta-ti-bsp/conf/machine/include/j784s4.inc | 2 +-
 meta-ti-bsp/conf/machine/j784s4-evm.conf    | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta-ti-bsp/conf/machine/include/j784s4.inc b/meta-ti-bsp/conf/machine/include/j784s4.inc
index 4dc3a71b..e0ce81b5 100644
--- a/meta-ti-bsp/conf/machine/include/j784s4.inc
+++ b/meta-ti-bsp/conf/machine/include/j784s4.inc
@@ -12,7 +12,7 @@ TFA_BOARD = "j784s4"
 
 OPTEEMACHINE = "k3-j784s4"
 
-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "cadence-mhdp-fw cnm-wave-fw ti-eth-fw-j784s4"
+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "cadence-mhdp-fw cnm-wave-fw"
 
 TI_CORE_INITRAMFS_KERNEL_MODULES = "kernel-module-cdns-pltfrm kernel-module-ti-j721e-ufs"
 TI_CORE_INITRAMFS_KERNEL_MODULES:bsp-ti-6_6 = ""
diff --git a/meta-ti-bsp/conf/machine/j784s4-evm.conf b/meta-ti-bsp/conf/machine/j784s4-evm.conf
index bf53b07c..f80e030f 100644
--- a/meta-ti-bsp/conf/machine/j784s4-evm.conf
+++ b/meta-ti-bsp/conf/machine/j784s4-evm.conf
@@ -27,3 +27,5 @@ KERNEL_DEVICETREE = " \
 "
 
 UBOOT_MACHINE = "j784s4_evm_a72_defconfig"
+
+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS:append = " ti-eth-fw-j784s4"
-- 
2.43.0

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Francesco Dolcini]

+Andrew

Hello Ryan,

On Wed, Apr 15, 2026 at 01:41:04PM +0200, Franz Schnyder wrote:
> From: Franz Schnyder <franz.schnyder@toradex.com>
> 
> The `ti-eth-fw-j784s4` firmware is added in the generic J784s4 SoC
> include, which is therefore used for all the J784s4-based machines.
> That firmware seems to be developed specifically for the EVM, as it
> takes control of pins used for the Ethernet board setup on the EVM. On
> non-EVM boards, like the Aquila-AM69, those signals are used for other
> functions, so enabling the firmware in the SoC include is too broad
> and breaks functionality.
> 
> Move the machine-essential recommend from the SoC include
> to the EVM configuration.
> 
> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>

This seems to be the 3rd time, in a relatively short time, in which
we are affected by your decision to put into the SoC file, configuration
that are not about the SOC

 1 - the initramfs topic [https://lore.kernel.org/yocto-meta-ti/78ec394aae8a141ceb87a6b67f109665e7c96122.camel@gmail.com/]
 2 - the console uart [https://lore.kernel.org/yocto-meta-ti/4e08fa3658b1e54add6d5476c7234e86dbcbb60c.camel@gmail.com/]
 3 - this firmware 


Can I ask TI once more to rethink this considering that meta-ti is used
by users of your SoC, but not of your EVK/SK ?

Thanks,
Francesco

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Andrew Davis]

On 4/15/26 6:58 AM, Francesco Dolcini wrote:
> +Andrew
> 
> Hello Ryan,
> 
> On Wed, Apr 15, 2026 at 01:41:04PM +0200, Franz Schnyder wrote:
>> From: Franz Schnyder <franz.schnyder@toradex.com>
>>
>> The `ti-eth-fw-j784s4` firmware is added in the generic J784s4 SoC
>> include, which is therefore used for all the J784s4-based machines.
>> That firmware seems to be developed specifically for the EVM, as it
>> takes control of pins used for the Ethernet board setup on the EVM. On
>> non-EVM boards, like the Aquila-AM69, those signals are used for other
>> functions, so enabling the firmware in the SoC include is too broad
>> and breaks functionality.
>>
>> Move the machine-essential recommend from the SoC include
>> to the EVM configuration.
>>
>> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> 
> This seems to be the 3rd time, in a relatively short time, in which
> we are affected by your decision to put into the SoC file, configuration
> that are not about the SOC
> 
>   1 - the initramfs topic [https://lore.kernel.org/yocto-meta-ti/78ec394aae8a141ceb87a6b67f109665e7c96122.camel@gmail.com/]
>   2 - the console uart [https://lore.kernel.org/yocto-meta-ti/4e08fa3658b1e54add6d5476c7234e86dbcbb60c.camel@gmail.com/]

I thought we solved this one by making the console selection more easily
updated in the board files. If we want to go one step further and remove
the defaults from the SoC level and always select the board specific UART
in each board config I wouldn't oppose that either.

>   3 - this firmware
> 

This firmware was a miss on our part, we were not aware that it was
not generic for all boards using this SoC but instead does some EVM
specific pinmuxing. I've looked into the FW source and can see where
that happens, I'll work to see how we can fix that. In the mean time
I agree then we should move this firmware to the board level (as the
patch does).

> 
> Can I ask TI once more to rethink this considering that meta-ti is used
> by users of your SoC, but not of your EVK/SK ?
> 

We do think a lot about external users of meta-ti, we even made a whole
split out reference layer (meta-beagle) that we treat like a normal vendor
layer so that we can more easily identify when we are making bad assumptions
that only apply to our EVM/SK boards. Yes we do still sometimes get it wrong,
and so we are very happy that you are providing the feedback that you have
and helping point out those cases.

If I'm not mistaken the initramfs topic is the only outstanding case
where what goes in the SoC file vs board files is still open and we
should continue to try to find the best solution.

Thanks,
Andrew

> Thanks,
> Francesco
> 

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Francesco Dolcini]

On Wed, Apr 15, 2026 at 09:43:31AM -0500, Andrew Davis wrote:
> On 4/15/26 6:58 AM, Francesco Dolcini wrote:
> > Can I ask TI once more to rethink this considering that meta-ti is used
> > by users of your SoC, but not of your EVK/SK ?
> > 
> 
> We do think a lot about external users of meta-ti, we even made a whole
> split out reference layer (meta-beagle) that we treat like a normal vendor
> layer so that we can more easily identify when we are making bad assumptions
> that only apply to our EVM/SK boards. Yes we do still sometimes get it wrong,
> and so we are very happy that you are providing the feedback that you have
> and helping point out those cases.
> 
> If I'm not mistaken the initramfs topic is the only outstanding case
> where what goes in the SoC file vs board files is still open and we
> should continue to try to find the best solution.
> 

Thanks a lot Andrew, I really appreciate this message. I do not mind at
all bugs or sending patches or having some temporary workaround in our
layers, I was concerned we were not on the same page on the main topic
here.

Your message solves all of these concerns.

In case you want to have a look at Toradex OE machine conf files
they are here [1], and here [2] you can find as an example verdin-am62.

Francesco


[1] https://git.toradex.com/meta-toradex-ti.git/tree/conf/machine
[2] https://git.toradex.com/meta-toradex-ti.git/tree/conf/machine/verdin-am62.conf

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Denys Dmytriyenko]

On Wed, Apr 15, 2026 at 09:43:31AM -0500, Andrew Davis via lists.yoctoproject.org wrote:
> On 4/15/26 6:58 AM, Francesco Dolcini wrote:
> >+Andrew
> >
> >Hello Ryan,
> >
> >On Wed, Apr 15, 2026 at 01:41:04PM +0200, Franz Schnyder wrote:
> >>From: Franz Schnyder <franz.schnyder@toradex.com>
> >>
> >>The `ti-eth-fw-j784s4` firmware is added in the generic J784s4 SoC
> >>include, which is therefore used for all the J784s4-based machines.
> >>That firmware seems to be developed specifically for the EVM, as it
> >>takes control of pins used for the Ethernet board setup on the EVM. On
> >>non-EVM boards, like the Aquila-AM69, those signals are used for other
> >>functions, so enabling the firmware in the SoC include is too broad
> >>and breaks functionality.
> >>
> >>Move the machine-essential recommend from the SoC include
> >>to the EVM configuration.
> >>
> >>Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> >
> >This seems to be the 3rd time, in a relatively short time, in which
> >we are affected by your decision to put into the SoC file, configuration
> >that are not about the SOC
> >
> >  1 - the initramfs topic [https://lore.kernel.org/yocto-meta-ti/78ec394aae8a141ceb87a6b67f109665e7c96122.camel@gmail.com/]
> >  2 - the console uart [https://lore.kernel.org/yocto-meta-ti/4e08fa3658b1e54add6d5476c7234e86dbcbb60c.camel@gmail.com/]
> 
> I thought we solved this one by making the console selection more easily
> updated in the board files. If we want to go one step further and remove
> the defaults from the SoC level and always select the board specific UART
> in each board config I wouldn't oppose that either.

I was going to reply to the end of the thread, but this entire section of the 
discussion was completely removed, hence I will do it here.

We've discussed this quite a lot internally and we ended up going with what 
Andrew is saying here.

There's this concept of "sane defaults" that covers most of the cases and it 
makes sense to set them as such. We have tens of platforms using this default 
UART configuration and it makes perfect sense to set it once, instead of 
copying the same over and over again - it is a maintenance pitfall. But we 
also make sure to allow very easy and effortless overriding of this default, 
if, for some reason, a specific board implementation doesn't follow this 
default.

There are lots and lots of similar examples when an upstream layer, including 
OE-Core, sets a sane default that may not match your configuration, but as 
long as it allows easy override downstream, it's not the end of the world.


> >  3 - this firmware
> >
> 
> This firmware was a miss on our part, we were not aware that it was
> not generic for all boards using this SoC but instead does some EVM
> specific pinmuxing. I've looked into the FW source and can see where
> that happens, I'll work to see how we can fix that. In the mean time
> I agree then we should move this firmware to the board level (as the
> patch does).

Here I agree with Andrew - it was an oversight and if it does per-board 
pinmuxing, then it belongs in a board config. That said, please address my 
comment for the patch before merging.


> >Can I ask TI once more to rethink this considering that meta-ti is used
> >by users of your SoC, but not of your EVK/SK ?
> >
> 
> We do think a lot about external users of meta-ti, we even made a whole
> split out reference layer (meta-beagle) that we treat like a normal vendor
> layer so that we can more easily identify when we are making bad assumptions
> that only apply to our EVM/SK boards. Yes we do still sometimes get it wrong,
> and so we are very happy that you are providing the feedback that you have
> and helping point out those cases.
> 
> If I'm not mistaken the initramfs topic is the only outstanding case
> where what goes in the SoC file vs board files is still open and we
> should continue to try to find the best solution.

Again, there's been a lot of internal discussion and as Ryan mentioned 
earlier, we do believe it is very easy to disable initramfs by several 
different methods and hence still falls into a "sane default" bucket.

As an example, to extend what Andrew said, meta-beagle as a vendor layer 
already had to deal with several such instances, showcasing how easy it is 
to override meta-ti defaults, when you disagree with them:

https://git.yoctoproject.org/meta-ti/commit/?id=b07a909654ac542353a7108f7a82bd5e1e2d4a82
https://git.yoctoproject.org/meta-ti/commit/?id=92c2198288fb19ce6f92084687b42f7d0af2adc7

-- 
Denys

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Francesco Dolcini]

On Wed, Apr 15, 2026 at 05:10:59PM -0400, Denys Dmytriyenko wrote:
> On Wed, Apr 15, 2026 at 09:43:31AM -0500, Andrew Davis via lists.yoctoproject.org wrote:
> > On 4/15/26 6:58 AM, Francesco Dolcini wrote:
> > >On Wed, Apr 15, 2026 at 01:41:04PM +0200, Franz Schnyder wrote:
> > >>From: Franz Schnyder <franz.schnyder@toradex.com>
> > >>
> > >>The `ti-eth-fw-j784s4` firmware is added in the generic J784s4 SoC
> > >>include, which is therefore used for all the J784s4-based machines.
> > >>That firmware seems to be developed specifically for the EVM, as it
> > >>takes control of pins used for the Ethernet board setup on the EVM. On
> > >>non-EVM boards, like the Aquila-AM69, those signals are used for other
> > >>functions, so enabling the firmware in the SoC include is too broad
> > >>and breaks functionality.
> > >>
> > >>Move the machine-essential recommend from the SoC include
> > >>to the EVM configuration.
> > >>
> > >>Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> > >
> > >This seems to be the 3rd time, in a relatively short time, in which
> > >we are affected by your decision to put into the SoC file, configuration
> > >that are not about the SOC
> > >
> > >  1 - the initramfs topic [https://lore.kernel.org/yocto-meta-ti/78ec394aae8a141ceb87a6b67f109665e7c96122.camel@gmail.com/]
> > >  2 - the console uart [https://lore.kernel.org/yocto-meta-ti/4e08fa3658b1e54add6d5476c7234e86dbcbb60c.camel@gmail.com/]
> > 
> > I thought we solved this one by making the console selection more easily
> > updated in the board files. If we want to go one step further and remove
> > the defaults from the SoC level and always select the board specific UART
> > in each board config I wouldn't oppose that either.
> 
> I was going to reply to the end of the thread, but this entire section of the 
> discussion was completely removed, hence I will do it here.
> 
> We've discussed this quite a lot internally and we ended up going with what 
> Andrew is saying here.
> 
> There's this concept of "sane defaults" that covers most of the cases and it 
> makes sense to set them as such. We have tens of platforms using this default 
> UART configuration and it makes perfect sense to set it once, instead of 
> copying the same over and over again - it is a maintenance pitfall. But we 
> also make sure to allow very easy and effortless overriding of this default, 
> if, for some reason, a specific board implementation doesn't follow this 
> default.
> 
> There are lots and lots of similar examples when an upstream layer, including 
> OE-Core, sets a sane default that may not match your configuration, but as 
> long as it allows easy override downstream, it's not the end of the world.
> 
> 
> > >  3 - this firmware
> > >
> > 
> > This firmware was a miss on our part, we were not aware that it was
> > not generic for all boards using this SoC but instead does some EVM
> > specific pinmuxing. I've looked into the FW source and can see where
> > that happens, I'll work to see how we can fix that. In the mean time
> > I agree then we should move this firmware to the board level (as the
> > patch does).
> 
> Here I agree with Andrew - it was an oversight and if it does per-board 
> pinmuxing, then it belongs in a board config. That said, please address my 
> comment for the patch before merging.
> 
> 
> > >Can I ask TI once more to rethink this considering that meta-ti is used
> > >by users of your SoC, but not of your EVK/SK ?
> > >
> > 
> > We do think a lot about external users of meta-ti, we even made a whole
> > split out reference layer (meta-beagle) that we treat like a normal vendor
> > layer so that we can more easily identify when we are making bad assumptions
> > that only apply to our EVM/SK boards. Yes we do still sometimes get it wrong,
> > and so we are very happy that you are providing the feedback that you have
> > and helping point out those cases.
> > 
> > If I'm not mistaken the initramfs topic is the only outstanding case
> > where what goes in the SoC file vs board files is still open and we
> > should continue to try to find the best solution.
> 
> Again, there's been a lot of internal discussion and as Ryan mentioned 
> earlier, we do believe it is very easy to disable initramfs by several 
> different methods and hence still falls into a "sane default" bucket.
> 
> As an example, to extend what Andrew said, meta-beagle as a vendor layer 
> already had to deal with several such instances, showcasing how easy it is 
> to override meta-ti defaults, when you disagree with them:
> 
> https://git.yoctoproject.org/meta-ti/commit/?id=b07a909654ac542353a7108f7a82bd5e1e2d4a82
> https://git.yoctoproject.org/meta-ti/commit/?id=92c2198288fb19ce6f92084687b42f7d0af2adc7

Denys, I understand your need to avoid duplication, I understand and I
agree with it, and I just disagree on your solution and I think
that is just wrong from an architecture point of view.

Mixing the concept that is something is shared between multiple boards
to the fact that is a default at the SoC level is plain wrong.

There is no such thing as a default console uart in the TI SoC reference
manual.

And the concept of pushing the initramfs into something that depends on
the HW is event worst, this is purely a SW decision. Our machine are
used in setup with/without initramfs, and forcing it at the SoC
level is technically wrong.

With that said, you made very clear what is your decision, I can just be
as clear and state that this decision is making the life of us, a TI
customer, way more painful than it should be.

And we'll deal with it, no need to explain us how to work with OE, we
are aware of it and we can work-around it in our layers.

Francesco

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[PRC Automation]

meta-ti / na / 20260415114107.1643556-1-fra.schnyder

PRC Results: PASS

=========================================================
  check-yocto-patches: PASS
=========================================================
Patches
----------------------------------------
WARN - [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf
    WARN: Commit message should not include directory path to recipe: conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf.
              machine
              conf (COMMIT-MESSAGE-3)
        patch
    
    For details on the above errors/warnings visit: https://lists.yoctoproject.org/g/meta-ti/wiki/40887



=========================================================
  apply-yocto-patch: PASS
=========================================================
master
=====================
Summary:
- Patch Series: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf
- Submitter: From: Franz Schnyder <fra.schnyder@gmail.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
- Date: Date: Wed, 15 Apr 2026 13:41:04 +0200
- Num Patches: 1
- Mailing List (public inbox) Commit SHA: fa4660c3c90128f11e8092e18014ce11ad8fb0d3

Applied to:
- Repository: lcpd-prc-meta-ti
- Base Branch: master-wip
- Commit Author: Ryan Eatmon <reatmon@ti.com>
- Commit Subject: conf: Add falcon support natively
- Commit SHA: 184758af4e6c34169d229c75fe94e8886ac3d7e5

Patches
----------------------------------------
All patches applied



=========================================================
  check-yocto-repo: PASS
=========================================================
master
=====================
PASS



=========================================================
  yocto-check-layers: PASS
=========================================================
master - PASS
=====================
All checks passed

Re: [meta-ti][master][PATCH v1] conf: machine: j784s4: Move ti-eth-fw-j784s4 to EVM conf

[Denys Dmytriyenko]

On Wed, Apr 15, 2026 at 01:41:04PM +0200, Franz Schnyder via lists.yoctoproject.org wrote:
> From: Franz Schnyder <franz.schnyder@toradex.com>
> 
> The `ti-eth-fw-j784s4` firmware is added in the generic J784s4 SoC
> include, which is therefore used for all the J784s4-based machines.
> That firmware seems to be developed specifically for the EVM, as it
> takes control of pins used for the Ethernet board setup on the EVM. On
> non-EVM boards, like the Aquila-AM69, those signals are used for other
> functions, so enabling the firmware in the SoC include is too broad
> and breaks functionality.
> 
> Move the machine-essential recommend from the SoC include
> to the EVM configuration.
> 
> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> ---
>  meta-ti-bsp/conf/machine/include/j784s4.inc | 2 +-
>  meta-ti-bsp/conf/machine/j784s4-evm.conf    | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta-ti-bsp/conf/machine/include/j784s4.inc b/meta-ti-bsp/conf/machine/include/j784s4.inc
> index 4dc3a71b..e0ce81b5 100644
> --- a/meta-ti-bsp/conf/machine/include/j784s4.inc
> +++ b/meta-ti-bsp/conf/machine/include/j784s4.inc
> @@ -12,7 +12,7 @@ TFA_BOARD = "j784s4"
>  
>  OPTEEMACHINE = "k3-j784s4"
>  
> -MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "cadence-mhdp-fw cnm-wave-fw ti-eth-fw-j784s4"
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "cadence-mhdp-fw cnm-wave-fw"
>  
>  TI_CORE_INITRAMFS_KERNEL_MODULES = "kernel-module-cdns-pltfrm kernel-module-ti-j721e-ufs"
>  TI_CORE_INITRAMFS_KERNEL_MODULES:bsp-ti-6_6 = ""
> diff --git a/meta-ti-bsp/conf/machine/j784s4-evm.conf b/meta-ti-bsp/conf/machine/j784s4-evm.conf
> index bf53b07c..f80e030f 100644
> --- a/meta-ti-bsp/conf/machine/j784s4-evm.conf
> +++ b/meta-ti-bsp/conf/machine/j784s4-evm.conf
> @@ -27,3 +27,5 @@ KERNEL_DEVICETREE = " \
>  "
>  
>  UBOOT_MACHINE = "j784s4_evm_a72_defconfig"
> +
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS:append = " ti-eth-fw-j784s4"

Can this be done with += instead of :append?