sorry, more custom partition questions, nano-emmc and tx2-nx machines

[goetzdd]

Hi, I originally set up custom machines for the xavier-nx and tx2-devkit by following this:

https://github.com/OE4T/meta-tegra/wiki/Creating-a-custom-MACHINE#custom-machine-definitions-for-existing-hardware

In fact the xavier example was for xavier-nx-emmc and I tweaked it back to just the xavier-nx.

For those I created custom flash layouts using a bbappend for mender-custom-flash-layout to provide my own mender_flash.xml files.

So now I've had to bring up another machine based on the xavier-nx-devkit-tx2-nx and though the tx2-devkit one pulled in my custom flash layout from the tegra186 layout the tx2-nx doesn't, I have a feeling it has to do with MACHINEOVERRIDES but could use a push in the right direction.

MACHINEOVERRIDES = "jetson-xavier-nx-devkit-tx2-nx:${MACHINE}"
require conf/machine/jetson-xavier-nx-devkit-tx2-nx.conf
PACKAGE_EXTRA_ARCHS_append = " jetson-xavier-nx-devkit-tx2-nx"

The same is true of setting up a custom machine based on nano-emmc, probably something similar

MACHINEOVERRIDES = "jetson-nano-devkit-emmc:cot:${MACHINE}"
require conf/machine/jetson-nano-devkit-emmc.conf
PACKAGE_EXTRA_ARCHS_append = " jetson-nano-devkit-emmc"

[madisongh]

The overrides settings look OK. Did you create a subdirectory under the directory where you put your bbappend for mender-custom-flash-layout, named the same as your custom MACHINE?

Look at the log.do_unpack log file for mender-custom-flash-layout - that will tell you which file it selected, and which directories it was searching.

[goetzdd]

I duplicated the folder naming from meta-mender-tegra\recipes-bsp\tegra-binaries\mender-custom-flash-layout recipe and the name of the files therein, but in order to make it work I had to change the flash_mender.xml containing folders for the problem child ones to match the machine name I was overriding:

jetson-nano-emmc -> jetson-nano-devkit-emmc

tegra186 -> jetson-xavier-nx-devkit-tx2-nv

Well actually I just created a symlink in my-layer\recipes-bsp\tegra-binaries\mender-custom-flash-layout folder with the matching name that pointed at the proper folder in the same location.

yadda:yadda/layers/meta-troll$ tree recipes-bsp/
recipes-bsp/
├── bootlogo
│ ├── bootlogo-custom
│ │ └── trollsplash_1920x1080.png
│ └── bootlogo-custom_%.bbappend
└── tegra-binaries
├── mender-custom-flash-layout
│ ├── jetson-nano-devkit-emmc -> jetson-nano-emmc
│ ├── jetson-nano-emmc
│ │ └── flash_mender.xml
│ ├── jetson-xavier-nx-devkit
│ │ └── flash_mender.xml
│ ├── jetson-xavier-nx-devkit-emmc
│ │ └── flash_mender.xml
│ ├── jetson-xavier-nx-devkit-tx2-nx -> tegra186
│ ├── tegra186
│ │ └── flash_mender.xml
│ └── tegra210
│ └── flash_mender.xml
├── mender-custom-flash-layout_%.bbappend
└── tegra-configs-alsa_%.bbappend

But if I understand correctly I could have used my own machine name as well, though it seems like that shouldn't have been necessary in the first place.

[goetzdd]

two things:

1. This should have been in tegra-demo-distro I suppose.

2. I didn't see a custom flash_mender.xml specifically for the jetson-xavier-nx-devkit-tx2-nx, so I assumed it was the same as tegra186, but based on the tx2 nx having only 16G vs the tx2 having 32G, the num_sectors for sdmmc_user should be different, probably same as xavier-nx value, but does that mean it should use the xavier-nx custom flash as the basis instead?

I suppose I can check by seeing what is pulled in for a default jetson-xavier-nx-tx2-nx machine build..

[madisongh]

I didn't see a custom flash_mender.xml specifically for the jetson-xavier-nx-devkit-tx2-nx

We have one here.

[goetzdd]

Ok, thanks. I appear to be working a little behind in version since this is in meta-tegra-community vs meta-mender-tegra. Also working from hardknott since I needed gstreamer 18.x version. Probably random place to ask this question, but for something to be released into the wild soon, what might your recommendation for version to stand on?

[madisongh]

The overrides we used to keep in tegra-demo-distro got moved to meta-tegra-community recently, so it's no wonder you missed it. We've had to do bbappends and overrides since meta-mender-tegra is back at dunfell + L4T R32.4.3, and I'm not sure when it will get updated; they got moved to meta-tegra-community to make it easier for folks to build their own distros without directly cloning our demo distro.

As long as you've got an upgrade strategy, hardknott is probably OK. OE-Core hardknott will be unsupported soon, so if you can update to honister (which will also update you to L4T R32.6.1), and plan to update to kirkstone when it comes out, that should at least get you to a more stable branch in the not-too-distant future.

[goetzdd]

Ok, I see, also the necessity to roll my own distro might come up as well in the near future to support other arch/devices alongside the nvidia tegra. Of course the pesky change in yocto syntax is why I stayed put a couple months back as well.

From an update to R32.6.1 perspective I have some kernel changes that I'm going to be tripping over as well I think. The latest moved the kernel from 4.9.210 to 4.9.253. If I forked my own at 4.9.210 and specified a local repo:

SRC_URI_pn-linux-tegra-4.9 = "git:///$(HOME)/linux-tegra-4.9;protocol=file;name=machine;branch=oe4t-patches-l4t-r32.5"
SRCREV_machine_jetson-nano-rx = "${AUTOREV}"

Then created a number of patches, is the practice to remove the above and go back to pulling kernel from the "normal" place and my patches are applied to it, fixing patches if they break with the new? This is still a green area for me.

Thanks much for the help, and all the work on making this in the first place.

[madisongh]

For my projects, I usually just maintain a mirror of the kernel repo, create branches to add patches, then just rebase those patches on top of whatever the next upstream branch ends up being. If that's not an easy option for you, then adding the patches via a bbappend would work, too. I just find that between driver additions and CVE patches that I end up having to add, the patch count gets unwieldy over time.