Ubuntu Core on the i.MX 8M platform

We have a need to bring up Ubuntu Core 18 (and 20 in future) on the i.MX 8M platform. We don’t have a specific board selected yet, however we wanted to know if there has been any work done to run Ubuntu Core on that platform ? If yes, then any pointers towards that would be very welcome.

The other boards that we will be working on are:

  • Raspberry Pi 3 (Already has Ubuntu Core)
  • Jetson Xavier (Much of the hard work already done by @abeato, thanks).
3 Likes

Hi Omer, nice to see you here! I believe we have a project in discussion that is i.MX8 but I am not sure which flavour.

2 Likes

This sounds great! i.MX8 support in general in Ubuntu Core would be awesome. It’s a whole family of SoCs and boards obviously.

Eg this one seems just perfect for a lot of things

https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
https://developer.toradex.com/products/verdin-imx8m-mini

so what we are trying is apparmor+snapd on Yocto for above, plus “roll your own” app/update thing - but I’m not keen on the latter, also not convinced.

and we want to compare that with a fully snapped system, Ubuntu Core + Canonical public/brand store …

1 Like

Adding snapd to Yocto is a nice way to get access to the app update mechanism. As long as you have a current kernel and apparmor you should be fine. We’re moving the apparmor dep[endencies into the snapd snap itself so in future really the only dependency will be the kernel, and we’ll auto-adapt to the kernel you have (more security with newer kernels).

1 Like

yeah, absolutey, yocto+snapd is quite attractive, because yocto has this broad industry BSP support, and snapd just solves all app level questions for such devices.

fwiw, I think this distro-independence and minimalism is a great strategy for snapd and the snap ecosystem, and I’m convinced, more and more developers will recognize the unique advantages and completeness of snaps over time. thanks for snaps!! =)

I think apparmor only has 3 patches not yet upstreamed (which is awesome of course!). however, yocto has a supported layer http://layers.openembedded.org/layerindex/recipe/60225/ which seems to work … not yet at snapd … will see

2 Likes

Hi Omer,

Glad to see you bring this up, because we will be enabling i.MX 8M mini on Ubuntu Core 20 soon. We may support other i.MX 8M too but can’t say for sure yet. At this moment, I don’t have anything to share as that’s still work in progress, but I’ll post it here once we get something for you, please stay tuned.

-Anthony

2 Likes

Great to know that.

Does that mean there will be official Ubuntu Core 20 images for i.MX 8M mini available or is that general enablement work and that we’ll have to build images ourselves ?

It will start with general enablement work first, including the kernel, bootloader, and the kernel and gadget snaps. We also want to create an image for a reference platform for the SoC in the future, but due to different board designs, you may have to create your own gadget snap and build the image yourself for the board you use.

Thanks for these infos! +1 on supporting i.MX8 in Ubuntu Core out of the box.

What you mention rgd kernel vs gadget snap, SoM and carrier board support etc, let me ask as I would like to understand how this is supposed to work in Ubuntu Core in general.

Let’s start with the concrete SoC you mention, the

https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-mini-arm-cortex-a53-cortex-m4-audio-voice-video:i.MX8MMINI

This already is a SoC, so has a whole bunch of peripherals built in. Eg GPU or USB2 or RNG. The (kernel) drivers for these would be part of the kernel snap, right?

Then let’s put that SoC on a concrete SoM, such as https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano which brings additional peripherals, such as eMMC, RAM and Wifi/BLE. The (kernel) drivers for these, would that be part of the kernel snap or a gadget snap?

Now, say I put that SoM onto a concrete carrier board such as https://developer.toradex.com/products/dahlia-carrier-board which brings additional peripherals, such as audio codec and CAN. The (kernel) drivers for these, would that be part of the kernel snap or a gadget snap?

So it might be that we can reuse the kernel snap from Canonical for 1), but would need to combine that with our own gadget snap for 2) + 3) to bake a complete device image?

Thanks a lot!

Cheers,
/Tobias

all your examples kind of explain themselves :wink:

if you write “kernel (drivers)” above that is pretty clearly something that has to be shipped by the kernel …

gadgets are a hardware description package, they ship bootloaders, set the partitioning scheme, describe what device trees and device tree overlay fragments to load and set up the required default configuration of the shipped software.

a SOM kernel would ship all drivers possible but the gadget would tell it what combination of device trees and overlays need to be loaded to run on the specific SOM/baseboard combination.

if your bootloader can be generic enough and can detect the actual hardware combination, there can be one gadget that runs on multiple combos (see the generic raspberry pi gadget where we do exactly this to boot all variations of pi2 to pi4) and loads the required dtb’s dynamically during boot …

if the bootloader was not designed in this scope by the vendor (often the bootloader code (i.e. u-boot patches) shipped in a BSP are precisely designed just for one specific combo of SOW and board) you will need one gadget per combination though …

1 Like

Thanks a lot for clarifying this! Now the kernel/gadget distinction makes sense.

if your bootloader can be generic enough …

aahh, right, I see. I have to dive into / read more to understand what’s actually involved in making a boot loader aware of multiple targets to auto-select the right dtb and so on. I’ll look at the RPi gadget snaps, thanks for that hint!