meta-swupdate-boards: Support for tegra platforms
148 views
Skip to first unread message
Dan Walkes
Jan 15, 2024, 3:32:19 PM1/15/24
to swupdate
Hi Stefano et al.,
Thanks for sharing all of your work and time on swupdate.
We've had several requests from the OE4T meta-tegra community for an
example which demonstrates software update on NVIDIA Jetson targets on
the latest production (Jetpack 5) release.
I've put together an example at [1] which I'd like to share with the
larger community and reference in our meta-tegra documentation.
I thought I'd start with this post to inquire about interest in a set
of patches to demonstrate tegra update support for
meta-swupdate-boards.
I was planning to share two patches:
* The first one at [2] which removes the emmcsetup.lua files from
platforms which don't use it, and makes it's inclusion in update-image
conditional on beaglebone_yocto, to avoid the need to add an empty and
unused file for tegra platforms. I haven't tested this change on
other platforms but I can do so if desired.
* The second one at [3] which adds support for tegra platforms, and a
dedicated README section for tegra.
Note that I've set up the tegra build slightly differently than the
other examples, with a dedicated update-image-tegra in dynamic-layers,
since it seemed there wasn't much to share with the existing
update-image and also because it will be dependent on the meta-tegra
layer. Let me know if there are different preferences about how you'd
like this set up.
One thing I was considering was potentially moving the tegra specific
readme content to a dedicated file. I can do that if desired.
Thanks for reviewing this request and thanks again for sharing your
work on swupdate.
Dan
1: https://github.com/Trellis-Logic/meta-swupdate-boards/tree/master%2Btegra
2: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/d40922841d504f6448ccdec5a40413a96fb0a368
3: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/685d8a333bba1a60d4cf3360fddc1b8ce869761e
Thanks for sharing all of your work and time on swupdate.
We've had several requests from the OE4T meta-tegra community for an
example which demonstrates software update on NVIDIA Jetson targets on
the latest production (Jetpack 5) release.
I've put together an example at [1] which I'd like to share with the
larger community and reference in our meta-tegra documentation.
I thought I'd start with this post to inquire about interest in a set
of patches to demonstrate tegra update support for
meta-swupdate-boards.
I was planning to share two patches:
* The first one at [2] which removes the emmcsetup.lua files from
platforms which don't use it, and makes it's inclusion in update-image
conditional on beaglebone_yocto, to avoid the need to add an empty and
unused file for tegra platforms. I haven't tested this change on
other platforms but I can do so if desired.
* The second one at [3] which adds support for tegra platforms, and a
dedicated README section for tegra.
Note that I've set up the tegra build slightly differently than the
other examples, with a dedicated update-image-tegra in dynamic-layers,
since it seemed there wasn't much to share with the existing
update-image and also because it will be dependent on the meta-tegra
layer. Let me know if there are different preferences about how you'd
like this set up.
One thing I was considering was potentially moving the tegra specific
readme content to a dedicated file. I can do that if desired.
Thanks for reviewing this request and thanks again for sharing your
work on swupdate.
Dan
1: https://github.com/Trellis-Logic/meta-swupdate-boards/tree/master%2Btegra
2: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/d40922841d504f6448ccdec5a40413a96fb0a368
3: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/685d8a333bba1a60d4cf3360fddc1b8ce869761e
Stefano Babic
Jan 16, 2024, 10:04:03 AM1/16/24
to Dan Walkes, swupdate
Hi Dan,
On 15.01.24 21:32, Dan Walkes wrote:
> Hi Stefano et al.,
>
> Thanks for sharing all of your work and time on swupdate.
>
> We've had several requests from the OE4T meta-tegra community for an
> example which demonstrates software update on NVIDIA Jetson targets on
> the latest production (Jetpack 5) release.
The problem with Tegra devices is, near the chronicle missing
documentation, that the boot sequence was steadily changed by Nvidia. I
had project with TX (based on U-Boot), then TX2 / Xavier (L4T, based on
Cboot, that leads to have support for it in SWUpdate) and later they
switch to EFI.
Last one is not yet supported in SWupdate because I think that an OTA
updater should have less dependencies as possible and be self
copntained, that means drop as much as possible any call to external
tools, that should be present on the older release causing an increased
dependency. That is the case here with the "os-indications".
a clean way is to add support into SWUpdate for EFI vars and integrate
what is required for Tegra, instead of calling a script like in
recipes-extended/images/update-image/tegra/bootloader-update.lua
>
> I've put together an example at [1] which I'd like to share with the
> larger community and reference in our meta-tegra documentation.
>
> I thought I'd start with this post to inquire about interest in a set
> of patches to demonstrate tegra update support for
> meta-swupdate-boards.
>
> I was planning to share two patches:
> * The first one at [2] which removes the emmcsetup.lua files
This is old stuff that is not used anymore. To be honest,
meta-swupdate-boards was firstly created because there was a request
from several users to get some examples. In my case, customers want to
have SWUpdate integrated on own projects, and they do not bothered about
eval boards. It looks like that the same happened to the same users
asking first for it, and after an initial interest, they focus on their
product. So IMHO meta-swupdate-boards contains some old and legacy stuff
(like the emmcsetup.lua script, not required because SWUpdate has native
support for partitions).
> from
> platforms which don't use it, and makes it's inclusion in update-image
> conditional on beaglebone_yocto, to avoid the need to add an empty and
> unused file for tegra platforms. I haven't tested this change on
> other platforms but I can do so if desired.
> * The second one at [3] which adds support for tegra platforms, and a
> dedicated README section for tegra.
>
IMHO it is misleading if it is not done in the appropriate way, that is
add EFI support for boot vars in SWUpdate. SWUpdate has an abstraction
for botloader setup, and even for Tegra it should work in the same way
via the bootloader internal interface.
> Note that I've set up the tegra build slightly differently than the
> other examples, with a dedicated update-image-tegra in dynamic-layers,
> since it seemed there wasn't much to share with the existing
> update-image and also because it will be dependent on the meta-tegra
> layer. Let me know if there are different preferences about how you'd
> like this set up.
>
> One thing I was considering was potentially moving the tegra specific
> readme content to a dedicated file. I can do that if desired.
>
> Thanks for reviewing this request and thanks again for sharing your
> work on swupdate.
>
> Dan
>
> 1: https://github.com/Trellis-Logic/meta-swupdate-boards/tree/master%2Btegra
> 2: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/d40922841d504f6448ccdec5a40413a96fb0a368
> 3: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/685d8a333bba1a60d4cf3360fddc1b8ce869761e
>
Best regards,
Stefano Babic
On 15.01.24 21:32, Dan Walkes wrote:
> Hi Stefano et al.,
>
> Thanks for sharing all of your work and time on swupdate.
>
> We've had several requests from the OE4T meta-tegra community for an
> example which demonstrates software update on NVIDIA Jetson targets on
> the latest production (Jetpack 5) release.
documentation, that the boot sequence was steadily changed by Nvidia. I
had project with TX (based on U-Boot), then TX2 / Xavier (L4T, based on
Cboot, that leads to have support for it in SWUpdate) and later they
switch to EFI.
Last one is not yet supported in SWupdate because I think that an OTA
updater should have less dependencies as possible and be self
copntained, that means drop as much as possible any call to external
tools, that should be present on the older release causing an increased
dependency. That is the case here with the "os-indications".
a clean way is to add support into SWUpdate for EFI vars and integrate
what is required for Tegra, instead of calling a script like in
recipes-extended/images/update-image/tegra/bootloader-update.lua
>
> I've put together an example at [1] which I'd like to share with the
> larger community and reference in our meta-tegra documentation.
>
> I thought I'd start with this post to inquire about interest in a set
> of patches to demonstrate tegra update support for
> meta-swupdate-boards.
>
> I was planning to share two patches:
> * The first one at [2] which removes the emmcsetup.lua files
meta-swupdate-boards was firstly created because there was a request
from several users to get some examples. In my case, customers want to
have SWUpdate integrated on own projects, and they do not bothered about
eval boards. It looks like that the same happened to the same users
asking first for it, and after an initial interest, they focus on their
product. So IMHO meta-swupdate-boards contains some old and legacy stuff
(like the emmcsetup.lua script, not required because SWUpdate has native
support for partitions).
> from
> platforms which don't use it, and makes it's inclusion in update-image
> conditional on beaglebone_yocto, to avoid the need to add an empty and
> unused file for tegra platforms. I haven't tested this change on
> other platforms but I can do so if desired.
> * The second one at [3] which adds support for tegra platforms, and a
> dedicated README section for tegra.
>
add EFI support for boot vars in SWUpdate. SWUpdate has an abstraction
for botloader setup, and even for Tegra it should work in the same way
via the bootloader internal interface.
> Note that I've set up the tegra build slightly differently than the
> other examples, with a dedicated update-image-tegra in dynamic-layers,
> since it seemed there wasn't much to share with the existing
> update-image and also because it will be dependent on the meta-tegra
> layer. Let me know if there are different preferences about how you'd
> like this set up.
>
> One thing I was considering was potentially moving the tegra specific
> readme content to a dedicated file. I can do that if desired.
>
> Thanks for reviewing this request and thanks again for sharing your
> work on swupdate.
>
> Dan
>
> 1: https://github.com/Trellis-Logic/meta-swupdate-boards/tree/master%2Btegra
> 2: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/d40922841d504f6448ccdec5a40413a96fb0a368
> 3: https://github.com/Trellis-Logic/meta-swupdate-boards/commit/685d8a333bba1a60d4cf3360fddc1b8ce869761e
>
Stefano Babic
Dan Walkes
Jan 16, 2024, 3:40:01 PM1/16/24
to Stefano Babic, swupdate
Hi Stefano,
Thanks for the response.
On Tue, Jan 16, 2024 at 8:04 AM Stefano Babic
<stefan...@swupdate.org> wrote:
>
> Hi Dan,
>
> On 15.01.24 21:32, Dan Walkes wrote:
> > Hi Stefano et al.,
> >
they will remain with EFI in Jetpack 6.
> Last one is not yet supported in SWupdate because I think that an OTA
> updater should have less dependencies as possible and be self
> copntained, that means drop as much as possible any call to external
> tools, that should be present on the older release causing an increased
> dependency. That is the case here with the "os-indications".
>
> a clean way is to add support into SWUpdate for EFI vars and integrate
> what is required for Tegra, instead of calling a script like in
> recipes-extended/images/update-image/tegra/bootloader-update.lua
>
I think what you are suggesting is to take the logic at [4] as
well as the functionality of the efivar utility used there and
incorporate directly
into the swupdate executable, with a special EFI bootloader target
configuration,
then supporting setting 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
with a `vars` section as discussed at [5], is that correct?
> >
> > I've put together an example at [1] which I'd like to share with the
> > larger community and reference in our meta-tegra documentation.
> >
> > I thought I'd start with this post to inquire about interest in a set
> > of patches to demonstrate tegra update support for
> > meta-swupdate-boards.
> >
> > I was planning to share two patches:
> > * The first one at [2] which removes the emmcsetup.lua files
>
> This is old stuff that is not used anymore. To be honest,
> meta-swupdate-boards was firstly created because there was a request
> from several users to get some examples. In my case, customers want to
> have SWUpdate integrated on own projects, and they do not bothered about
> eval boards. It looks like that the same happened to the same users
> asking first for it, and after an initial interest, they focus on their
> product. So IMHO meta-swupdate-boards contains some old and legacy stuff
> (like the emmcsetup.lua script, not required because SWUpdate has native
> support for partitions).
Does this mean that you don't intend to add support for development boards
in this repository going forward? Or you'd only add if a complete integration
with swupdate was available as you've suggested above?
directly in swupdate,
and some of this logic could likely be used with other targets, but it seems
for tegra specifically this would be more work for not a lot of additional value
unless I'm missing something about what would be gained with this
integration. I think
the main benefit would be removing dependencies from the external efivar utility
and the logic in [4].
I suspect the benefit of full bootloader integration would be to
provide capabilities like
redundancy/rollback which aren't going to be possible without using
something other than
the capsule update mechanism NVIDIA provides with their EDK implementation and
references in their documentation.
Thanks for considering and thanks again for sharing your work on swupdate.
Dan
4: https://github.com/OE4T/meta-tegra/blob/563552ce0272495511e5a8f1d6ddfacb54b368e4/recipes-bsp/tools/setup-nv-boot-control/uefi_common.func.in#L12
5: https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables
Thanks for the response.
On Tue, Jan 16, 2024 at 8:04 AM Stefano Babic
<stefan...@swupdate.org> wrote:
>
> Hi Dan,
>
> On 15.01.24 21:32, Dan Walkes wrote:
> > Hi Stefano et al.,
> >
> The problem with Tegra devices is, near the chronicle missing
> documentation, that the boot sequence was steadily changed by Nvidia. I
> had project with TX (based on U-Boot), then TX2 / Xavier (L4T, based on
> Cboot, that leads to have support for it in SWUpdate) and later they
> switch to EFI.
>
Correct, Jetpack 4 to 5 transition moved to EFI. Indications are that
> documentation, that the boot sequence was steadily changed by Nvidia. I
> had project with TX (based on U-Boot), then TX2 / Xavier (L4T, based on
> Cboot, that leads to have support for it in SWUpdate) and later they
> switch to EFI.
>
they will remain with EFI in Jetpack 6.
> Last one is not yet supported in SWupdate because I think that an OTA
> updater should have less dependencies as possible and be self
> copntained, that means drop as much as possible any call to external
> tools, that should be present on the older release causing an increased
> dependency. That is the case here with the "os-indications".
>
> a clean way is to add support into SWUpdate for EFI vars and integrate
> what is required for Tegra, instead of calling a script like in
> recipes-extended/images/update-image/tegra/bootloader-update.lua
>
well as the functionality of the efivar utility used there and
incorporate directly
into the swupdate executable, with a special EFI bootloader target
configuration,
then supporting setting 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndications
with a `vars` section as discussed at [5], is that correct?
> >
> > I've put together an example at [1] which I'd like to share with the
> > larger community and reference in our meta-tegra documentation.
> >
> > I thought I'd start with this post to inquire about interest in a set
> > of patches to demonstrate tegra update support for
> > meta-swupdate-boards.
> >
> > I was planning to share two patches:
> > * The first one at [2] which removes the emmcsetup.lua files
>
> This is old stuff that is not used anymore. To be honest,
> meta-swupdate-boards was firstly created because there was a request
> from several users to get some examples. In my case, customers want to
> have SWUpdate integrated on own projects, and they do not bothered about
> eval boards. It looks like that the same happened to the same users
> asking first for it, and after an initial interest, they focus on their
> product. So IMHO meta-swupdate-boards contains some old and legacy stuff
> (like the emmcsetup.lua script, not required because SWUpdate has native
> support for partitions).
in this repository going forward? Or you'd only add if a complete integration
with swupdate was available as you've suggested above?
>
>
> > from
> > platforms which don't use it, and makes it's inclusion in update-image
> > conditional on beaglebone_yocto, to avoid the need to add an empty and
> > unused file for tegra platforms. I haven't tested this change on
> > other platforms but I can do so if desired.
> > * The second one at [3] which adds support for tegra platforms, and a
> > dedicated README section for tegra.
> >
>
> IMHO it is misleading if it is not done in the appropriate way, that is
> add EFI support for boot vars in SWUpdate. SWUpdate has an abstraction
> for botloader setup, and even for Tegra it should work in the same way
> via the bootloader internal interface.
It would certainly be possible to set the OsIndications EFI variable
>
> > from
> > platforms which don't use it, and makes it's inclusion in update-image
> > conditional on beaglebone_yocto, to avoid the need to add an empty and
> > unused file for tegra platforms. I haven't tested this change on
> > other platforms but I can do so if desired.
> > * The second one at [3] which adds support for tegra platforms, and a
> > dedicated README section for tegra.
> >
>
> IMHO it is misleading if it is not done in the appropriate way, that is
> add EFI support for boot vars in SWUpdate. SWUpdate has an abstraction
> for botloader setup, and even for Tegra it should work in the same way
> via the bootloader internal interface.
directly in swupdate,
and some of this logic could likely be used with other targets, but it seems
for tegra specifically this would be more work for not a lot of additional value
unless I'm missing something about what would be gained with this
integration. I think
the main benefit would be removing dependencies from the external efivar utility
and the logic in [4].
I suspect the benefit of full bootloader integration would be to
provide capabilities like
redundancy/rollback which aren't going to be possible without using
something other than
the capsule update mechanism NVIDIA provides with their EDK implementation and
references in their documentation.
Thanks for considering and thanks again for sharing your work on swupdate.
Dan
4: https://github.com/OE4T/meta-tegra/blob/563552ce0272495511e5a8f1d6ddfacb54b368e4/recipes-bsp/tools/setup-nv-boot-control/uefi_common.func.in#L12
5: https://sbabic.github.io/swupdate/sw-description.html#swupdate-persistent-variables
Stefano Babic
Jan 16, 2024, 8:03:32 PM1/16/24
to Dan Walkes, Stefano Babic, swupdate
Hi Dan,
Yes, so that Tegra becomes a target like all other ones.
>
>>>
>>> I've put together an example at [1] which I'd like to share with the
>>> larger community and reference in our meta-tegra documentation.
>>>
>>> I thought I'd start with this post to inquire about interest in a set
>>> of patches to demonstrate tegra update support for
>>> meta-swupdate-boards.
>>>
>>> I was planning to share two patches:
>>> * The first one at [2] which removes the emmcsetup.lua files
>>
>> This is old stuff that is not used anymore. To be honest,
>> meta-swupdate-boards was firstly created because there was a request
>> from several users to get some examples. In my case, customers want to
>> have SWUpdate integrated on own projects, and they do not bothered about
>> eval boards. It looks like that the same happened to the same users
>> asking first for it, and after an initial interest, they focus on their
>> product. So IMHO meta-swupdate-boards contains some old and legacy stuff
>> (like the emmcsetup.lua script, not required because SWUpdate has native
>> support for partitions).
>
> Does this mean that you don't intend to add support for development boards
> in this repository going forward?
No, it just means that I do not spend a lot of effort in this repo, but
I will accept contributions. The repo was still tested under -dunfell,
tests and rework of images was not done after that.
> Or you'd only add if a complete integration
> with swupdate was available as you've suggested above?
meta-swupdate-boards is thought as *examples* (maybe it should be better
stated in README), and not as a reference to be copied. I could also
merge a new board if it is documented which are the limits and the
issues, like not existent bootloader support. It seems weird, because
fallback in L4t with Cboot (or previous version with U-Boot) worked.
>>
>>
>>> from
>>> platforms which don't use it, and makes it's inclusion in update-image
>>> conditional on beaglebone_yocto, to avoid the need to add an empty and
>>> unused file for tegra platforms. I haven't tested this change on
>>> other platforms but I can do so if desired.
>>> * The second one at [3] which adds support for tegra platforms, and a
>>> dedicated README section for tegra.
>>>
>>
>> IMHO it is misleading if it is not done in the appropriate way, that is
>> add EFI support for boot vars in SWUpdate. SWUpdate has an abstraction
>> for botloader setup, and even for Tegra it should work in the same way
>> via the bootloader internal interface.
>
> It would certainly be possible to set the OsIndications EFI variable
> directly in swupdate,
> and some of this logic could likely be used with other targets, but it seems
> for tegra specifically this would be more work for not a lot of additional value
> unless I'm missing something about what would be gained with this
> integration. I think
> the main benefit would be removing dependencies from the external efivar utility
> and the logic in [4].
>
> I suspect the benefit of full bootloader integration would be to
> provide capabilities like
> redundancy/rollback
I confess that this should be the goal. Fallback is a plus in an update
strategies and restores the board in many case due to runtime issues. It
is a pity if this is not available, and it is a step back because this
was possible with older Jetpacks.
Nvidia had always had its way in the past, that wasn't sufficient for a
fallback. I am not aware with Jetpack 5, but Jetpack 4 still required to
patch cboot to provide a full functional fallback, that is not just
toggling between rootfs.
> which aren't going to be possible without using
> something other than
> the capsule update mechanism NVIDIA provides with their EDK implementation and
> references in their documentation.
As you have more investigated with Jetpack 5, can you provide me links
so that I understand why it is not possible ?
Best regards,
Stefano
>
>>>
>>> I've put together an example at [1] which I'd like to share with the
>>> larger community and reference in our meta-tegra documentation.
>>>
>>> I thought I'd start with this post to inquire about interest in a set
>>> of patches to demonstrate tegra update support for
>>> meta-swupdate-boards.
>>>
>>> I was planning to share two patches:
>>> * The first one at [2] which removes the emmcsetup.lua files
>>
>> This is old stuff that is not used anymore. To be honest,
>> meta-swupdate-boards was firstly created because there was a request
>> from several users to get some examples. In my case, customers want to
>> have SWUpdate integrated on own projects, and they do not bothered about
>> eval boards. It looks like that the same happened to the same users
>> asking first for it, and after an initial interest, they focus on their
>> product. So IMHO meta-swupdate-boards contains some old and legacy stuff
>> (like the emmcsetup.lua script, not required because SWUpdate has native
>> support for partitions).
>
> Does this mean that you don't intend to add support for development boards
> in this repository going forward?
I will accept contributions. The repo was still tested under -dunfell,
tests and rework of images was not done after that.
> Or you'd only add if a complete integration
> with swupdate was available as you've suggested above?
stated in README), and not as a reference to be copied. I could also
merge a new board if it is documented which are the limits and the
issues, like not existent bootloader support. It seems weird, because
fallback in L4t with Cboot (or previous version with U-Boot) worked.
>>
>>
>>> from
>>> platforms which don't use it, and makes it's inclusion in update-image
>>> conditional on beaglebone_yocto, to avoid the need to add an empty and
>>> unused file for tegra platforms. I haven't tested this change on
>>> other platforms but I can do so if desired.
>>> * The second one at [3] which adds support for tegra platforms, and a
>>> dedicated README section for tegra.
>>>
>>
>> IMHO it is misleading if it is not done in the appropriate way, that is
>> add EFI support for boot vars in SWUpdate. SWUpdate has an abstraction
>> for botloader setup, and even for Tegra it should work in the same way
>> via the bootloader internal interface.
>
> It would certainly be possible to set the OsIndications EFI variable
> directly in swupdate,
> and some of this logic could likely be used with other targets, but it seems
> for tegra specifically this would be more work for not a lot of additional value
> unless I'm missing something about what would be gained with this
> integration. I think
> the main benefit would be removing dependencies from the external efivar utility
> and the logic in [4].
>
> I suspect the benefit of full bootloader integration would be to
> provide capabilities like
> redundancy/rollback
strategies and restores the board in many case due to runtime issues. It
is a pity if this is not available, and it is a step back because this
was possible with older Jetpacks.
Nvidia had always had its way in the past, that wasn't sufficient for a
fallback. I am not aware with Jetpack 5, but Jetpack 4 still required to
patch cboot to provide a full functional fallback, that is not just
toggling between rootfs.
> which aren't going to be possible without using
> something other than
> the capsule update mechanism NVIDIA provides with their EDK implementation and
> references in their documentation.
so that I understand why it is not possible ?
Best regards,
Stefano
Dan Walkes
Jan 18, 2024, 6:29:46 PM1/18/24
to Stefano Babic, swupdate
Hi Stefano,
Apologies, I just realized I inadvertently left the list out of my
response. Resending to the list.
On Tue, Jan 16, 2024 at 6:03 PM Stefano Babic
<stefan...@swupdate.org> wrote:
>
> I confess that this should be the goal. Fallback is a plus in an update
> strategies and restores the board in many case due to runtime issues. It
> is a pity if this is not available, and it is a step back because this
> was possible with older Jetpacks.
>
> Nvidia had always had its way in the past, that wasn't sufficient for a
> fallback. I am not aware with Jetpack 5, but Jetpack 4 still required to
> patch cboot to provide a full functional fallback, that is not just
> toggling between rootfs.
>
Do you have any information about the patches used for cboot? I'm not
familiar with these. The cboot implementations I used for Jetpack 4
worked similarly, using nvidia's nv-update-engine (or
tegra-bootloader-update) tool to perform the bootloader update and
switch to the alternate rootfs. Example at [6].
>
> > which aren't going to be possible without using
> > something other than
> > the capsule update mechanism NVIDIA provides with their EDK implementation and
> > references in their documentation.
>
> As you have more investigated with Jetpack 5, can you provide me links
> so that I understand why it is not possible ?
I'm sure it is possible somehow by customizing NVIDIA's EDK
bootloader, I was just mentioning that the current implementation uses
the Capsule Update feature as described by NVIDIA in their
documentation at [7].
>
> Best regards,
> Stefano
>
6: https://github.com/mendersoftware/meta-mender-community/blob/kirkstone/meta-mender-tegra/recipes-mender/tegra-state-scripts/files/redundant-boot-install-script
7: https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/Bootloader/UpdateAndRedundancy.html?highlight=capsule#manually-trigger-the-capsule-update
Apologies, I just realized I inadvertently left the list out of my
response. Resending to the list.
On Tue, Jan 16, 2024 at 6:03 PM Stefano Babic
<stefan...@swupdate.org> wrote:
>
> I confess that this should be the goal. Fallback is a plus in an update
> strategies and restores the board in many case due to runtime issues. It
> is a pity if this is not available, and it is a step back because this
> was possible with older Jetpacks.
>
> Nvidia had always had its way in the past, that wasn't sufficient for a
> fallback. I am not aware with Jetpack 5, but Jetpack 4 still required to
> patch cboot to provide a full functional fallback, that is not just
> toggling between rootfs.
>
familiar with these. The cboot implementations I used for Jetpack 4
worked similarly, using nvidia's nv-update-engine (or
tegra-bootloader-update) tool to perform the bootloader update and
switch to the alternate rootfs. Example at [6].
>
> > which aren't going to be possible without using
> > something other than
> > the capsule update mechanism NVIDIA provides with their EDK implementation and
> > references in their documentation.
>
> As you have more investigated with Jetpack 5, can you provide me links
> so that I understand why it is not possible ?
bootloader, I was just mentioning that the current implementation uses
the Capsule Update feature as described by NVIDIA in their
documentation at [7].
>
> Best regards,
> Stefano
>
6: https://github.com/mendersoftware/meta-mender-community/blob/kirkstone/meta-mender-tegra/recipes-mender/tegra-state-scripts/files/redundant-boot-install-script
7: https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/Bootloader/UpdateAndRedundancy.html?highlight=capsule#manually-trigger-the-capsule-update
Stefano Babic
Jan 21, 2024, 8:57:24 AM1/21/24
to Dan Walkes, Stefano Babic, swupdate
Hi Dan,
On 19.01.24 00:29, Dan Walkes wrote:
> Hi Stefano,
> Apologies, I just realized I inadvertently left the list out of my
> response. Resending to the list.
>
Thanks !
> On Tue, Jan 16, 2024 at 6:03 PM Stefano Babic
> <stefan...@swupdate.org> wrote:
>>
>> I confess that this should be the goal. Fallback is a plus in an update
>> strategies and restores the board in many case due to runtime issues. It
>> is a pity if this is not available, and it is a step back because this
>> was possible with older Jetpacks.
>>
>> Nvidia had always had its way in the past, that wasn't sufficient for a
>> fallback. I am not aware with Jetpack 5, but Jetpack 4 still required to
>> patch cboot to provide a full functional fallback, that is not just
>> toggling between rootfs.
>>
> Do you have any information about the patches used for cboot?
Sure.
> I'm not
> familiar with these. The cboot implementations I used for Jetpack 4
> worked similarly, using nvidia's nv-update-engine (or
> tegra-bootloader-update) tool to perform the bootloader update and
> switch to the alternate rootfs. Example at [6].
Jetpack as delivered by Nvidia uses he nv-update-engine and there is no
fallback. Surely, Nvidia has more focus that the board is never bricked
(there are a lot of redundancy) else to update the full stack. With
nv-update-engine, just rootfs can be switched. Nevertheless, most
customers needs to update kernel, DT,etc. Fallback is strictly required
because a new DT can activate some drivers that can cause hanging on
some devices.
My choice was to drop kernel partitions (kernel_a / kernel_b) and put
the kernel inside rootfs. To perform the switch, I decided to use the
bootinfo (tegra-bootinfo) structure. This is put on TX2 / Xavier on
internal SPI flash and IMHO Nvidia's implementation for it is robust and
power-cut safe, that is well designed to store some kind of environment.
SWUpdate was adapted top manage them as bootloader's vars, see :
https://github.com/sbabic/swupdate/blob/master/bootloader/cboot.c
This uses the library provided by meta-tegra, and everything is
mainlined in SWupdate.
The delievered cboot (t19x-32.7.3 in my case) does not evaluate the
bootinfo, just for machine-id because it should be passed as kernel parm
at startup. I then changed the code and evaluate bootinfo vars to decide
which is the partition to be read to get the kernel and DT (default is
first partition or a partition with a GUID that is not standard but
invented by Nvidia). A counter was already implemented and it work like
the one in U-Boot - after hitting a threshold, a fallback happens inside
cboot.
cboot is delivered by Nvidia with an own license, and Nvidia is known to
not allowed 3rd-party contribution, so I never tried to push. This had
required more work, because I disabled in my patch the standard Nvidia
mode. And because license is not GPL, I cannot post my patch without
explicit agreement of my customer. However, what I did is explained above.
>
>>
>>> which aren't going to be possible without using
>>> something other than
>>> the capsule update mechanism NVIDIA provides with their EDK implementation and
>>> references in their documentation.
>>
>> As you have more investigated with Jetpack 5, can you provide me links
>> so that I understand why it is not possible ?
>
> I'm sure it is possible somehow by customizing NVIDIA's EDK
> bootloader, I was just mentioning that the current implementation uses
> the Capsule Update feature as described by NVIDIA in their
> documentation at [7].
Ah ok, same movie then as I already saw with previous release. Digging
in bootloader is required again to add fallback functionality. But
frankly speaking, as Nvidia already changed more than one time the boot
workflow, even if says that won't change in future is not enough to be
sure. And because contributions are not easy accepted, this requires
maintaining own patches in future.
Best regards,
Stefano
On 19.01.24 00:29, Dan Walkes wrote:
> Hi Stefano,
> Apologies, I just realized I inadvertently left the list out of my
> response. Resending to the list.
>
> On Tue, Jan 16, 2024 at 6:03 PM Stefano Babic
> <stefan...@swupdate.org> wrote:
>>
>> I confess that this should be the goal. Fallback is a plus in an update
>> strategies and restores the board in many case due to runtime issues. It
>> is a pity if this is not available, and it is a step back because this
>> was possible with older Jetpacks.
>>
>> Nvidia had always had its way in the past, that wasn't sufficient for a
>> fallback. I am not aware with Jetpack 5, but Jetpack 4 still required to
>> patch cboot to provide a full functional fallback, that is not just
>> toggling between rootfs.
>>
> Do you have any information about the patches used for cboot?
> I'm not
> familiar with these. The cboot implementations I used for Jetpack 4
> worked similarly, using nvidia's nv-update-engine (or
> tegra-bootloader-update) tool to perform the bootloader update and
> switch to the alternate rootfs. Example at [6].
fallback. Surely, Nvidia has more focus that the board is never bricked
(there are a lot of redundancy) else to update the full stack. With
nv-update-engine, just rootfs can be switched. Nevertheless, most
customers needs to update kernel, DT,etc. Fallback is strictly required
because a new DT can activate some drivers that can cause hanging on
some devices.
My choice was to drop kernel partitions (kernel_a / kernel_b) and put
the kernel inside rootfs. To perform the switch, I decided to use the
bootinfo (tegra-bootinfo) structure. This is put on TX2 / Xavier on
internal SPI flash and IMHO Nvidia's implementation for it is robust and
power-cut safe, that is well designed to store some kind of environment.
SWUpdate was adapted top manage them as bootloader's vars, see :
https://github.com/sbabic/swupdate/blob/master/bootloader/cboot.c
This uses the library provided by meta-tegra, and everything is
mainlined in SWupdate.
The delievered cboot (t19x-32.7.3 in my case) does not evaluate the
bootinfo, just for machine-id because it should be passed as kernel parm
at startup. I then changed the code and evaluate bootinfo vars to decide
which is the partition to be read to get the kernel and DT (default is
first partition or a partition with a GUID that is not standard but
invented by Nvidia). A counter was already implemented and it work like
the one in U-Boot - after hitting a threshold, a fallback happens inside
cboot.
cboot is delivered by Nvidia with an own license, and Nvidia is known to
not allowed 3rd-party contribution, so I never tried to push. This had
required more work, because I disabled in my patch the standard Nvidia
mode. And because license is not GPL, I cannot post my patch without
explicit agreement of my customer. However, what I did is explained above.
>
>>
>>> which aren't going to be possible without using
>>> something other than
>>> the capsule update mechanism NVIDIA provides with their EDK implementation and
>>> references in their documentation.
>>
>> As you have more investigated with Jetpack 5, can you provide me links
>> so that I understand why it is not possible ?
>
> I'm sure it is possible somehow by customizing NVIDIA's EDK
> bootloader, I was just mentioning that the current implementation uses
> the Capsule Update feature as described by NVIDIA in their
> documentation at [7].
in bootloader is required again to add fallback functionality. But
frankly speaking, as Nvidia already changed more than one time the boot
workflow, even if says that won't change in future is not enough to be
sure. And because contributions are not easy accepted, this requires
maintaining own patches in future.
Best regards,
Stefano
Reply all
Reply to author
Forward
0 new messages