On Mon Feb 23, 2026 at 4:43 PM CST, Andrew Davis wrote: > On 2/23/26 3:54 PM, Ryan Eatmon wrote: >> >> >> On 2/23/2026 3:51 PM, Andrew Davis wrote: >>> On 2/23/26 2:22 PM, Randolph Sapp via lists.yoctoproject.org wrote: >>>> From: Randolph Sapp <[email protected]> >>>> >>>> Add a TI configuration for the BeagleY-AI development board. >>>> >>>> Signed-off-by: Randolph Sapp <[email protected]> >>>> --- >>>> meta-ti-bsp/conf/machine/beagley-ai-ti-k3r5.conf | 7 +++++++ >>>> meta-ti-bsp/conf/machine/beagley-ai-ti.conf | 16 ++++++++++++++++ >>>> 2 files changed, 23 insertions(+) >>>> create mode 100644 meta-ti-bsp/conf/machine/beagley-ai-ti-k3r5.conf >>>> create mode 100644 meta-ti-bsp/conf/machine/beagley-ai-ti.conf >>>> >>>> diff --git a/meta-ti-bsp/conf/machine/beagley-ai-ti-k3r5.conf >>>> b/meta-ti-bsp/conf/machine/beagley-ai-ti-k3r5.conf >>>> new file mode 100644 >>>> index 00000000..88d0888b >>>> --- /dev/null >>>> +++ b/meta-ti-bsp/conf/machine/beagley-ai-ti-k3r5.conf >>>> @@ -0,0 +1,7 @@ >>>> +#@TYPE: Machine >>>> +#@NAME: BeagleY-AI (R5F) >>>> +#@DESCRIPTION: Machine configuration for the BeagleY-AI (R5F core) >>>> + >>>> +require conf/machine/include/k3r5.inc >>>> + >>>> +UBOOT_MACHINE = "am67a_beagley_ai_r5_defconfig" >>>> diff --git a/meta-ti-bsp/conf/machine/beagley-ai-ti.conf >>>> b/meta-ti-bsp/conf/machine/beagley-ai-ti.conf >>>> new file mode 100644 >>>> index 00000000..088cbd62 >>>> --- /dev/null >>>> +++ b/meta-ti-bsp/conf/machine/beagley-ai-ti.conf >>>> @@ -0,0 +1,16 @@ >>>> +#@TYPE: Machine >>>> +#@NAME: BeagleY-AI (A53) >>>> +#@DESCRIPTION: Machine configuration for the BeagleY-AI (A53) >>>> + >>>> +require conf/machine/include/j722s.inc >>>> + >>>> +KERNEL_DEVICETREE_PREFIX = " \ >>>> + ti/k3-am67a \ >>>> + ti/k3-j722s \ >>>> +" >>>> + >>>> +KERNEL_DEVICETREE = " \ >>>> + ti/k3-am67a-beagley-ai.dtb \ >>>> +" >>>> + >>>> +UBOOT_MACHINE = "am67a_beagley_ai_a53_defconfig" >>> >>> This defconfig doesn't work if you select an older BSP. >>> >>> Thinking on this, the only difference we should have between this machine >>> config and the one already in meta-beagle is the default selected BSP >>> (bsp-ti-6_12 vs bb_org-6_12). Why can't we just have the one config and >>> select the BSP with TI_PREFERRED_BSP? We could do that externally >>> from the build env, or with a branding. >>> >>> The issue with this patch is we would now have two configs for the same >>> hardware, and there is no TI produced BeagleY, so having the machine >>> config for it in this layer just seems wrong. I have the same complaint >>> for beagleplay-ti and beaglebadge-ti, we should drop those too and fix >>> them in the same way. >> >> The difference between the two platforms is that one is supported by TI and >> one is not. We do not answer questions or support the meta-beagle boards. >> Those are supported by the community (aka Denys). But the beagleplay-ti >> board using the TI kernel and TI uboot is supported. We will answer >> questions about them. >> > > And selecting TI kernel and TI uboot is done by simply setting > TI_PREFERRED_BSP = "ti-6_12", why do we need to clone files for this? > >> It was a decision from Sitara management to do this. >> > > To do what? Support BeagleY, sure that is fine, we also support Wayland > for instance, but we don't go and clone it and rebrand it Wayland-TI™. > > We support community projects by working in those communities, in this > case the community project is "meta-beagle". So let's add support for > our TI BSP to that project, not fork bits of it into our meta-ti project. > > Anyway to close the loop on the two threads, > >> I don't necessarily hate that idea. Guessing this is hinging on Andrew's >> idea of >> overriding the BSP provider variable directly for our internal testing? > > We could at very least start with this "beagley-ai-ti.conf" do nothing but > the following two lines: > > require meta-beagle/conf/machine/beagley-ai.conf > TI_PREFERRED_BSP = "ti-6_18" > > This would remove any duplication at least, but does introduce a reverse > dependency from meta-ti towards meta-beagle. So the first option of a > BSP provider override as needed is still my strong preference. > > Andrew >
I'd almost prefer we move all the beagle-ti configs back into meta-beagle and do that override there. Makes the layer dependency tree more reasonable and provides logical isolation from meta-ti and meta-beagle devices. I'll draft that. Doesn't seem so awful. >> That's why we name them differently to draw a distinction between the two.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19577): https://lists.yoctoproject.org/g/meta-ti/message/19577 Mute This Topic: https://lists.yoctoproject.org/mt/117964418/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
