[meta-ti,scarthgap] HACK: conf: machine: am64x: Use new sdimage efti wks template

Currently am64x boards are failing SD card boot since standard
boot is the current boot method for the boards. With standard
boot, the grub shell is invoked and the grub.cfg used to pass
kernel parameters to Linux. Normally we would like to use grub
class to modify the kernel parameters passed to Linux but
since this is not currently working with SERIAL_CONSOLES nor
GRUB_OPTS, lets make a template that includes our own custom
console= and let am64x conf use this.

Signed-off-by: Judith Mendez <jm@ti.com>
---
 meta-ti-bsp/conf/machine/include/am64xx.inc  | 2 ++
 meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in | 8 ++++++++
 2 files changed, 10 insertions(+)
 create mode 100644 meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in

On 2/11/25 5:11 PM, Mendez, Judith via lists.yoctoproject.org wrote:
> Currently am64x boards are failing SD card boot since standard
> boot is the current boot method for the boards. With standard
> boot, the grub shell is invoked and the grub.cfg used to pass
> kernel parameters to Linux. Normally we would like to use grub
> class to modify the kernel parameters passed to Linux but
> since this is not currently working with SERIAL_CONSOLES nor
> GRUB_OPTS, lets make a template that includes our own custom

Why do SERIAL_CONSOLES nor GRUB_OPTS work here? Should explain
that in this message.

Looks like there is a comment that this needs fixed[0]. Since it
affects you now, might be good to go fix this upstream.

For now, this seems like a GRUB issue. Why do we use GRUB again,
isn't one bootloader enough?.. uboot-extlinux-config.bbclass
doesn't seem to have this issue, and the resulting extlinux.conf
can be used directly by U-Boot (or used by GRUB if we really want
to have a middle layer bootloader that only ends up breaking FIT,
DT overlays, rproc loading, security, etc..)

<rant>
GRUB makes no sense on embedded, and it never did as we don't
have an x86 legacy BIOS, the only reason anyone still uses GRUB.
systemd-boot and efistub are the future for EFI capable systems
like ours. Simple, better security, and already available in
Yocto, let's switch already..
</rant>

Andrew

[0] https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/grub-efi-cfg.bbclass#n22

> console= and let am64x conf use this.
> 
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
>   meta-ti-bsp/conf/machine/include/am64xx.inc  | 2 ++
>   meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in | 8 ++++++++
>   2 files changed, 10 insertions(+)
>   create mode 100644 meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
> 
> diff --git a/meta-ti-bsp/conf/machine/include/am64xx.inc b/meta-ti-bsp/conf/machine/include/am64xx.inc
> index 49e996c8..be65aa6e 100644
> --- a/meta-ti-bsp/conf/machine/include/am64xx.inc
> +++ b/meta-ti-bsp/conf/machine/include/am64xx.inc
> @@ -34,3 +34,5 @@ TFA_BOARD = "lite"
>   OPTEEMACHINE = "k3-am64x"
>   
>   MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "prueth-fw pruhsr-fw prusw-fw"
> +
> +WKS_FILE = "${@bb.utils.contains("MACHINE_FEATURES", "efi", "sdimage-2part-efi-csl.wks.in", "sdimage-2part.wks", d)}"
> diff --git a/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
> new file mode 100644
> index 00000000..6dc69a17
> --- /dev/null
> +++ b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
> @@ -0,0 +1,8 @@
> +# short-description: Create SD card image with 2 partitions and EFI support
> +# long-description: Creates a partitioned SD card image for TI platforms that
> +# supports EFI.  Boot files are located in the first vfat partition with extra
> +# reserved space.  We cannot use a GPT here.
> +
> +bootloader --timeout=5 --append="rootfstype=ext4 console=ttyS2,115200n8"
> +part --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --fstype=vfat --label boot --active --align 1024 --use-uuid --fixed-size 128M
> +part / --source rootfs --fstype=ext4 --label root --align 1024 --use-uuid
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#18300): https://lists.yoctoproject.org/g/meta-ti/message/18300
> Mute This Topic: https://lists.yoctoproject.org/mt/111133257/3619733
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [afd@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Hi Andrew,

On 2/12/25 1:42 PM, Andrew Davis wrote:
> On 2/11/25 5:11 PM, Mendez, Judith via lists.yoctoproject.org wrote:
>> Currently am64x boards are failing SD card boot since standard
>> boot is the current boot method for the boards. With standard
>> boot, the grub shell is invoked and the grub.cfg used to pass
>> kernel parameters to Linux. Normally we would like to use grub
>> class to modify the kernel parameters passed to Linux but
>> since this is not currently working with SERIAL_CONSOLES nor
>> GRUB_OPTS, lets make a template that includes our own custom
> 
> Why do SERIAL_CONSOLES nor GRUB_OPTS work here? Should explain
> that in this message.

According to the grub class, I believe we are supposed to be able
to modify GRUB_OPTS to append variables, for grub config. It was not
working for me.

SERIAL_CONSOLES is a bit of a misery to me. Although I did not spend
to much time on this, I tested both variables to see if the default
console would change but it did not work. So I am just pointing that
out as well.

> 
> Looks like there is a comment that this needs fixed[0]. Since it
> affects you now, might be good to go fix this upstream.

Yes, that is a good idea. Ill keep it in mind, thanks.

> 
> For now, this seems like a GRUB issue. Why do we use GRUB again,
> isn't one bootloader enough?.. uboot-extlinux-config.bbclass
> doesn't seem to have this issue, and the resulting extlinux.conf
> can be used directly by U-Boot (or used by GRUB if we really want
> to have a middle layer bootloader that only ends up breaking FIT,
> DT overlays, rproc loading, security, etc..)
> 
> <rant>
> GRUB makes no sense on embedded, and it never did as we don't
> have an x86 legacy BIOS, the only reason anyone still uses GRUB.
> systemd-boot and efistub are the future for EFI capable systems
> like ours. Simple, better security, and already available in
> Yocto, let's switch already..
> </rant>

I do not have a strong opinion on what bootloader to use. imo, I think
we should just select one unanimously and be done with it.

Probably this will never happen.

Sign.. in any case, we have a grub config issue in our hands, so was
fixing it as quick as possible to unblock CICD.

~ Judith


> 
> Andrew
> 
> [0] 
> https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/grub-efi-cfg.bbclass#n22
> 
>> console= and let am64x conf use this.
>>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>>   meta-ti-bsp/conf/machine/include/am64xx.inc  | 2 ++
>>   meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in | 8 ++++++++
>>   2 files changed, 10 insertions(+)
>>   create mode 100644 meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
>>
>> diff --git a/meta-ti-bsp/conf/machine/include/am64xx.inc 
>> b/meta-ti-bsp/conf/machine/include/am64xx.inc
>> index 49e996c8..be65aa6e 100644
>> --- a/meta-ti-bsp/conf/machine/include/am64xx.inc
>> +++ b/meta-ti-bsp/conf/machine/include/am64xx.inc
>> @@ -34,3 +34,5 @@ TFA_BOARD = "lite"
>>   OPTEEMACHINE = "k3-am64x"
>>   MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "prueth-fw pruhsr-fw prusw-fw"
>> +
>> +WKS_FILE = "${@bb.utils.contains("MACHINE_FEATURES", "efi", 
>> "sdimage-2part-efi-csl.wks.in", "sdimage-2part.wks", d)}"
>> diff --git a/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in 
>> b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
>> new file mode 100644
>> index 00000000..6dc69a17
>> --- /dev/null
>> +++ b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
>> @@ -0,0 +1,8 @@
>> +# short-description: Create SD card image with 2 partitions and EFI 
>> support
>> +# long-description: Creates a partitioned SD card image for TI 
>> platforms that
>> +# supports EFI.  Boot files are located in the first vfat partition 
>> with extra
>> +# reserved space.  We cannot use a GPT here.
>> +
>> +bootloader --timeout=5 --append="rootfstype=ext4 console=ttyS2,115200n8"
>> +part --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" 
>> --fstype=vfat --label boot --active --align 1024 --use-uuid 
>> --fixed-size 128M
>> +part / --source rootfs --fstype=ext4 --label root --align 1024 
>> --use-uuid
>>
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#18300): 
>> https://lists.yoctoproject.org/g/meta-ti/message/18300
>> Mute This Topic: https://lists.yoctoproject.org/mt/111133257/3619733
>> Group Owner: meta-ti+owner@lists.yoctoproject.org
>> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [afd@ti.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

On Wed, Feb 12, 2025 at 01:42:08PM -0600, Andrew Davis via lists.yoctoproject.org wrote:
> On 2/11/25 5:11 PM, Mendez, Judith via lists.yoctoproject.org wrote:
> >Currently am64x boards are failing SD card boot since standard
> >boot is the current boot method for the boards. With standard
> >boot, the grub shell is invoked and the grub.cfg used to pass
> >kernel parameters to Linux. Normally we would like to use grub
> >class to modify the kernel parameters passed to Linux but
> >since this is not currently working with SERIAL_CONSOLES nor
> >GRUB_OPTS, lets make a template that includes our own custom
> 
> Why do SERIAL_CONSOLES nor GRUB_OPTS work here? Should explain
> that in this message.
> 
> Looks like there is a comment that this needs fixed[0]. Since it
> affects you now, might be good to go fix this upstream.
> 
> For now, this seems like a GRUB issue.

Andrew,

> Why do we use GRUB again,

Might want to ask Nishanth for specific details, but this was part of 
the "generic distro boot" support and EFI boot on K3:

https://git.yoctoproject.org/meta-ti/commit/?id=993d80764de4d7c2b181d4262d18e950f86c3467
https://git.yoctoproject.org/meta-ti/commit/?id=f2d9882e175db1832a90378a01f72d3c3b3f2264


> isn't one bootloader enough?.. uboot-extlinux-config.bbclass
> doesn't seem to have this issue, and the resulting extlinux.conf
> can be used directly by U-Boot (or used by GRUB if we really want
> to have a middle layer bootloader that only ends up breaking FIT,
> DT overlays, rproc loading, security, etc..)
> 
> <rant>
> GRUB makes no sense on embedded, and it never did as we don't
> have an x86 legacy BIOS, the only reason anyone still uses GRUB.
> systemd-boot and efistub are the future for EFI capable systems
> like ours. Simple, better security, and already available in
> Yocto, let's switch already..
> </rant>
> 
> Andrew
> 
> [0] https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/grub-efi-cfg.bbclass#n22
> 
> >console= and let am64x conf use this.
> >
> >Signed-off-by: Judith Mendez <jm@ti.com>
> >---
> >  meta-ti-bsp/conf/machine/include/am64xx.inc  | 2 ++
> >  meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in | 8 ++++++++
> >  2 files changed, 10 insertions(+)
> >  create mode 100644 meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
> >
> >diff --git a/meta-ti-bsp/conf/machine/include/am64xx.inc b/meta-ti-bsp/conf/machine/include/am64xx.inc
> >index 49e996c8..be65aa6e 100644
> >--- a/meta-ti-bsp/conf/machine/include/am64xx.inc
> >+++ b/meta-ti-bsp/conf/machine/include/am64xx.inc
> >@@ -34,3 +34,5 @@ TFA_BOARD = "lite"
> >  OPTEEMACHINE = "k3-am64x"
> >  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "prueth-fw pruhsr-fw prusw-fw"
> >+
> >+WKS_FILE = "${@bb.utils.contains("MACHINE_FEATURES", "efi", "sdimage-2part-efi-csl.wks.in", "sdimage-2part.wks", d)}"
> >diff --git a/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
> >new file mode 100644
> >index 00000000..6dc69a17
> >--- /dev/null
> >+++ b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
> >@@ -0,0 +1,8 @@
> >+# short-description: Create SD card image with 2 partitions and EFI support
> >+# long-description: Creates a partitioned SD card image for TI platforms that
> >+# supports EFI.  Boot files are located in the first vfat partition with extra
> >+# reserved space.  We cannot use a GPT here.
> >+
> >+bootloader --timeout=5 --append="rootfstype=ext4 console=ttyS2,115200n8"
> >+part --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --fstype=vfat --label boot --active --align 1024 --use-uuid --fixed-size 128M
> >+part / --source rootfs --fstype=ext4 --label root --align 1024 --use-uuid

On 2/14/25 5:33 PM, Denys Dmytriyenko wrote:
> On Wed, Feb 12, 2025 at 01:42:08PM -0600, Andrew Davis via lists.yoctoproject.org wrote:
>> On 2/11/25 5:11 PM, Mendez, Judith via lists.yoctoproject.org wrote:
>>> Currently am64x boards are failing SD card boot since standard
>>> boot is the current boot method for the boards. With standard
>>> boot, the grub shell is invoked and the grub.cfg used to pass
>>> kernel parameters to Linux. Normally we would like to use grub
>>> class to modify the kernel parameters passed to Linux but
>>> since this is not currently working with SERIAL_CONSOLES nor
>>> GRUB_OPTS, lets make a template that includes our own custom
>>
>> Why do SERIAL_CONSOLES nor GRUB_OPTS work here? Should explain
>> that in this message.
>>
>> Looks like there is a comment that this needs fixed[0]. Since it
>> affects you now, might be good to go fix this upstream.
>>
>> For now, this seems like a GRUB issue.
> 
> Andrew,
> 
>> Why do we use GRUB again,
> 
> Might want to ask Nishanth for specific details, but this was part of
> the "generic distro boot" support and EFI boot on K3:
> 
> https://git.yoctoproject.org/meta-ti/commit/?id=993d80764de4d7c2b181d4262d18e950f86c3467
> https://git.yoctoproject.org/meta-ti/commit/?id=f2d9882e175db1832a90378a01f72d3c3b3f2264
> 
> 

I'm all for generic distro boot, things like extlinux.conf being provided
by the distro, and not baked into u-boot scripts, is the way to go.

But going distro/EFI doesn't mean going GRUB now that we have much simpler
options like systemd-boot and/or efistub, I'd like to look into those.
Or rather make sure there are no objections to dropping GRUB. And if
not, then actually doing the switch might be a good project for +Bryan,
who has already been working to streamline our boot strategy.

Andrew

>> isn't one bootloader enough?.. uboot-extlinux-config.bbclass
>> doesn't seem to have this issue, and the resulting extlinux.conf
>> can be used directly by U-Boot (or used by GRUB if we really want
>> to have a middle layer bootloader that only ends up breaking FIT,
>> DT overlays, rproc loading, security, etc..)
>>
>> <rant>
>> GRUB makes no sense on embedded, and it never did as we don't
>> have an x86 legacy BIOS, the only reason anyone still uses GRUB.
>> systemd-boot and efistub are the future for EFI capable systems
>> like ours. Simple, better security, and already available in
>> Yocto, let's switch already..
>> </rant>
>>
>> Andrew
>>
>> [0] https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/grub-efi-cfg.bbclass#n22
>>
>>> console= and let am64x conf use this.
>>>
>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>> ---
>>>   meta-ti-bsp/conf/machine/include/am64xx.inc  | 2 ++
>>>   meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in | 8 ++++++++
>>>   2 files changed, 10 insertions(+)
>>>   create mode 100644 meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
>>>
>>> diff --git a/meta-ti-bsp/conf/machine/include/am64xx.inc b/meta-ti-bsp/conf/machine/include/am64xx.inc
>>> index 49e996c8..be65aa6e 100644
>>> --- a/meta-ti-bsp/conf/machine/include/am64xx.inc
>>> +++ b/meta-ti-bsp/conf/machine/include/am64xx.inc
>>> @@ -34,3 +34,5 @@ TFA_BOARD = "lite"
>>>   OPTEEMACHINE = "k3-am64x"
>>>   MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "prueth-fw pruhsr-fw prusw-fw"
>>> +
>>> +WKS_FILE = "${@bb.utils.contains("MACHINE_FEATURES", "efi", "sdimage-2part-efi-csl.wks.in", "sdimage-2part.wks", d)}"
>>> diff --git a/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
>>> new file mode 100644
>>> index 00000000..6dc69a17
>>> --- /dev/null
>>> +++ b/meta-ti-bsp/wic/sdimage-2part-efi-csl.wks.in
>>> @@ -0,0 +1,8 @@
>>> +# short-description: Create SD card image with 2 partitions and EFI support
>>> +# long-description: Creates a partitioned SD card image for TI platforms that
>>> +# supports EFI.  Boot files are located in the first vfat partition with extra
>>> +# reserved space.  We cannot use a GPT here.
>>> +
>>> +bootloader --timeout=5 --append="rootfstype=ext4 console=ttyS2,115200n8"
>>> +part --source bootimg-efi --sourceparams="loader=${EFI_PROVIDER}" --fstype=vfat --label boot --active --align 1024 --use-uuid --fixed-size 128M
>>> +part / --source rootfs --fstype=ext4 --label root --align 1024 --use-uuid