mender l4t-r32.4.3 and test-distro

dwalkes commented 4 years ago

Hi Matt,

Atharva and I have been working on the mender dunfell r32.4.2 port this week with the goal of putting together a base image that supports mender on 32.4.2. I wondered if it would make sense to test it here on test-distro instead of using the repo tool deployment scheme used by other meta-mender-community packages. This might make it easier to demonstrate, deploy, and test support of different branches both here and in meta-tegra. I’ve started a branch at here with work in progress changes for dunfell-l4t-r32.4.2 and I’m wondering if you would be interested in ultimately bringing it in to test-distro as a follow-on to your existing zeus-mender branches.

I’ve noticed the uboot sources from nvidia used on the dunfell-l4t-r32.4.2 branch don’t include fw_printenv/setenv support. For this reason I’ve started by attempting to get jetson-tx2-cboot working on core-image-base. Build succeeds but tegraflash isn't working yet, presumably because there's something wrong with the jetson tx2 cboot conf and the partition setup you've got in test-distro which I don't understand yet.

I needed to make one change to support turning off signing support in order to build locally, see this commit.

Let me know what you think about making test-distro the supported way to test mender updates for new branches going forward and if you have any feedback on what I’ve done so far, which is rebasing everything you had in zeus-mender-l4t-r32.3.1 on test-distro over top of dunfell-l4t-r32.4.2 and putting a few hacks on top to get the build working.

Thanks for your help!

madisongh commented 4 years ago

Hi Dan,

On U-Boot in 32.4.2: it's the upstream U-Boot now, and in OE-Core they're using libubootenv to supply the fw_ utilities, rather than building them out of the U-Boot sources. It should still be workable, but the patches that you had for lock coordination and dynamically marking the boot partition for read/write access would need to be ported to the new code base.

The jetson-tx2-cboot MACHINE definition is, as you found, set up for secure boot, for testing not only the secure boot stuff in the BSP but also my code signing server and using LUKS to encrypt all the partitions with a passphrase derived from this TrustZone application. I haven't really coded it to be generalizable for other use cases; to do so would probably require more cleanup. Due to the LUKS encryption for the rootfs, it's set up for a two-stage installation process - you have to build the tegra-sysinstall image to flash the device, then do an OTA install of the real image you want to run (not via Mender, just a simple tarball install with these scripts).

I've been wondering myself what to do about test-distro... I've got too many branches going in it at this point, and I've just been testing stuff out and forgetting to merge all the good changes together again, so it's a lot messier than I'd like it to be. I've been thinking of starting fresh in a new repo with some restructuring and cleanup (and maybe some documentation)... it just hasn't been a high priority. If there's interest in turning this into a demo/reference distro, maybe I should reprioritize.

All that said, I'd be happy to have a branch with Mender + 32.4.2 support on it, here or anywhere.

kekiefer commented 4 years ago

Hey Matt,

Dan asked me to step in and help out here.

To frame this, I'll acknowledge that there's gray area in the utility of these changes, given the current nature of test-distro as just a playground, but having a setup to fixture an entire build when communicating issues is certainly useful, especially if it's the setup you're using to test meta-tegra.

Regarding the jetson-tx2-cboot machine and the signing support workarounds in 0af08ad5c28d801dd30c4c7b0b46b9e80dd183ce, is there a discussion somewhere about this? My initial take is that it might be a bit less awkward as a distro feature.

Is there a reason why the mender support is in separate branches here? I'd like to bring mender up from dunfell to master, and it seems like it would be better from a maintenance prospective to integrate (provided the support could be kept optional).

madisongh commented 4 years ago

having a setup to fixture an entire build when communicating issues is certainly useful, especially if it's the setup you're using to test meta-tegra.

Agreed, and that's mostly what I've been using test-distro for these days. But there is a range of use cases, features, and hardware variants that has grown over time, and it's gotten harder (and ever more expensive) to cover them all.

I know it would be useful, particularly for newcomers, to have an easy-to-use setup to get started with, with easy knobs for turning on additional features, some nice documentation, etc. - essentially a reference distro for meta-tegra. I'd like to have that, too, but haven't had the time and money to put that together - test-distro has mainly been for supporting my own hobby, and open-sourcing efforts related to my day job.

Maybe this is a good time for me to create a Github organization account, move meta-tegra and the other supporting repos there, and turn this into a real open-source project.

Regarding the jetson-tx2-cboot machine and the signing support workarounds in 0af08ad, is there a discussion somewhere about this? My initial take is that it might be a bit less awkward as a distro feature.

Some of it could be selectable either way, I suppose. Secure boot support itself is a machine feature. Mender artifact signing could be a distro feature, although at work I have a setup where we have unsecured devices for developers that don't require signed artifacts vs. production devices that require signed artifacts (and also have secure boot enabled). Partition encryption setup could potentially be decoupled from the secure-boot machine override, too. I just needed to test all those features together, and I have just one device that I've fused for secure boot testing, hence the overload.

Is there a reason why the mender support is in separate branches here?

The number one reason is the intrusiveness of the Mender meta layers. Just including meta-mender-core in your layer stack triggers a global inherit of mender-setup.bbclass, which makes it really really really difficult to mix Mender and non-Mender builds in a single distro. And everything else in their layers pretty much assumes you want to use Mender for everything.

I could have multiple parallel distro setups in one branch, with selection happening when you source the setup-env script. I've done that kind of thing before, and that's what I was thinking of for this. I just haven't had the time to do it.

kekiefer commented 4 years ago

at work I have a setup where we have unsecured devices for developers that don't require signed artifacts vs. production devices that require signed artifacts (and also have secure boot enabled

At a high level, how is this handled? That's what I'd like to accomplish here.

I could have multiple parallel distro setups in one branch, with selection happening when you source the setup-env script. I've done that kind of thing before, and that's what I was thinking of for this. I just haven't had the time to do it.

I've done this as well. I'll plan on taking that approach for the integration.

madisongh commented 4 years ago

At a high level, how is this handled?

I have two machine configurations that are essentially the same, but one adds secureboot to MACHINEOVERRIDES. Then all the decisions about bootloader signing and Mender artifact signing (and inclusion of the public key for verification) are made based on that override. I do enable partition encryption for both, but the developer machines use a dummy passphrase to unlock the LUKS partitions.

kekiefer commented 4 years ago

Can we move the tegra-bup-payload recipe to meta-tegra? This will be required by meta-mender-tegra, and would probably be useful for other update mechanisms as well, and I would rather not create a copy of it or have a dependency on test-distro to use an updater.

If there's no objections, please see https://github.com/madisongh/meta-tegra/pull/364

madisongh commented 4 years ago

Yeah, that's fine. There may be some other useful variants on it... see my comment over on the other PR for one. There are other types of update payloads that could be useful for other use cases, too, such as kernel-only and bootloader-only, but the combined bootloader + kernel payload is probably going to be the most frequently used for OTA updates.

madisongh commented 4 years ago

@kekiefer @dwalkes I've created new branches in meta-tegra and here for L4T R32.4.3 on a dunfell base. I'm planning on deprecating the R32.4.2-based branches at some point, since that was "developer preview" release, so it would be good to start migrating, if/when you're in a good place to do so.

kekiefer commented 4 years ago

OK, it's good timing. I've got both cboot and u-boot support working against master 32.4.3. It should be good for all machines now, just a little cleanup left. I'll be sending over pull requests to master first, and the backport for dunfell should be straightforward.

dwalkes commented 4 years ago

@madisongh @kekiefer

regarding the two distro split discussion and this comment:

The number one reason is the intrusiveness of the Mender meta layers. Just including meta-mender-core in your layer stack triggers a global inherit of mender-setup.bbclass, which makes it really really really difficult to mix Mender and non-Mender builds in a single distro. And everything else in their layers pretty much assumes you want to use Mender for everything.

@drewmoseley has some changes in progress to fix this in https://github.com/mendersoftware/meta-mender/pull/1037 and would like any feedback you have.

kekiefer commented 4 years ago

It's finally time to get this stuff merged. Last week, mendersoftware/meta-mender updated their master brach from zeus to dunfell, and created the dunfell branch. I'm now pointing to this new master in test-distro master+wip-mender, and the base is current with test-distro master (and u-boot 2020.07), and everything seems to be working.

I think what I'd like to do is keep all this support on one account, if you agree. I'd need a master branch on your remote (from mendersoftware/meta-mender-community @ zeus) to send a PRs to get that set up. This will be just ahead of what will need to be forked for dunfell, I haven't gone back to any of the tegra dunfell branches to try this yet -- we'll need to decide what L4T version to target first.

dwalkes commented 4 years ago

Thanks @kekiefer

we'll need to decide what L4T version to target first

My vote is 32.4.3 if that works for you. We should rename the issue I suppose.

madisongh commented 4 years ago

I'm now pointing to this new master in test-distro master+wip-mender, and the base is current with test-distro master (and u-boot 2020.07), and everything seems to be working.

Great.

I think what I'd like to do is keep all this support on one account, if you agree.

Sure. I've created an organization called OE4T; I'll invite you to join. We can get the new reference distro hosted there first, along with any needed forks (e.g. the meta-mender-community one - my fork is a bit of a mess), then I'll start migrating ownership of meta-tegra and the other supporting repos over to it. Sound reasonable?

And maybe we should rename the new reference distro while we're at it?

we'll need to decide what L4T version to target first.

I concur with @dwalkes - target latest and greatest first. Retrofitting on to the 32.3.1-based dunfell should then just be a synthesis of the existing zeus+32.3.1 with dunfell+32.4.3, which hopefully won't be too hard.

kekiefer commented 4 years ago

Sounds good. I'll be doing some final cleanup on the meta-mender-community fork and then get that up there.

I agree that a rename of test-distro to indicate that it's associated with meta-tegra would make sense. One reference point would be the meta-freescale-distro layer that goes with meta-freescale layer. It serves the same purpose in demonstrating machine functionality prior to customization.

dwalkes commented 4 years ago

We can get the new reference distro hosted there first, along with any needed forks (e.g. the meta-mender-community - my fork is a bit of a mess)

From my perspective it's fine to fork directly from mender repo if that's what you had in mind. If you'd rather not make this the default fork for upstream changes then I think we should probably use https://github.com/BoulderAI/meta-mender-community but we should clean that one up first in that case as it comes from my Trellis-Logic one which is probably more of a mess than yours.

madisongh commented 4 years ago

From my perspective it's fine to fork directly from mender repo if that's what you had in mind. If you'd rather not make this the default fork for upstream changes then I think we should probably use https://github.com/BoulderAI/meta-mender-community but we should clean that one up first in that case as it comes from my Trellis-Logic one which is probably more of a mess than yours.

Well, I forked mine from your Trellis-Logic fork, so there's even more entropy there. :) Let's fork the OE4T copy directly from Mender's upstream so we have a clean base to start from.

madisongh commented 4 years ago

One reference point would be the meta-freescale-distro layer that goes with meta-freescale layer. It serves the same purpose in demonstrating machine functionality prior to customization.

Sounds good, but let's not start the repo name with meta-, which would make it look like a standalone layer. Maybe something like oel4t-demo-distro or tegra-test-distro?

dwalkes commented 4 years ago

FWIW I like the combination in tegra-demo-distro because tegra is easier to find/search for/understand for people who don't work with Open Embedded acronyms and demo highlights the fact that it could be useful for things other than testing. However, I think any combinations of oel4t, tegra etc are good if you have other preferences.

kekiefer commented 4 years ago

I'm also liking tegra-demo-distro

madisongh commented 4 years ago

tegra-demo-distro works for me.

madisongh commented 4 years ago

Some more ideas to go along with the rename, to make it more user-friendly for demo purposes:

Move the OE-Core meta layer up a level under layers. This has some impact on the setup-env script, but makes the layout more uniform.
Maybe replace the bitbake and openembedded-core repos with poky. No functional difference, but one less submodule in the mix.
Directly add all of the meta-openembedded layers into the layer set at their top levels, rather than having the pseudo-layers with subsets linked in. This will add to recipe parsing time, but will make it easier for users to add packages to their builds. Same for meta-virtualization.
We could perhaps also remove the site.conf template and maybe some of the other files that are specific to my autobuilder environment. I'll have to come up with some other way to deal with that integration for my builds, but it will make the distro more generic.

dwalkes commented 4 years ago

@madisongh FWIW I'm good with any/all of the suggestions above, whatever you think is best.

@kekiefer I tried tonight and I'm not understanding the right way to get a custom distribution added on top of this, and I must be doing something wrong.

It looks like TEMPLATECONF here expects distro files under meta-testdistro/conf/template-$DISTRO. I added a symlink from there to my layer and moved bblayers.conf.sample, conf-notes.txt, local.conf.sample and site.conf.sample there. The source of setup-env referencing my machine and distro works fine but when I try the build I get

yocto@yocto:/build/jetson-distro-dan/build$ bitbake core-image-base
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/build/jetson-distro-dan/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 10326 at 2020-08-06 19:45:02.439996 ---
NOTE: Your conf/bblayers.conf has been automatically updated.
.... above line repeated 20 times
ERROR: Configuration has been re-parsed over 20 times, breaking out of the loop...
ERROR: Error parsing configuration files
Traceback (most recent call last):
  File "/build/jetson-distro-dan/repos/bitbake/lib/bb/cookerdata.py", line 287, in CookerDataBuilder.parseBaseConfiguration():
                                      "breaking out of the loop...")
    >                    raise Exception("Too deep config re-parse loop. Check locations where "
                                         "BB_INVALIDCONF is being set (ConfigParsed event handlers)")
Exception: Too deep config re-parse loop. Check locations where BB_INVALIDCONF is being set (ConfigParsed event handlers)

Is the idea that I should be adding my custom distro directly into the layers/meta-testdistro/conf directory instead of symlinking?

kekiefer commented 4 years ago

Are you trying to add a BSP layer and use one of the existing testdistro or testdistro-mender DISTROs? In this case, you would create the build directory with setup-env

. setup-env -m my-custom-machine -d testdistro

then after that you can just add your layer to the $BUILDDIR/conf/bblayers.conf

If you've got a whole new set of config files for a custom distro as well as custom bsp, you can either

create a whole new copy of the layers dir (say, to layers-custom), and also add your new layer(s) in there. Then modify layers-custom/.templateconf to point to your distro layer's template config files, then source setup-env like
```
BMETA=layers-custom . setup-env -m my-custom-machine -d my-custom-distro
```

Put your layer(s) into the existing layers dir, and override the default TEMPLATECONF

TEMPLATECONF=layers/my-custom-distro/conf . setup-env -m my-custom-machine -d my-custom-distro

If one of these second scenarios is really what you're going for, what exactly is the functionality you're trying to get out of test-distro / tegra-demo-distro?

dwalkes commented 4 years ago

Put your layer(s) into the existing layers dir, and override the default TEMPLATECONF

TEMPLATECONF=my-custom-distro/conf . setup-env -m my-custom-machine -d my-custom-distro is probably the closest to what I was looking to do. I'd want to automate the TEMPLATECONF setting but I suppose I could do so in a script linked to my custom layer.

If one of these second scenarios is really what you're going for, what exactly is the functionality you're trying to get out of test-distro / tegra-demo-distro?

The ability to easily switch between a custom distro and a distro used by the community, based on exactly the same sources for each layer, to compare behavior of any problems I see in a custom distro with the behavior of a distro shared in a common project.

So for instance, if I find a problem with mender support on one of my custom machine my custom distro, I'd like to have the ability to switch to testdistro-mender and a community based machine to verify I can reproduce the problem there, bisect with the latest tested release to find the problem, update community layers to get the testdistro-mender distro working again, then rebuild with my custom distro on top of the updated layers.

Is there a better way to achieve this objective?

madisongh commented 4 years ago

Should setup-env try looking for layers/$DISTRO/conf/distro/$DISTRO.conf first, maybe?

dwalkes commented 4 years ago

I really like the idea!

Would it make sense to just define a .templateconf in the root of a layers/meta-$DISTRO directory that would override the one in layers/.templateconf?

I've roughed something in at https://github.com/BoulderAI/test-distro/commit/ca8767c47da3cd48d7b05703d0fe450f63b34d56 which works with my current setup, although I didn't name my distro to match my layer so I'll need to fix that. Might be more verbose than needed but it took me a while to figure out all the links between .templateconf, TEMPLATECONF, build/conf/templateconf.cfg and and setup-env so some more breadcrumbs either in the script or documentation might be helpful.

dwalkes commented 4 years ago

Actually thinking more about it I think the script could source $TDROOT/.templateconf here and bomb out with a verbose error message if the TEMPLATECONF directory doesn't exist, avoid the noise if it already does exist.

kekiefer commented 4 years ago

Should setup-env try looking for layers/$DISTRO/conf/distro/$DISTRO.conf first, maybe?

and bomb out with a verbose error message if the TEMPLATECONF directory doesn't exist

Something along these lines would be great if we extend on this just a bit. As proposed, these approaches break down when a meta-layer contains more than one distro conf, which will be the case here once testdistro-mender is merged, or if the meta-layer doesn't match the name of the distro. These aren't uncommon cases.

We can probably get around this if we forgo trying to source a .templateconf file. Currently, for the help text, we list all the distro conf files found in meta-testdistro. W could do something similar and find the desired distro conf from every meta-layer, then then define TEMPLATECONF locally based on that before we run oe-init-build-env.

This would mean we would no longer use the .templateconf in $TDROOT. We could leave it there, or not.

dwalkes commented 4 years ago

We can probably get around this if we forgo trying to source a .templateconf file. Currently, for the help text, we list all the distro conf files found in meta-testdistro. W could do something similar and find the desired distro conf from every meta-layer, then then define TEMPLATECONF locally based on that before we run oe-init-build-env.

Yea I like this idea. So if $TDROOT/*/conf/template-$DISTRO exists we set that path as TEMPLATECONF and avoid the extra step of setting up .templateconf files or any dependencies on mapping distros to layer names, if it doesn't exist we verbosely complain with a message about what needs to happen. The only thing you'd want to ensure in this case was that you didn't have a distro name collision with another layer, which I expect would be unlikely.

madisongh commented 4 years ago

@kekiefer @dwalkes I made a pass through test-distro this morning and moved some more metdata into meta-tegra and meta-tegra/contrib. I also took a stab at the refactoring and layout changes I mentioned earlier, and have a repo here. It's stripped down somewhat, removing a bunch of junk from test-distro (some of which could be added back later, in a more organized/layered fashion). I also reworked the setup script to eliminate the functions I noticed were getting left in the user's environment - moving some of that work into scripts that get called from setup-env instead.

Take a look and see what you think... personally, I'd rather start with a more stripped-down base that is closer to the OE-Core/poky default setup for building a reference distro... it's possible that we could strip out even more than I have done so far. We can add some packagegroup and image recipes to make it easier to build something more like the kitchen-sink L4T image. I'm not exactly sure where the right balance is to serve the two main streams of new users that I see - those coming from a Yocto/OE background that are new to the Jetson platforms, and those using L4T/JetPack that are new to Yocto/OE - but hopefully we can come up with a manageable set of images. Ideally, that set could be carried through to any distro variants (e.g., for Mender), as well as any custom distros folks might want to build off the reference base.

dwalkes commented 4 years ago

Thanks for spending time on this @madisongh. The changes look good to me although @kekiefer is deeper into this than I am so he probably has more relevant feedback. I added one question at https://github.com/madisongh/tegra-demo-distro/commit/ddc12606c989fa6b0c23e23c23da97c875109e22#r42074979 regarding layer support plans.

I'd rather start with a more stripped-down base that is closer to the OE-Core/poky default setup for building a reference distro... it's possible that we could strip out even more than I have done so far

I agree with the approach of basically trying to match poky + minimal additional components as a base option. I like the idea of keeping the base image as simple as possible to avoid additional support burden beyond the support someone would need when they are just starting out with poky.

Ideally, that set could be carried through to any distro variants (e.g., for Mender), as well as any custom distros folks might want to build off the reference base.

For people who want to build a custom distro off the reference, would you expect the recommendation should be to copy the meta-tegrademo distro source into their own layer and modify it as desired, then remove the meta-tegrademo layer from their layer setup entirely? Or would you suggest designing meta-tegrademo such that it could/would be included in a custom distribution? It seems to me the latter option would be preferable since this would allow sharing of common recipes, packagegroups, images, etc which might not fit in meta-tegra but might be useful to be able to match up between the tegra demo build and a custom distro. Either way I think it would be nice to make this recommendation explicit.

madisongh commented 4 years ago

For people who want to build a custom distro off the reference, would you expect the recommendation should be to copy the meta-tegrademo distro source into their own layer and modify it as desired, then remove the meta-tegrademo layer from their layer setup entirely? Or would you suggest designing meta-tegrademo such that it could/would be included in a custom distribution?

I'd lean toward the former, as I think it's simpler to start with a reference and modify it as needed. The latter could be made to work, but in that case, we should pull out the meta-tegrademo layer as a separate repo, and then subject that to the yocto-check-layer compatibility tests. I know that tool has checks specifically for distro layers, but I haven't looked at what they are, so I don't know how much extra effort there would be to make that work.

As for common recipes, packagegroups, etc... my thinking was that new layers could be created for grouping interesting features together. Maybe some could start in the reference distro (or distro layer, if we really go that route), then get separated out once they're sufficiently developed. I'm open to alternatives, though.

kekiefer commented 4 years ago

This sounds good to me.

I'm going to test-drive the workflow for a new machine I'm putting together that uses a third party base-board, and then give some more feedback.

One thing that this project brings to mind was having a common place for vendors or consumers of 3rd-party base boards to share board support. For example, my little project uses an Auvidia J120 carrier. I went through the trouble of picking apart their "BSP" to determine what needed to be customized and it turns out it's only a few patches to the device tree and new pmic settings. Others might find it useful, but I don't want to host a new layer just to share support for a third party board.

madisongh commented 4 years ago

I don't want to host a new layer just to share support for a third party board

I haven't used any of the off-the-shelf third-party carriers, but I know some folks have, as this topic has come up before. I'd be OK with including support for them either as a sublayer (like contrib) in the meta-tegra repo, or even as part of the main BSP layer itself, provided someone signs up to be responsible for maintaining them.

kekiefer commented 4 years ago

That's a good point about the contrib directory -- it's probably the right place if we're just talking about one or two third party boards, short of a critical mass for some kind of meta-tegra-community layer.

Anyhow, getting a new distro layer put together was pretty painless. Here is what I did, using the whole meta-tegrademo directory as a template:

git clone https://github.com/madisongh/tegra-demo-distro
cd tegra-demo-distro
git submodule update --init

# Create meta-mylayer/mylayer distro based on meta-tegrademo/tegrademo distro
cp -a layers/meta-tegrademo layers/meta-mylayer
mv meta-mylayer/conf/template-tegrademo meta-mylayer/conf/template-mylayer
mv layers/meta-mylayer/classes/tegrademo-sanity.bbclass layers/meta-mylayer/classes/mylayer-sanity.bbclass
find layers/meta-mylayer -type f -exec sed -i 's/tegrademo/mylayer/' {} \;

# Customize new distro configuration:
# edit layers/meta-mylayer/conf/distro/mylayer.conf 
#     set DISTRO* variables at top
#     any other customizations

# Add any additional layers:
git submodule add https://github.com/other/meta-otherlayer repos/meta-otherlayer
ln -rs repos/meta-otherlayer layers/
# edit layers/meta-mylayer/conf/template-mylayer/bblayers.conf.sample

. setup-env -m jetson-tx2 -d mylayer build-mylayer

The changes you made to select the templateconf based on the distro selection worked out well. The custom sanity checks translate OK to the new layer (these can be a bit confusing if you don't know they are there), but this worked itself out with the sed replacements and name changes.

The insertion of MACHINE and DISTRO right at the top of the local.conf instead of replacing them inline looked a little funny to me, was this the intention?

madisongh commented 4 years ago

Great.

The insertion of MACHINE and DISTRO right at the top of the local.conf instead of replacing them inline looked a little funny to me, was this the intention?

Yeah, although I admit it does look a bit funny. I thought it would be good to have them right up front, easy to find. The sample config file has so much stuff in it, I didn't want those settings to get buried. Of course, you lose out on having the settings reside with the relevant comments.

kekiefer commented 4 years ago

Maybe reducing some of the comment-description around these variables in the local.conf.sample would make sense, since they're pretty self explanatory. The first thing I did was open up that local.conf and "fix" that.

One tweak occurred to me that might strike a balance between "recommendations a and b" of keeping or throwing away the meta-tegrademo layer when customizing. If we split meta-tegrademo in two parts, something like meta-tegrademo and meta-tegra-support (or something, for the sed trick to work might not include the 'tegrademo' name exactly), the first part could simply be the templateconf and distro conf, and that could be copied into a new custom layer (like I did) without making wholesale copies of recipes that may or may not be useful. The second part would have all the bbappends that were useful in meta-tegrademo, and users could choose to leverage them or not. If they did want them, they could benefit from being able to merge in changes to those recipes from upstream.

madisongh commented 4 years ago

If we split meta-tegrademo in two parts, something like meta-tegrademo and meta-tegra-support ...

Great idea. I'll add that and see how it works out.

kekiefer commented 4 years ago

Heads-up that I created the meta-mender-tegra dunfell branch, and I created a master-next branch based on this, to stay in line with the way that mender manages their branching. If no one objects, I'll delete the master branch (IMO, it's a little unfair to users if we're having to continually rebase a branch with a name like that) and make either master-next or dunfell the default.

The dunfell branch will build against meta-mender as soon as https://github.com/mendersoftware/meta-mender/pull/1086 is merged. OE dunfell picked up libubootenv v0.3... in the middle of a release... But at least now what we've got on dunfell is almost exactly the same to what we've got on master, just a u-boot patch refresh for master.

I'll hold off on any PR for a tegra mender distro until @madisongh has some time to split up meta-tegrademo, then it should be a pretty straightforward PR to send over the mender support to that -- I have it pretty much worked out from my test a few days ago.

madisongh commented 4 years ago

@kekiefer I've implemented the split-out of meta-tegra-support, which has the bbappends and common recipes. I added packagegroup and image recipes to meta-tegrademo for now - I may move at least the packagegroup recipes to the support layer instead, since I would expect those to be more shareable. Image recipes could maybe go either way, but I wanted there to be at least some recipes in the distro layer.

Next I'll work on updating the submodules to latest, creating a dunfell branch for tracking the corresponding upstream layers, and migrating the repo to the OE4T organization. Probably won't get to all that until tomorrow, but hopefully what's there now is enough for you to do your testing.

madisongh commented 4 years ago

OK, I've completed the latest tasks, and fixed a few bugs in the setup script that I found while I was testing things out.

The new repo is here. I squashed all of the commits and fixups together into a single initial commit, just to clean things up, and created a dunfell-l4t-r32.4.3 branch. I haven't tested builds for all machines yet, so there may still be some issues to sort out. I will set up some automated builds this week to verify everything.

kekiefer commented 3 years ago

tegrademo-mender is merged into master. I've got a working dunfell-l4t-r32.4.3 setup, pending https://github.com/mendersoftware/meta-mender-community/pull/172 acceptance upstream

madisongh commented 3 years ago

@kekiefer Is it OK to close this issue now?

kekiefer commented 3 years ago

Fine with me

madisongh / test-distro

mender l4t-r32.4.3 and test-distro #5