diff mbox series

[dunfell] wic: move uboot/spls mountpoint to /boot/firmware

Message ID 20220721210152.28223-1-bb@ti.com
State Rejected
Delegated to: Ryan Eatmon
Headers show
Series [dunfell] wic: move uboot/spls mountpoint to /boot/firmware | expand

Commit Message

Bryan Brattlof July 21, 2022, 9:01 p.m. UTC
Currently out boards will auto-mount the sd-card's boot partition into
the /boot folder, effectively hiding the kernel image and dtb files that
are already there.

Move the boot partition mount point to /boot/firmware allowing access to
both the bootloader binares and kernel images.

Signed-off-by: Bryan Brattlof <bb@ti.com>
---
 wic/sdimage-2part.wks | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Denys Dmytriyenko July 21, 2022, 10:57 p.m. UTC | #1
I don't think this is a correct solution, or maybe I'm not understanding the 
problem. Can you please elaborate a bit more on the problem?


On Thu, Jul 21, 2022 at 04:01:52PM -0500, Bryan Brattlof wrote:
> Currently out boards will auto-mount the sd-card's boot partition into
> the /boot folder, effectively hiding the kernel image and dtb files that
> are already there.
> 
> Move the boot partition mount point to /boot/firmware allowing access to
> both the bootloader binares and kernel images.
> 
> Signed-off-by: Bryan Brattlof <bb@ti.com>
> ---
>  wic/sdimage-2part.wks | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/wic/sdimage-2part.wks b/wic/sdimage-2part.wks
> index 77d6f7b576aef..7567c4429a2eb 100644
> --- a/wic/sdimage-2part.wks
> +++ b/wic/sdimage-2part.wks
> @@ -2,5 +2,5 @@
>  # long-description: Creates a partitioned SD card image for TI platforms.
>  # Boot files are located in the first vfat partition with extra reserved space.
>  
> -part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 1024 --extra-space 100M --use-uuid
> +part /boot/firmware --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 1024 --extra-space 100M --use-uuid
>  part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root --align 1024 --use-uuid
> -- 
> 2.17.1
Bryan Brattlof July 22, 2022, 2:31 a.m. UTC | #2
Hi Denys!

+Tom Rini

On July 21, 2022 thus sayeth Denys Dmytriyenko:
> I don't think this is a correct solution, or maybe I'm not understanding the 
> problem. Can you please elaborate a bit more on the problem?
>

I'm fairly new to yocto so I'm sure I've found the entirely wrong way to 
get what I wanted :)

After boot it appears /etc/fstab is setup to mount our vfat boot 
partition to the /boot directory currently holding the Image and dtbs.  
I guess because uboot has already thrown the kernel and dtb into ddr at 
this point only Anand was able to notice this.

My change should mount the vfat partition to /boot/firmware so we can 
access to both our spls and kernel binaries in /boot.

I'm also not sure what folder name to use here. It seem like there may 
be a standard to this? Would /boot/uboot be more correct?

Thanks
~Bryan

> 
> On Thu, Jul 21, 2022 at 04:01:52PM -0500, Bryan Brattlof wrote:
> > Currently out boards will auto-mount the sd-card's boot partition into
> > the /boot folder, effectively hiding the kernel image and dtb files that
> > are already there.
> > 
> > Move the boot partition mount point to /boot/firmware allowing access to
> > both the bootloader binares and kernel images.
> > 
> > Signed-off-by: Bryan Brattlof <bb@ti.com>
> > ---
> >  wic/sdimage-2part.wks | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/wic/sdimage-2part.wks b/wic/sdimage-2part.wks
> > index 77d6f7b576aef..7567c4429a2eb 100644
> > --- a/wic/sdimage-2part.wks
> > +++ b/wic/sdimage-2part.wks
> > @@ -2,5 +2,5 @@
> >  # long-description: Creates a partitioned SD card image for TI platforms.
> >  # Boot files are located in the first vfat partition with extra reserved space.
> >  
> > -part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 1024 --extra-space 100M --use-uuid
> > +part /boot/firmware --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 1024 --extra-space 100M --use-uuid
> >  part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root --align 1024 --use-uuid
> > -- 2.17.1
Tom Rini July 22, 2022, 12:29 p.m. UTC | #3
On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
> Hi Denys!
> 
> +Tom Rini
> 
> On July 21, 2022 thus sayeth Denys Dmytriyenko:
> > I don't think this is a correct solution, or maybe I'm not understanding the 
> > problem. Can you please elaborate a bit more on the problem?
> >
> 
> I'm fairly new to yocto so I'm sure I've found the entirely wrong way to 
> get what I wanted :)
> 
> After boot it appears /etc/fstab is setup to mount our vfat boot 
> partition to the /boot directory currently holding the Image and dtbs.  
> I guess because uboot has already thrown the kernel and dtb into ddr at 
> this point only Anand was able to notice this.
> 
> My change should mount the vfat partition to /boot/firmware so we can 
> access to both our spls and kernel binaries in /boot.
> 
> I'm also not sure what folder name to use here. It seem like there may 
> be a standard to this? Would /boot/uboot be more correct?

So which SoCs are we talking about here?  For the 64bit parts, the
intention should be that the FAT partition on p1 be functional as the
ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
how that's being treated in upstream OE around the notion of making an
image that's what a UEFI system expects.
Bryan Brattlof July 25, 2022, 11:29 p.m. UTC | #4
On July 22, 2022 thus sayeth Tom Rini:
> On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
> > On July 21, 2022 thus sayeth Denys Dmytriyenko:
> > > I don't think this is a correct solution, or maybe I'm not understanding the 
> > > problem. Can you please elaborate a bit more on the problem?
> > >
> > 
> > I'm fairly new to yocto so I'm sure I've found the entirely wrong way to 
> > get what I wanted :)
> > 
> > After boot it appears /etc/fstab is setup to mount our vfat boot 
> > partition to the /boot directory currently holding the Image and dtbs.  
> > I guess because uboot has already thrown the kernel and dtb into ddr at 
> > this point only Anand was able to notice this.
> > 
> > My change should mount the vfat partition to /boot/firmware so we can 
> > access to both our spls and kernel binaries in /boot.
> > 
> > I'm also not sure what folder name to use here. It seem like there may 
> > be a standard to this? Would /boot/uboot be more correct?
> 
> So which SoCs are we talking about here?  For the 64bit parts, the
> intention should be that the FAT partition on p1 be functional as the
> ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
> how that's being treated in upstream OE around the notion of making an
> image that's what a UEFI system expects.

Ideally this should be for all TI's K3 devices. I'm unfamiliar with the 
UEFI format and don't know if we currently follow it, however I like the 
idea of /boot/efi from what I googled.  I also found raspian is using 
/boot/firmware. Could this be less of a standard than I think?

~Bryan
Tom Rini July 28, 2022, 11:31 a.m. UTC | #5
On Mon, Jul 25, 2022 at 06:29:04PM -0500, Bryan Brattlof wrote:
> On July 22, 2022 thus sayeth Tom Rini:
> > On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
> > > On July 21, 2022 thus sayeth Denys Dmytriyenko:
> > > > I don't think this is a correct solution, or maybe I'm not understanding the 
> > > > problem. Can you please elaborate a bit more on the problem?
> > > >
> > > 
> > > I'm fairly new to yocto so I'm sure I've found the entirely wrong way to 
> > > get what I wanted :)
> > > 
> > > After boot it appears /etc/fstab is setup to mount our vfat boot 
> > > partition to the /boot directory currently holding the Image and dtbs.  
> > > I guess because uboot has already thrown the kernel and dtb into ddr at 
> > > this point only Anand was able to notice this.
> > > 
> > > My change should mount the vfat partition to /boot/firmware so we can 
> > > access to both our spls and kernel binaries in /boot.
> > > 
> > > I'm also not sure what folder name to use here. It seem like there may 
> > > be a standard to this? Would /boot/uboot be more correct?
> > 
> > So which SoCs are we talking about here?  For the 64bit parts, the
> > intention should be that the FAT partition on p1 be functional as the
> > ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
> > how that's being treated in upstream OE around the notion of making an
> > image that's what a UEFI system expects.
> 
> Ideally this should be for all TI's K3 devices. I'm unfamiliar with the 
> UEFI format and don't know if we currently follow it, however I like the 
> idea of /boot/efi from what I googled.  I also found raspian is using 
> /boot/firmware. Could this be less of a standard than I think?

Keep in mind this is a generic OE on 64bit Arm problem and not a TI
specific problem.  Where to mount the ESP should have a consistent
default.  And it should look like it does on an off the shelf distro.
Andrew Davis Sept. 27, 2023, 7 p.m. UTC | #6
On 7/28/22 6:31 AM, Tom Rini wrote:
> On Mon, Jul 25, 2022 at 06:29:04PM -0500, Bryan Brattlof wrote:
>> On July 22, 2022 thus sayeth Tom Rini:
>>> On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
>>>> On July 21, 2022 thus sayeth Denys Dmytriyenko:
>>>>> I don't think this is a correct solution, or maybe I'm not understanding the
>>>>> problem. Can you please elaborate a bit more on the problem?
>>>>>
>>>>
>>>> I'm fairly new to yocto so I'm sure I've found the entirely wrong way to
>>>> get what I wanted :)
>>>>
>>>> After boot it appears /etc/fstab is setup to mount our vfat boot
>>>> partition to the /boot directory currently holding the Image and dtbs.
>>>> I guess because uboot has already thrown the kernel and dtb into ddr at
>>>> this point only Anand was able to notice this.
>>>>
>>>> My change should mount the vfat partition to /boot/firmware so we can
>>>> access to both our spls and kernel binaries in /boot.
>>>>
>>>> I'm also not sure what folder name to use here. It seem like there may
>>>> be a standard to this? Would /boot/uboot be more correct?
>>>
>>> So which SoCs are we talking about here?  For the 64bit parts, the
>>> intention should be that the FAT partition on p1 be functional as the
>>> ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
>>> how that's being treated in upstream OE around the notion of making an
>>> image that's what a UEFI system expects.
>>
>> Ideally this should be for all TI's K3 devices. I'm unfamiliar with the
>> UEFI format and don't know if we currently follow it, however I like the
>> idea of /boot/efi from what I googled.  I also found raspian is using
>> /boot/firmware. Could this be less of a standard than I think?
> 
> Keep in mind this is a generic OE on 64bit Arm problem and not a TI
> specific problem.  Where to mount the ESP should have a consistent
> default.  And it should look like it does on an off the shelf distro.
> 

While not an exact ESP partition, we are working on making our boot
partition as close as we can given ROM constraints.

I'm running into the problem now of updating kernel on a live system,
would fail as we have mounted our boot partition over the rootfs boot/
directory, so new images are not installed to the right spot/partition.

Let's go with /boot/efi if that works for everyone.

Bryan, could you re-send this with that change and the same for
sdimage-2part-efi.wks.in?

Andrew

> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#14912): https://lists.yoctoproject.org/g/meta-ti/message/14912
> Mute This Topic: https://lists.yoctoproject.org/mt/92535778/3619733
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [afd@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Tom Rini Sept. 27, 2023, 7:02 p.m. UTC | #7
On Wed, Sep 27, 2023 at 02:00:26PM -0500, Andrew Davis wrote:
> On 7/28/22 6:31 AM, Tom Rini wrote:
> > On Mon, Jul 25, 2022 at 06:29:04PM -0500, Bryan Brattlof wrote:
> > > On July 22, 2022 thus sayeth Tom Rini:
> > > > On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
> > > > > On July 21, 2022 thus sayeth Denys Dmytriyenko:
> > > > > > I don't think this is a correct solution, or maybe I'm not understanding the
> > > > > > problem. Can you please elaborate a bit more on the problem?
> > > > > > 
> > > > > 
> > > > > I'm fairly new to yocto so I'm sure I've found the entirely wrong way to
> > > > > get what I wanted :)
> > > > > 
> > > > > After boot it appears /etc/fstab is setup to mount our vfat boot
> > > > > partition to the /boot directory currently holding the Image and dtbs.
> > > > > I guess because uboot has already thrown the kernel and dtb into ddr at
> > > > > this point only Anand was able to notice this.
> > > > > 
> > > > > My change should mount the vfat partition to /boot/firmware so we can
> > > > > access to both our spls and kernel binaries in /boot.
> > > > > 
> > > > > I'm also not sure what folder name to use here. It seem like there may
> > > > > be a standard to this? Would /boot/uboot be more correct?
> > > > 
> > > > So which SoCs are we talking about here?  For the 64bit parts, the
> > > > intention should be that the FAT partition on p1 be functional as the
> > > > ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
> > > > how that's being treated in upstream OE around the notion of making an
> > > > image that's what a UEFI system expects.
> > > 
> > > Ideally this should be for all TI's K3 devices. I'm unfamiliar with the
> > > UEFI format and don't know if we currently follow it, however I like the
> > > idea of /boot/efi from what I googled.  I also found raspian is using
> > > /boot/firmware. Could this be less of a standard than I think?
> > 
> > Keep in mind this is a generic OE on 64bit Arm problem and not a TI
> > specific problem.  Where to mount the ESP should have a consistent
> > default.  And it should look like it does on an off the shelf distro.
> > 
> 
> While not an exact ESP partition, we are working on making our boot
> partition as close as we can given ROM constraints.
> 
> I'm running into the problem now of updating kernel on a live system,
> would fail as we have mounted our boot partition over the rootfs boot/
> directory, so new images are not installed to the right spot/partition.
> 
> Let's go with /boot/efi if that works for everyone.
> 
> Bryan, could you re-send this with that change and the same for
> sdimage-2part-efi.wks.in?

The only feedback I would provide here is to work with the ROM team to
fix whatever constraints prevent an "ESP" itself from being used as this
will hinder the long term viability of the processors being widely
supported.
Res Sapp Sept. 28, 2023, 5:44 a.m. UTC | #8
On 9/27/23 14:02, Tom Rini wrote:
> On Wed, Sep 27, 2023 at 02:00:26PM -0500, Andrew Davis wrote:
>> On 7/28/22 6:31 AM, Tom Rini wrote:
>>> On Mon, Jul 25, 2022 at 06:29:04PM -0500, Bryan Brattlof wrote:
>>>> On July 22, 2022 thus sayeth Tom Rini:
>>>>> On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
>>>>>> On July 21, 2022 thus sayeth Denys Dmytriyenko:
>>>>>>> I don't think this is a correct solution, or maybe I'm not understanding the
>>>>>>> problem. Can you please elaborate a bit more on the problem?
>>>>>>>
>>>>>>
>>>>>> I'm fairly new to yocto so I'm sure I've found the entirely wrong way to
>>>>>> get what I wanted :)
>>>>>>
>>>>>> After boot it appears /etc/fstab is setup to mount our vfat boot
>>>>>> partition to the /boot directory currently holding the Image and dtbs.
>>>>>> I guess because uboot has already thrown the kernel and dtb into ddr at
>>>>>> this point only Anand was able to notice this.
>>>>>>
>>>>>> My change should mount the vfat partition to /boot/firmware so we can
>>>>>> access to both our spls and kernel binaries in /boot.
>>>>>>
>>>>>> I'm also not sure what folder name to use here. It seem like there may
>>>>>> be a standard to this? Would /boot/uboot be more correct?
>>>>>
>>>>> So which SoCs are we talking about here?  For the 64bit parts, the
>>>>> intention should be that the FAT partition on p1 be functional as the
>>>>> ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
>>>>> how that's being treated in upstream OE around the notion of making an
>>>>> image that's what a UEFI system expects.
>>>>
>>>> Ideally this should be for all TI's K3 devices. I'm unfamiliar with the
>>>> UEFI format and don't know if we currently follow it, however I like the
>>>> idea of /boot/efi from what I googled.  I also found raspian is using
>>>> /boot/firmware. Could this be less of a standard than I think?
>>>
>>> Keep in mind this is a generic OE on 64bit Arm problem and not a TI
>>> specific problem.  Where to mount the ESP should have a consistent
>>> default.  And it should look like it does on an off the shelf distro.
>>>
>>
>> While not an exact ESP partition, we are working on making our boot
>> partition as close as we can given ROM constraints.
>>
>> I'm running into the problem now of updating kernel on a live system,
>> would fail as we have mounted our boot partition over the rootfs boot/
>> directory, so new images are not installed to the right spot/partition.
>>
>> Let's go with /boot/efi if that works for everyone.
>>
>> Bryan, could you re-send this with that change and the same for
>> sdimage-2part-efi.wks.in?
> 
> The only feedback I would provide here is to work with the ROM team to
> fix whatever constraints prevent an "ESP" itself from being used as this
> will hinder the long term viability of the processors being widely
> supported.

Haha, this debate has lasted so long that systemd-boot has standardized 
mounting the ESP partition to just /efi now [1].

[1] https://www.freedesktop.org/software/systemd/man/systemd-boot.html

Randolph
Bryan Brattlof Sept. 28, 2023, 1:39 p.m. UTC | #9
On September 28, 2023 thus sayeth Res Sapp:
> On 9/27/23 14:02, Tom Rini wrote:
> > On Wed, Sep 27, 2023 at 02:00:26PM -0500, Andrew Davis wrote:
> > > On 7/28/22 6:31 AM, Tom Rini wrote:
> > > > On Mon, Jul 25, 2022 at 06:29:04PM -0500, Bryan Brattlof wrote:
> > > > > On July 22, 2022 thus sayeth Tom Rini:
> > > > > > On Thu, Jul 21, 2022 at 09:31:30PM -0500, Bryan Brattlof wrote:
> > > > > > > On July 21, 2022 thus sayeth Denys Dmytriyenko:
> > > > > > > > I don't think this is a correct solution, or maybe I'm not understanding the
> > > > > > > > problem. Can you please elaborate a bit more on the problem?
> > > > > > > > 
> > > > > > > 
> > > > > > > I'm fairly new to yocto so I'm sure I've found the entirely wrong way to
> > > > > > > get what I wanted :)
> > > > > > > 
> > > > > > > After boot it appears /etc/fstab is setup to mount our vfat boot
> > > > > > > partition to the /boot directory currently holding the Image and dtbs.
> > > > > > > I guess because uboot has already thrown the kernel and dtb into ddr at
> > > > > > > this point only Anand was able to notice this.
> > > > > > > 
> > > > > > > My change should mount the vfat partition to /boot/firmware so we can
> > > > > > > access to both our spls and kernel binaries in /boot.
> > > > > > > 
> > > > > > > I'm also not sure what folder name to use here. It seem like there may
> > > > > > > be a standard to this? Would /boot/uboot be more correct?
> > > > > > 
> > > > > > So which SoCs are we talking about here?  For the 64bit parts, the
> > > > > > intention should be that the FAT partition on p1 be functional as the
> > > > > > ESP.  So that means mounting it to /boot/efi.  But I'm not sure off-hand
> > > > > > how that's being treated in upstream OE around the notion of making an
> > > > > > image that's what a UEFI system expects.
> > > > > 
> > > > > Ideally this should be for all TI's K3 devices. I'm unfamiliar with the
> > > > > UEFI format and don't know if we currently follow it, however I like the
> > > > > idea of /boot/efi from what I googled.  I also found raspian is using
> > > > > /boot/firmware. Could this be less of a standard than I think?
> > > > 
> > > > Keep in mind this is a generic OE on 64bit Arm problem and not a TI
> > > > specific problem.  Where to mount the ESP should have a consistent
> > > > default.  And it should look like it does on an off the shelf distro.
> > > > 
> > > 
> > > While not an exact ESP partition, we are working on making our boot
> > > partition as close as we can given ROM constraints.
> > > 
> > > I'm running into the problem now of updating kernel on a live system,
> > > would fail as we have mounted our boot partition over the rootfs boot/
> > > directory, so new images are not installed to the right spot/partition.
> > > 
> > > Let's go with /boot/efi if that works for everyone.
> > > 
> > > Bryan, could you re-send this with that change and the same for
> > > sdimage-2part-efi.wks.in?
> > 
> > The only feedback I would provide here is to work with the ROM team to
> > fix whatever constraints prevent an "ESP" itself from being used as this
> > will hinder the long term viability of the processors being widely
> > supported.
> 
> Haha, this debate has lasted so long that systemd-boot has standardized
> mounting the ESP partition to just /efi now [1].
> 
> [1] https://www.freedesktop.org/software/systemd/man/systemd-boot.html

Even systemd was having trouble trying to figure it out[2] ;)

I'll respin this today with /boot/efi

~Bryan

[2] https://github.com/systemd/systemd/pull/3757
diff mbox series

Patch

diff --git a/wic/sdimage-2part.wks b/wic/sdimage-2part.wks
index 77d6f7b576aef..7567c4429a2eb 100644
--- a/wic/sdimage-2part.wks
+++ b/wic/sdimage-2part.wks
@@ -2,5 +2,5 @@ 
 # long-description: Creates a partitioned SD card image for TI platforms.
 # Boot files are located in the first vfat partition with extra reserved space.
 
-part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 1024 --extra-space 100M --use-uuid
+part /boot/firmware --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 1024 --extra-space 100M --use-uuid
 part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root --align 1024 --use-uuid