Mender NVIDIA Tegra Jetson TX2 Platform Support
337 views
Skip to first unread message
Dan Walkes
Nov 3, 2018, 11:13:18 AM11/3/18
to Mender List mender.io
Hi Everyone!
Building on the amazing work of the Yocto community, Mender community, and Matt Madison's meta-tegra project, I've shared a project at meta-mender-tegra with preliminary support for Mender on NVIDIA Tegra. So far I've tested on the sumo branch using Jetson TX2 hardware. I've added a post on mender hub with details. I've also shared a yocto-tegra project which demonstrates support for this platform.
I've got some open questions in the pull request here so I expect the implementation will change. Any suggestions from the mender community about how to best simplify the configuration, especially partitioning and u-boot environment, are appreciated.
I'd also appreciate help from anyone who would like to test on other Yocto branches or on different hardware (I only have a Jetson TX2 development board).
Thanks!
Dan
Mirza Krak
Nov 5, 2018, 4:51:09 AM11/5/18
to Mender List mender.io
On Sat, Nov 3, 2018 at 4:13 PM Dan Walkes <danw...@trellis-logic.com> wrote:
Hi Everyone!Building on the amazing work of the Yocto community, Mender community, and Matt Madison's meta-tegra project, I've shared a project at meta-mender-tegra with preliminary support for Mender on NVIDIA Tegra. So far I've tested on the sumo branch using Jetson TX2 hardware. I've added a post on mender hub with details. I've also shared a yocto-tegra project which demonstrates support for this platform.I've got some open questions in the pull request here so I expect the implementation will change. Any suggestions from the mender community about how to best simplify the configuration, especially partitioning and u-boot environment, are appreciated.
I do not have much experience with TX1/TX2 but I have worked a bit the previous generation Tegra2/Tegra3.
Provisioning has always been bit of a pain, due to the specialized tools used for Tegra where you create the partitions with the tool (xml file in this case right?). Our workaround working with the older SoCs was not to use the flashing tools from NVIDIA, but instead just executing U-boot from recovery mode and then you can take a fairly standard approach on flashing the devices. The tool used was tegrarcm [1].
But this would probably be a to big of an overhaul of how meta-tegra works today, and it might be easier to use the current classes available in meta-tegra.
Regarding the U-boot environment location. I recently also worked with a board with similar hardware partitioning and U-boot environment was stored on one of these as well (default BSP), that is:
/dev/mmcblk0boot1
What I noticed is that Mender currently does not support putting the environment on one of the HW partitions. Maybe you could make it work, but you would probably need to fight the meta-mender layer as there are many assumptions that it should go in the "root part".
In the end I accepted the location that meta-mender generates, meaning that it ends up on "/dev/mmcblk0" which worked just fine for me.
I have seen that is pretty common to put the U-boot environment on the last block of "/dev/mmcblk0boot1", not sure if it has any real benefits and might be just a thing that everyone copies because someone else did it :).
I'd also appreciate help from anyone who would like to test on other Yocto branches or on different hardware (I only have a Jetson TX2 development board).
Dan Walkes
Nov 10, 2018, 12:32:17 PM11/10/18
to men...@lists.mender.io
Thanks for the response Mirza. I've opened a PR today for meta-mender-community changes at https://github.com/mendersoftware/meta-mender-community/pull/15
I do not have much experience with TX1/TX2 but I have worked a bit the previous generation Tegra2/Tegra3.Provisioning has always been bit of a pain, due to the specialized tools used for Tegra where you create the partitions with the tool (xml file in this case right?). Our workaround working with the older SoCs was not to use the flashing tools from NVIDIA, but instead just executing U-boot from recovery mode and then you can take a fairly standard approach on flashing the devices. The tool used was tegrarcm [1].But this would probably be a to big of an overhaul of how meta-tegra works today, and it might be easier to use the current classes available in meta-tegra.
Agree, and this is an interesting option but I also think it might be better to use the support meta-tegra has built in today. The deployment used there is really simple and also useful for people who don't have u-boot serial console access which requires additional TTL to serial conversion hardware [1].
Regarding the U-boot environment location. I recently also worked with a board with similar hardware partitioning and U-boot environment was stored on one of these as well (default BSP), that is:/dev/mmcblk0boot1What I noticed is that Mender currently does not support putting the environment on one of the HW partitions. Maybe you could make it work, but you would probably need to fight the meta-mender layer as there are many assumptions that it should go in the "root part".In the end I accepted the location that meta-mender generates, meaning that it ends up on "/dev/mmcblk0" which worked just fine for me.I have seen that is pretty common to put the U-boot environment on the last block of "/dev/mmcblk0boot1", not sure if it has any real benefits and might be just a thing that everyone copies because someone else did it :).
Thanks for sharing this background and experience. Based on this and a re-read of Matt's comments in the PR [2] about problems on some environments with redundancy I'm thinking it's better to keep the dedicated u-boot environment partition and to keep it after the other tegra partitions defined in the default layout. I've added some comments in the README.md [3] about work which needs to happen regarding partitioning setup on new tegra platforms.
Reply all
Reply to author
Forward
0 new messages