Problem: Trying to install clean Debian on IOT2050

Hi! I am wondering if there is something fundamental about the IOT2050 that makes it impossible to install a clean Debinan netinst image, or if I have done something wrong when following the setup guides.

I am used to the SIMATIC IPC127E units, which we can boot from USB and install Debian on without any hurdles.

I have tried to do the same for the IOT2050, but I never get to boot from the image. I am doing the following:
- Download the official arm64 netinst image from Debian
- Add the image to a basic Kingston USB drive using Rufus.
- For the IPC127E I could simply boot it up with this stick, and choose "boot from file" to choose the USB.
- However, the IOT2050 has a pre-installed Siemens OS which does not give the option for booting from another device, so I followed section 3.2.3 in the IOT2050 setting up guide, using an UART cable to enter the U-boot and manually setting the boot unit order.

When trying to boot up the Debian install image, I get the error message listed below.

Would be happy for any comments here. I am especially curious if I have misunderstood something basic about the IOT2050 hardware that makes it hard to install Debian, or if this is related to some other error I made.

=> run bootcmd_usb0

Device 0: Vendor: Kingston Rev: 0000 Prod: DataTraveler 3.0
Type: Removable Hard Disk
Capacity: 29560.0 MB = 28.8 GB (60538881 x 512)
... is now current device
Scanning usb 0:1...
** Unable to read file / **
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk sdhci@4f80000.blk...
Scanning disk sdhci@04FA0000.blk...
Disk sdhci@04FA0000.blk not ready
Scanning disk usb_mass_storage.lun0...
Found 4 disks
856064 bytes read in 45 ms (18.1 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 80080000 ...
Could not get variable storage info: Unsupported
Could not create MokListRT: Unsupported
Could not get variable storage info: Unsupported
Could not create MokListXRT: Unsupported
Could not get variable storage info: Unsupported
Could not create MokListRT: Unsupported
Could not get variable storage info: Unsupported
Could not create MokListXRT: Unsupported
Something has gone seriously wrong: import_mok_state() failed: Unsupported

I see, thank you. Could you explain why it is necessary to go the route via the example images?

And if so - can we make an example image with the basic Debian netinst as the starting point?

You may notice that I don't understand exactly what an example image is. So appreciate any extra effort you need to use to express this in layman's terms.

To give some context: The main reason we are looking into a clean Debian install, is because we are seeing low-level equipment errors and failures using the IOT2050, which does not happen when we use the IPC127. These are things like not being able to install working drivers for USB-to-CANbus adapters, various faults when controlling microcontrollers via USB, and similar.

I thought these faults could be related to the IOT2050 image basis not being based on the most recent Linux kernel or something along those lines, or other pre-installed software might interfere. Having a clean Debian install would remove any potential problems related to the custom Siemens Industrial OS.

On a sidenote, having a clean Debian install also makes it easier to automate the entire setup process, which would then be more equal between the different Linux machines we have.

We do share your vision of full upstream support, which is why we are working together with our supplier(s) on that.

You already find basic support for the IOT2050 variants in the latest mainline kernel, which will mean that basic things will start to work from bookworm onward. Well, Ethernet won't because we are still waiting for TI to finish related driver upstreaming. And that means that your envisioned netinst will unfortunately not work with vanilla Debian in the foreseeable future.

That's where the meta-iot2050 example image - or BSP layer for Debian - comes into play. It closes the gaps we can't fill yet otherwise, adds some packages that could be useful (e.g. mraa, UART mode control, Coral support with tflite & friends) and also optionally (i.e. if self-built) performs more complex pre-integrations like secure boot and A/B image-based OTA updates. You can even put your own customization layer on top, pick from the base layer what you need and leave out the rest.

That image and ad-hoc package generator Isar is not specific to the IOT2050. You can find it in other use cases already, specifically to address reproducibilites in combination with embedded customizations. For simpler problems, there are simpler solutions than Isar, but I haven't seen anything slimmer for complex ones.

Nevertheless, we are always trying to remain as close to Debian as possible with meta-iot2050. That's why are working on TensorFlow for Debian, patch or even maintain some packages related to OTA update (SWUpdate, EFI Boot Guard) and hope to use them as-is from later Debian releases.

Hope that answers your conceptual questions. Feel free to follow up if not.

Regarding the concrete technical issues you saw, please follow up in one or more separate threads on those, providing more details on the involved hardware, what software you want to install, where drivers came from (upstream backports or vendor packages) and how to potentially reproduce (steps taken for the installation).

In general, the purpose of a Linux board support package is

A) to bridge the time between hardware availability, mainline integration of required changes/extensions and sometimes also adoption of those changes by distributions and

B) to act as a show case / reference / template for complex integrations beyond the kernel.

The first purpose should be temporarily by nature, the second may have good reasons to stay.

For the IOT2050, both purposes still apply. The first one primarily because of the SoC. The second one because of some packages not yet being available in Debian (Coral, TensorFlow) or because of complex integrations like secure boot that are not yet as simple to configure as on x86 (work in progress).

x86 targets and, thus, also the IPC127E are often faster supported by upstream because the delta for new generations is often smaller and the suppliers there are faster with upstreaming (with unfortunate exceptions). But you may be in a need for a support package there as well. Example: When the IPC227G was released, existing distro releases did not support all or even any of its network interfaces. Luckily, we managed to fix that for Debian 11 which happened to appear in the same time frame, other distributions took longer.

We are discussing such issues regularly with our suppliers to continue improving the situation, for our customers on Linux as well as for our own integrations.