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:
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.
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 …
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).
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
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
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
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 
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 …
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!
Hi everyone. My company asked me if I can build Ubuntu Core for the i.MX8 Mini board, from BoundaryDevices.
I’ve successfully compiled Ubuntu Core 16 image for my variant of the board. It is booting sucessfully and detecting the Ethernet, etc.
I’ve compiled the kernel, and the gadget snap all from source.
The only problem I face, is the fact that USB-serial chipsets is detected on the USB port (usbutils-lool), but no kernel module for them is loaded, neither them populating in the /dev/ directory.
My company is requiring serial port access on this, they have a few devices relying on serial ports that they need to interface with the software built snap they have.
Maybe some of you might be able to diagnose the problem, and come up with a fix?
@ogra, I compiled the kernel from BoundaryDevices, they have a kernel source we can maybe use for building Ubuntu Core for the i.MX8 board variants?
(gadget and kernel snapcraft.yaml files on the way soon, need to do cleanup on it. Github repo to follow.)
-Ruhan
After digging a bit, I also found this kernel source
http://git.toradex.com/cgit/linux-toradex.git/tree/?h=toradex_5.4-2.1.x-imx
Like oberstet mentioned this board.
Seems like someone can also build a kernel from this source for the board in question.
did you check you are also including all required firmware in your kernel ? perhaps something is missing, check your BSP … beyond this i’d suspect some missing kernel config …
if you own a brand store you can indeed maintain your own device kernel yourself … if you want a canonical maintained kernel, there are device enablement packages at https://ubuntu.com/pricing/devices …
Here is my kernel snapcraft.yaml:
name: nitrogen8m-mini-kernel
version: 5.4
summary: A Nitrogen8M-Mini kernel built from source
description: This provides a kernel snap for Boundary Devices’ Nitrogen8M-Mini board
type: kernel
architectures:
- build-on: [ amd64 ]
run-on: arm64
confinement: strict
parts:
kernel:
plugin: kernel
source: https://github.com/boundarydevices/linux-imx6.git
source-branch: boundary-imx_5.4.x_2.2.0
source-type: git
kdefconfig: [boundary_defconfig]
kconfigs:
- CONFIG_EXT4_FS=y
- CONFIG_BLK_DEV_LOOP=y
- CONFIG_BLK_DEV_LOOP_MIN_COUNT=256
- CONFIG_SQUASHFS=m
- CONFIG_ENCRYPTED_KEYS=y
- CONFIG_SQUASHFS_XATTR=y
- CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
- CONFIG_BLK_DEV_BSG=y
- CONFIG_USB_SERIAL=m
- CONFIG_USB_SERIAL_GENERIC=y
- CONFIG_USB_SERIAL_AIRPRIME=y
- CONFIG_USB_SERIAL_ANYDATA=y
- CONFIG_USB_SERIAL_BELKIN=y
- CONFIG_USB_SERIAL_CP2101=y
- CONFIG_USB_SERIAL_CYPRESS_M8=y
- CONFIG_USB_SERIAL_MCT_U232=y
- CONFIG_USB_SERIAL_PL2303=y
- CONFIG_USB_SERIAL_FTDI_SIO=y
prepare: |
#export KERNEL_SRC=pwd
#export INSTALL_MOD_PATH=$KERNEL_SRC/ubuntunize64/linux-staging
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
#echo “Building Ubuntunize…”
#make -C ubuntunize64 prerequisites
echo “Building kernel…(Going to take a LONG time)”
make boundary_defconfig
kernel-initrd-modules:
- squashfs
- usbserial
kernel-image-target: Image
build-packages: [debootstrap, lsb-release, lzop, cpio, kmod, bc]
kernel-with-firmware: False
Please forgive the bloat, I was compiling this over and over again with different experiments, to no avail.
I’m not aware of any firmware that needs to be included?
Should I try to build again with ‘kernel-with-firmware: True’?
My company already has a brand store AFAIK, so this is just to see if we can get everything working before fully committing to maintain the kernel and gadget snap.
Hi guys, just an update, I will try to compile an older kernel, maybe it has something to do with 5.2.
I suspect something does not play nice with 5.2, and still being updated by the guys at Boundary (not stable yet?)
Will try to compile a stable kernel. 4.x
Hi,
FYI we updated our ubuntu-core repo so that it works on all our i.MX 8M* platforms (8MQ, 8M Mini, 8M Nano & 8M Plus): https://github.com/boundarydevices/ubuntu-core/tree/18-arm64
We will publish an article about it soon, with prebuilt images for both armhf and arm64 for all our platforms. Ping me if you need such image.
Note that UC20 wouldn’t boot, but according to the doc it’s still in “active development” which so far meant “doesn’t boot”
Also, our snaps have been updated in the store in case you want to create your own image, simply use nitrogen-gadget and nitrogen-kernel snaps.
Anyway, let us know if you try it on one of our platforms.
Cheers, Gary
Hi Gary,
Glad to hear that you are officially supporting Ubuntu Core out of the box for the iMX8 series chips from Boundary.
I have previously compiled from sources the gadget snap and kernel snap for the iMX8M-Mini.
What you can do, is to add the slots in the gadget snap, for other snaps to have access to hardware, like i2c, serial ports, etc.
I was struggling to get the WiFi working, is it working on your boards?
BR
Hi,
Yes I confirm that WiFi is working for all our i.MX8M platforms:
gbisson@localhost:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether no-carrier configuring
3 can0 n/a off unmanaged
4 wlan0 wlan routable configured
5 p2p0 wlan off unmanaged
You can download this prebuilt image if you want to give it a shot:
https://boundarydevices.com/eula/?file=ubuntu-core18-arm64-nitrogen-stable-20201231.img.gz
As for slots, thanks for the heads up as I wasn’t aware of it. Do you know what happens if I declare a slot that doesn’t exist on the platform? Reason i’m asking is that I want that nitrogen image to work on all our Nitrogen8 platforms, they don’t all expose the same number of i2c nodes nor the same serial ports necessarily.
Finally, last question: has anyone successfully ran Mir (kiosk) on Vivante blobs?
Regards,
Gary
