How to TFTP, NFS boot TorizonCore image?

I downloaded a Torizon-core verdin imx8mm tar file.

As a guide, I am using this article Boot from a TFTP/NFS Server.

What I have done:

  • I setup DHCP, TFTP, and NFS, on Ubuntu 20.04 development host
  • I verified TFTP is working from imx8mm uboot prompt
  • I verified can load data from TFTP server into u-boot memory
  • I downloaded torizon-core-docker-evaluation-verdin-imx8mm-Tezi_5.7.0%2Bbuild.17.container.tar

wget https://artifacts.toradex.com:443/artifactory/torizoncore-oe-prod-frankfurt/dunfell-5.x.y/release/17/verdin-imx8mm/torizon/torizon-core-docker-evaluation/oedeploy/torizon-core-docker-evaluation-verdin-imx8mm-Tezi_5.7.0%2Bbuild.17.container.tar

Does dhcp.conf filename “uImage” need to be changed?

I am lost at this point. I do not understand which TorizonCore tarball file contents I should copy to /srv/tftp/ and /srv/nfs/rootfs/ folders?

Thank in advance for any tips or direction,

-Ed

Verdin iMX8MM # run bootcmd_dhcp
starting USB...
USB0:   Port not available.
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
BOOTP broadcast 1
DHCP client bound to address 192.168.10.2 (78 ms)
Using ethernet@30be0000 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uImage'.
Load address: 0x46000000
Loading: *.
TFTP error: 'File not found' (1)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 192.168.10.2 (4 ms)
Using ethernet@30be0000 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uImage'.
Load address: 0x42000000
Loading: *.
TFTP error: 'File not found' (1)
Not retrying...

Contents: /srv/tftp/

tree -L 2 /srv/tftp/
/srv/tftp/
├── boot
│   ├── boot -> .
│   ├── loader -> loader.1
│   ├── loader.1
│   └── ostree
├── boot.scr
├── hello.txt
└── ostree
    ├── boot.1 -> boot.1.1
    ├── boot.1.1
    ├── deploy
    └── repo

TorizonCore image tar ball files:

tree /srv/nfs/rootfs/
/srv/nfs/rootfs/
├── docker-compose.yml
├── docker-storage.tar.xz
├── image.json
├── imx-boot
├── LA_OPT_NXP_SW.html
├── marketing.tar
├── prepare.sh
├── toradexlinux.png
├── torizon-core-docker-verdin-imx8mm.ota.tar.zst
├── u-boot-initial-env-sd
└── wrapup.sh

I am using a verdin imx8mm

# dhcpd.conf
# https://developer.toradex.com/linux-bsp/how-to/boot/boot-from-a-tftpnfs-server/#introduction
#
#
# Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
# configuration file instead of this file.
#
# /etc/default/isc-dhcp-server
#
# Restart after config change:
# service isc-dhcp-server restart
#
# Date: 2022-09-01 09:23:38

option domain-name "colibri.net";
option domain-name-servers ns1.example.org;

default-lease-time 600;
max-lease-time 7200;

# Use this to enable / disable dynamic dns updates globally.
ddns-update-style none;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# 1) Change interface to match USB adapter interface displayed by ifconfig on Ubuntu
#    Interface name will be something like "enx000ec667e752" rather than "eth0"
# 2) Your dev board should be assigned the IP address from start of range, 192.168.10.2
subnet 192.168.10.0 netmask 255.255.255.0 {
        default-lease-time              86400;
        max-lease-time                  86400;
        option broadcast-address        192.168.10.255;
        option domain-name              "colibri.net";
        option domain-name-servers      ns1.example.org;
        option ip-forwarding            off;
        option routers                  192.168.10.1;
        option subnet-mask              255.255.255.0;
        interface                       enx000ec667e752;
        range                           192.168.10.2 192.168.10.254;
}
#MAC address dependent IP assignment, used for the colibri target device
# next-server - Set to your USB Ethenet to manual static IP
# fixed-address - The IP adress of yur board assigned in uboot
host eval {
        filename                        "uImage";
        fixed-address                   192.168.10.2;
        hardware ethernet               00:14:2D:6C:8A:A3;
        next-server                     192.168.10.1;
        option host-name                "colibri";
        option root-path                "192.168.10.1:/srv/nfs/rootfs,wsize=1024,rsize=1024,v3";
}

Hi @embeddEd ,

I just checked here internally and trying to boot TorizonCore from TFTP/NFS server isn’t something simple to achieve given that TorizonCore uses OSTree, which is a technology that handles updates to rootfs.

The article you are following is valid for our Linux BSP reference images, but not TorizonCore necessarily.

If I may ask, what is your reason in doing this? TorizonCore has a container-based approach in running applications, so it wasn’t designed with TFTP/NFS boot in mind.

Best regards,
Lucas Akira

Hi @lucas_a.tx ,

I was planning to use TFTP NFS boot to quickly switch, and experiment, with performance of TorizonCore versus TorizonCore PREEMPT_RT as well as b2qt images.

A primary motivation, was that TFTP NFS boot has saved much development time in the past. For example, switching images, modifying images, being able to compile my code inside the embedded device’s file system that physically lives on my development system host, eliminating deployment times of each build, iterative development of optimizing boot times, etc.

Thank you,

-Ed

I was planning to use TFTP NFS boot to quickly switch, and experiment, with performance of TorizonCore versus TorizonCore PREEMPT_RT as well as b2qt images.

Switching between TorizonCore and TorizonCore PREEMPT_RT should be simple enough using the built-in OTA/OSTree mechanisms to switch between the two as needed for testing. However switching to b2qt adds a bit of complication.

Maybe you can have TorizonCore and TorizonCore PREEMPT_RT on the system, switching between them with OSTree. Then if you need to boot b2qt that can be done with TFTP NFS boot.

A follow up question I have though is why are you switching between these 3 different images? Are you still evaluating which image you will eventually settle upon?

Best Regards,
Jeremias

Hi @jeremias.tx,

Yes, still evaluating images. Our main goal is to develop software and user interface using Qt for Device Creation.

I installed Qt for Device Creation Demo Image from EasyInstaller menu. After installing a HDMI adapter on Verdin Development Board carrier, I cannot get a HDMI signal.
This article Boot2Qt for Verdin imx8mm , says HDMI is not supported by boot2Qt image. It sounds like I must build boot2qt image myself using yocto, or consider TorizonCore.

For Qt for Device Creation application development, is TorizonCore a solution to get started?

Thank you,

-Ed

It sounds like I must build boot2qt image myself using yocto, or consider TorizonCore.

That is correct. As the other thread you referenced said this module isn’t “officially” supported by the Boot2Qt image that Qt provides. At least not out of the box.

For Qt for Device Creation application development, is TorizonCore a solution to get started?

You can develop with Qt on TorizonCore. However it’s not the full Qt for Device Creation experience. For example the Qt Creator IDE is not compatible with TorizonCore. For an example of how to use Qt on TorizonCore we have this article as a reference: Qt C++ Application Development on Torizon Using Visual Studio Code | Toradex Developer Center

Best Regards,
Jeremias

Hi @jeremias.tx,

That is very good to know that Qt Creator IDE is not compatible with TorizonCore. I had not expected that.

Is that because Qt target app is running as a container under TorizonCore?

I had not thought about potential challenges of debugging containerized apps.

Thank you,

-Ed

Is that because Qt target app is running as a container under TorizonCore?

This is correct. TorizonCore uses this containerized workflow for building and deploying applications. QtCreator does not know how to work with such a workflow. One could possibly script QtCreator to do so. But such a workaround would not be officially supported by Qt themselves.

This is more or less the reason we created IDE extensions of our own that are capable of working with containerized workflows.

Best Regards,
Jeremias