Issue Running Network Application on Genode OS on i.MX8MP ARMSTONE Development Board

Dear Genode Community :waving_hand: ,

We are currently developing a network server application based on Genode OS, with the goal of running it on an i.MX8MP ARMSTONE development board. To test the network connectivity of the board, we wrote a simple program that connects to a website using a socket. Our objective is to retrieve the content of the website, and even a 404 error or a TLS handshake failure would be sufficient to confirm that the network communication is working. Unfortunately, we are unable to successfully run the program on the development board :cry: .

Here are the key points from our diagnostics:

  • The test program runs fine on both x86 and aarch64 platforms in QEMU, suggesting that the application layer implementation is most likely not the issue.

  • When the development board runs a standard Linux distribution, it can access the internet without any problems, indicating that the network environment is fine.

  • The networking issue only occurs when the board is running Genode OS.

Possible Causes and Observations

We suspect that Genode is logging a problem related to the loading of platform-specific device drivers. Specifically, we observed the following errors in the runtime log, which we believe could be the core issue:

[init -> drivers -> nic] --- i.MX FEC nic driver started ---
[init -> drivers -> platform] Error: ROM-session creation failed (label="system", ram_quota=6K, cap_quota=3, )
[init -> drivers -> platform] Error: could not open ROM session for "system"
[init -> drivers -> platform] Error: Uncaught exception of type 'Genode::Rom_connection::Rom_connection_failed'

Despite attempting to adjust the cap and RAM quotas in the run file, the core error message remains unchanged.

Version and Migration Attempts

  1. We noticed that this error only occurs when the image is compiled with Genode 25.02. We tried migrating to Genode 25.05 to avoid this issue, but found that lwIP does not run properly in the QEMU-simulated aarch64 environment. Therefore, we reverted to Genode 25.02, where lwIP works correctly. We believe this is a bug in Genode 25.05, and we will describe this issue in more detail on GitHub and include a link to help improve the Genode project.

  2. We are also unsure whether the issue with running Genode on the i.MX8MP development board is specific to this model, or if all boards in the i.MX8MP series require the loading of network drivers to function correctly. When compiling the i.MX8MP uImage image, we couldn’t directly compile it using the BOARD ?= imx8mp_armstone setting in the build.conf file. By emulating the drivers_nic-imx6q_sabrelite approach, we added drivers_nic_imx8mp_armstone to the recipe/pkg folder in the imx repository, and successfully compiled an image that could run on the board, but the network still does not behave correctly. We suspect this could be another root cause of the issue.

Further Information

If you’re interested in this issue and need more information, we have attached the simplified test program, corresponding run script, the complete Genode output log from the i.MX8MP development board and our board picture for further analysis.

myapp.cc
#include <base/component.h>
#include <libc/component.h>
#include <base/heap.h>
#include <base/attached_rom_dataspace.h>

#include <unistd.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <arpa/inet.h>
#include <sys/stat.h>
#include <sys/select.h>
#include <netinet/in.h>
#include <netinet/in.h>
#include <fcntl.h>

struct AppMain {

    Genode::Env& env;
    Genode::Heap heap { env.ram(), env.rm() };

    AppMain(Genode::Env&);

};


AppMain::AppMain(Genode::Env& env) : env {env} {

    Genode::Attached_rom_dataspace configDs { env, "drivers.config" };

    Genode::log("------ drivers.config ------");
    Genode::log(configDs.xml());

    Libc::with_libc([&] () {

        auto fd = socket(AF_INET, SOCK_STREAM, 0);
        if (fd == -1) {
            perror("socket");
            return;
        }

        
        {
            struct sockaddr_in addr;
            addr.sin_family = AF_INET;
            addr.sin_port = adl::htons(443);
            inet_pton(AF_INET, "202.120.189.175", &addr.sin_addr);

            if (connect(fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
                perror("connect");
                close(fd);
                return;
            }
        }

        char buf[1024] = "";

        const char* http_get = "GET / HTTP/1.1\r\nHost: 202.120.189.175\r\nConnection: close\r\n\r\n";
        send(fd, http_get, adl::strlen(http_get), 0);
        int n = recv(fd, buf, sizeof(buf)-1, 0);
        if (n > 0) {
            buf[n] = 0;
            printf("Received %d bytes:\n%s\n", n, buf);
        } else {
            if (n == 0) {
                printf("Connection closed by peer\n");
            } else {
                perror("recv");
            }
        }
        close(fd);
        Genode::log((const char*)buf);

        return ;
    });
}



void Libc::Component::construct(Libc::Env& env) {
    static AppMain main {env};
}

myapp.run


#
# Build
#

create_boot_directory

import_from_depot [depot_user]/src/[base_src] \
                  [depot_user]/pkg/[drivers_nic_pkg] \
                  [depot_user]/src/init \
                  [depot_user]/src/libc \
                  [depot_user]/src/nic_router \
                  [depot_user]/src/vfs \
                  [depot_user]/src/vfs_lwip \
                  [depot_user]/src/vfs_pipe \
                  [depot_user]/raw/[board]-devices


build {
    core init timer app/myapp

	driver/platform/imx8mq
}

#
# Generate config
#


install_config {

<config verbose="yes" prio_levels="4">

    <default-route>
        <any-service> <parent/> <any-child/> </any-service>
    </default-route>

    <parent-provides>
        <service name="LOG"/>
        <service name="PD"/>
        <service name="CPU"/>
        <service name="ROM"/>
        <service name="IRQ"/>
		<service name="RM"/>
		<service name="IO_MEM"/>
        <service name="IO_PORT"/>
    </parent-provides>

    <default caps="200"/>


    <start name="timer" priority="0">
        
        <resource name="RAM" quantum="2M"/>
        <provides> <service name="Timer"/> </provides>
    </start>


    <start name="drivers" caps="1200" managing_system="yes" priority="0">
        
        <resource name="RAM" quantum="512M"/>
        <binary name="init"/>
        <route>
            <service name="ROM" label="config"> <parent label="drivers.config"/> </service>
            <service name="Timer"> <child name="timer"/> </service>
            <service name="Uplink"> <child name="nic_router"/> </service>
            <any-service> <parent/> </any-service>
        </route>
    </start>

    <start name="nic_router" caps="4000" priority="-1">
        
        <resource name="RAM" quantum="128M"/>
        <provides>
            <service name="Nic"/>
            <service name="Uplink"/>
        </provides>
        
        <config verbose_domain_state="yes" verbose_packet_drop="yes" trace_packets="yes" >


            <policy label_prefix="myapp" domain="downlink"/>
            <policy label_prefix="drivers" domain="uplink"/>

            <!-- <domain name="uplink"> -->
            <domain name="uplink" interface="192.168.1.101/24" gateway="192.168.1.1">
            <!-- <domain name="uplink" interface="10.0.2.15/24" gateway="10.0.2.2"> -->

                <nat domain="downlink"
                     tcp-ports="16384"
                     udp-ports="16384"
                     icmp-ids="16384"/>

				<tcp-forward port="10000" domain="downlink" to="10.0.3.2"/>

            </domain>


			<domain name="downlink" interface="10.0.3.1/24">

                <dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2">
                    <dns-server ip="8.8.8.8"/>
                    <dns-server ip="1.1.1.1"/>
                </dhcp-server>

                <tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
                <udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>
                <icmp dst="0.0.0.0/0" domain="uplink"/>

            </domain>

        </config>
    </start>



    <start name="myapp" caps="2000" priority="-2">
        
        <resource name="RAM" quantum="256M"/>

        <config>
            <vfs>
                <dir name="dev"> <log/> </dir>
                <dir name="socket"> <lwip ip_addr="10.0.3.2" netmask="255.255.255.0" gateway="10.0.3.1"/> </dir>
                <!-- <dir name="socket"> <lwip dhcp="yes"/> </dir> -->
                <dir name="pipe"> <pipe/> </dir>
            </vfs>
            <libc stdout="/dev/log" socket="/socket" pipe="/pipe"/>

        </config>

        <route>
            <service name="Nic"> <child name="nic_router"/> </service>
            <any-service> <parent/> <any-child/> </any-service>
        </route>
    </start>


</config>

}





#
# Boot image
#


build_boot_image [build_artifacts]

append qemu_args " -nographic "
append_qemu_nic_args "hostfwd=tcp:127.0.0.1:5555-:10000"

run_genode_until forever

genode-output-from-imx_board.log
forlinx=>  0x40000000 OK8MP-C.<INTERRUPT>
forlinx=> <INTERRUPT>
forlinx=> fatload mmc 1 0x40000000 OK8MP-C.dtb && fatload mmc 1 0x40800000 con && bootm 0x40800000 - 0x40000000
67264 bytes read in 24 ms (2.7 MiB/s)
3135728 bytes read in 158 ms (18.9 MiB/s)
## Booting kernel from Legacy Image at 40800000 ...
   Image Name:
   Image Type:   AArch64 Linux Kernel Image (gzip compressed)
   Data Size:    3135664 Bytes = 3 MiB
   Load Address: 40200000
   Entry Point:  40200000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 40000000
   Booting using the fdt blob at 0x40000000
   Uncompressing Kernel Image
   Using Device Tree in place at 0000000040000000, end 00000000400136bf

Starting kernel ...


kernel initialized
Genode 25.02-2-g6458c1bcf9 <local changes>
2037 MiB RAM and 64536 caps assigned to init
[init] parent provides
[init]   service "LOG"
[init]   service "PD"
[init]   service "CPU"
[init]   service "ROM"
[init]   service "IRQ"
[init]   service "RM"
[init]   service "IO_MEM"
[init]   service "IO_PORT"
[init] child "timer"
[init]   RAM quota:  1800K
[init]   cap quota:  166
[init]   ELF binary: timer
[init]   priority:   0
[init]   provides service Timer
[init] child "drivers"
[init]   RAM quota:  524040K
[init]   cap quota:  1166
[init]   ELF binary: init
[init]   priority:   0
[init] child "nic_router"
[init]   RAM quota:  130824K
[init]   cap quota:  3966
[init]   ELF binary: nic_router
[init]   priority:   1
[init]   provides service Nic
[init]   provides service Uplink
[init] child "myapp"
[init]   RAM quota:  261896K
[init]   cap quota:  1966
[init]   ELF binary: myapp
[init]   priority:   2
[init -> drivers -> nic] --- i.MX FEC nic driver started ---
[init -> drivers -> platform] Error: ROM-session creation failed (label="system", ram_quota=6K, cap_quota=3, )
[init -> drivers -> platform] Error: could not open ROM session for "system"
[init -> drivers -> platform] Error: Uncaught exception of type 'Genode::Rom_connection::Rom_connection_failed'
[init -> drivers -> platform] Warning: abort called - thread: ep
[init] child "timer" announces service "Timer"
[init -> nic_router] [uplink] static IP config: interface 192.168.1.101/24, gateway 192.168.1.1, P2P 0
[init -> nic_router] [uplink] NIC sessions: 0
[init -> nic_router] [downlink] static IP config: interface 10.0.3.1/24, gateway 0.0.0.0, P2P 0
[init -> nic_router] [downlink] NIC sessions: 0
[init] child "nic_router" announces service "Nic"
[init] child "nic_router" announces service "Uplink"
[init -> nic_router] [downlink] NIC sessions: 1
[init -> myapp] lwIP Nic interface down
[init -> myapp] lwIP Nic interface up address=10.0.3.2 netmask=0.0.0.0 gateway=0.0.0.0
[init -> myapp] ------ drivers.config ------
[init -> myapp] <config>
[init -> myapp]      <parent-provides>
[init -> myapp]              <service name="IRQ"/>
[init -> myapp]              <service name="IO_MEM"/>
[init -> myapp]              <service name="ROM"/>
[init -> myapp]              <service name="PD"/>
[init -> myapp]              <service name="RM"/>
[init -> myapp]              <service name="CPU"/>
[init -> myapp]              <service name="LOG"/>
[init -> myapp]              <service name="Timer"/>
[init -> myapp]              <service name="Uplink"/>
[init -> nic_router] [downlink] drop packet (gratuitous ARP request)
[init -> myapp]      </parent-provides>
[init -> myapp]
[init -> myapp]      <default caps="100"/>
[init -> myapp]
[init -> myapp]      <service name="Nic">
[init -> myapp]              <default-policy> <child name="nic"/> </default-policy> </service>
[init -> myapp]
[init -> myapp]      <start name="platform" caps="150" ram="1M" managing_system="yes">
[init -> myapp]              <binary name="imx8mp_platform"/>
[init -> myapp]              <provides> <service name="Platform"/> </provides>
[init -> myapp]              <config>
[init -> myapp]                      <policy label="nic -> " info="yes"> <device name="fec"/> </policy>
[init -> myapp]              </config>
[init -> myapp]              <route> <any-service> <parent/> </any-service> </route>
[init -> myapp]      </start>
[init -> myapp]
[init -> myapp]      <start name="nic" caps="180" ram="20M">
[init -> myapp]              <binary name="fec_nic"/>
[init -> myapp]              <route>
[init -> myapp]                      <service name="ROM" label="nic.dtb"> <parent label="fec_nic-imx8mp_armstone.dtb"/> </service>
[init -> myapp]                      <service name="Uplink"><parent/> </service>
[init -> myapp]                      <service name="ROM">   <parent/> </service>
[init -> myapp]                      <service name="PD">    <parent/> </service>
[init -> myapp]                      <service name="RM">    <parent/> </service>
[init -> myapp]                      <service name="CPU">   <parent/> </service>
[init -> myapp]                      <service name="LOG">   <parent/> </service>
[init -> myapp]                      <service name="Timer"> <parent/> </service>
[init -> myapp]                      <service name="Platform"> <child name="platform"/> </service>
[init -> myapp]              </route>
[init -> myapp]      </start>
[init -> myapp] </config>
[init -> nic_router] [downlink] drop packet (gratuitous ARP request)
[init -> nic_router] [downlink] drop packet (DHCP request with broken message type)

our imx board picture — OKMX8MP-C v2.1

We are also reviewing every commit between Genode 25.02 and 25.05 to determine the root cause of the issue. However, we believe that the Genode community might be more familiar with the version upgrade process and could offer more direct help. Any discussion or suggestions would be greatly appreciated.

Thank you in advance for your time and assistance! :smiling_face_with_three_hearts:

2025-08-10T16:00:00Z

Hi and welcome,

I’m guessing that the trouble with ‘platform’ is what’s causing the net driver to fail reading traffic, as ‘platform’ is the gateway used by drivers to access hardware, so I’ll focus on that.

 <start name="platform" caps="150" ram="1M" managing_system="yes">

If memory serves, configuring it as ‘managing_system’ is what causes it to require a ‘system’ ROM, and there were changes leading up to Genode 25.05(?) related to that. So you could try to assign the value “no” instead of yes. (EDIT: strike-out for clarity for those who later read this thread in-order)

Alternatively, I seem to recall that a blank ‘system’ ROM will do, too (it’s just a text file that contains a string like “power-off” or “reboot” IIRC).

Running a recursive grep on Genode .run files on the string “managing_system” might help find .run files with the correct ‘system’ ROM setup.

Others more knowledgeable than me will be needed to address your other concerns.

Let us know how it goes!

(and congrats on a very well made bug/query report ^^ )

1 Like

Welcome to our community,

as @ttcoder already pointed out, the platform driver for the imx8mp_armstone board requires a ROM named “system”. It asks for it at its parent (most probably the init component), but because that service gets denied, the platform driver fails, which is sensitive for all other device drivers including network.

This ROM is typically used, e.g. in Sculpt OS, to determine the envisioned next system state like “normal”, “reset”, or “poweroff”. It is for instance used by the GUI of Sculpt-OS to instantly reboot if the user requested so. Or you can implement a management component that tracks heartbeats from sensitive components, which might reset etc..

Even if you do not need this kind of mechanism, the component imx8mp_armstone_platformis dependent on such a ROM. Therefore, you need to provide a route to a ROM service fulfilling this dependency. Therefore, you can also provide a dummy ROM, which does not change at all during runtime, for instance by using a simple boot module (boot modules can be accessed as ROM). Please have a look at the following run-script as an example: genode-imx/run/armstone_framebuffer.run at master ¡ genodelabs/genode-imx ¡ GitHub

The failure has nothing to do with the managing_systemattribute used in the start node of the platform driver. It is wise to keep this property enabled in this context. The managing_system property is a special right. It gets forwarded to corethe root of all components in the system when the protection-domain of the platform driver gets created by init. It hints corethat this component has some special rights, e.g. to determine the bus-addresses of some anonymous memory (RAM dataspace). Only with this property enabled, the platform driver is for instance able to deliver DMA-capable memory to its clients: the actual device drivers, e.g. your network driver.

1 Like

Yes, I can only agree! Thank you for your well-written, thoughtful description.

Becasue I really want to solve this problem, and witness Genode running network services on the iMX board.:heart_eyes:

Thank you very much for helping us understand the meaning of the managing_system parameter.

I noticed that you all mentioned the ROM configuration. While reviewing the script provided by skalk, I suddenly realized that I had been assuming that the run script was cross-platform. After running it on QEMU, I only made simple modifications to the build.conf file in the build folder of the Genode main code architecture. Specifically:

  1. Set BOARD ?= virt_qemu_arm_v8a,

  2. Added REPOSITORIES += $(GENODE_DIR)/repos/imx and RUN_OPT += --include image/uboot

After that, I proceeded with the compilation and directly deployed the generated uImage to the board, which then led to the error. Throughout this process, there were no changes to the run script, and the ROM configuration was consistent with the QEMU environment. Is there something wrong with this? Do I need to refer to the configuration in the linked script and write a platform-specific run file, configuring ROM or drivers more specifically, to ensure the board’s functionality works properly? But I have another question, why I didn’t encounter this

on Genode 25.05, it doesn’t make sense.

I believe this confusion might be the key reason I haven’t been successful so far, because I realized that the previous run file did not lack ROM configuration, but it only had the following configuration:

<parent-provides>
		<service name="ROM"/>
		<service name="IRQ"/>
		<service name="IO_MEM"/>
		<service name="IO_PORT"/>
		<service name="PD"/>
		<service name="RM"/>
		<service name="CPU"/>
		<service name="LOG"/>
	</parent-provides>

    <start name="drivers" caps="1200" managing_system="yes" priority="0">
        
        <resource name="RAM" quantum="512M"/>
        <binary name="init"/>
        <route>
            <service name="ROM" label="config"> <parent label="drivers.config"/> </service>
            <service name="Timer"> <child name="timer"/> </service>
            <service name="Uplink"> <child name="nic_router"/> </service>
            <any-service> <parent/> </any-service>
        </route>
    </start>

But it did not include a specific ROM configuration for the device tree. Is the following kind of configuration required for any driver being used, and was I unaware of this issue because on non-imx platforms only a simple driver configuration is needed?

<start name="fb" caps="250">
		<binary name="imx8mp_armstone_fb"/>
		<resource name="RAM" quantum="128M"/>
		<route>
			<service name="ROM" label="dtb"> <parent label="imx8mp_armstone_fb-imx8mp_armstone.dtb"/> </service>
			<service name="RM">       <parent/> </service>
			<service name="ROM">      <parent/> </service>
			<service name="PD">       <parent/> </service>
			<service name="CPU">      <parent/> </service>
			<service name="LOG">      <parent/> </service>
			<service name="Timer">    <child name="timer"/>            </service>
			<service name="Platform"> <child name="platform"/>         </service>
			<service name="Capture">  <child name="test-framebuffer"/> </service>
		</route>
	</start>

Thank you again for your valuable advice. I look forward to your reply.

I also don’t understand what means provide a dummy ROM, I want to know is it a file or just a line of config in *.run. And if it is a file, where should I place it.

In the link provided by skalk, I believe the dummy ‘system’ state is provided by this part of the run script:

set fd [open [run_dir]/genode/system w]
puts $fd {
<system state=""/>
}
close $fd

I think there should also be another part of the .run script which then refers to that file, to include it as a boot-module ROM in the generated bootable image, but can’t remember what it is ATM (maybe it’s just [build_artifacts]).

In Genode 24.05 there were changes related to that ROM. I don’t recall exactly which, but based on the commit I made to my own project at the time, it seems ‘system’ migrated from being provided (or read?) by a report_rom to something else.

Oh, thank you very much. I tried adding this script to my run configuration. Although my network test program still doesn’t seem to run successfully :grinning_face: , it indeed ensured that the “ROM-session creation failed” error no longer occurs when running on the development board. It seems my previous guess was incorrect. Now, I have two new questions:

  • I noticed that the /imx/recipes/raw/drivers_nic-imx8mp_armstone/drivers.config file specifies the device tree, and there is also a corresponding dtb file in the depot folder. I suspect that the Genode community’s practice is to write their own device trees to adapt to hardware vendors, rather than following the Linux approach. Therefore, I might need to confirm whether the Genode community has network driver support for this board. How should I confirm this?
  • Is there a test script in the community for testing the normal Ethernet connection between the development board and the router? Since I was able to successfully compile the image file by manually creating the drivers_nic-imx8mp_armstone configuration file, I believe this is the next key point to check to ensure that I can run network applications on the board.

Your assumption with regard to the script you originally started with is not necessarily wrong. There are run-scripts specific to an individual board, like the one I’ve referenced to, and there are run-scripts that typically uses depot packages to spawn a driver-class runtime (in your case for the network card) for the specific board to test. To make that work, you need a corresponding depot package for your designated board, which is not available with respect to the imx8mp_armstone, because we don’t automatically test this specific board in the nightly test-infrastructure of Genode Labs, and typically provide these driver runtime packages especially for our test targets.

If you want to look at a plain (no special sub-init components with a driver runtime inside), board-specific run-script you can look at the run-scripts inside the genode-imx repository, which refer to boards like mnt_pocket, armstone, or imx8mp_iot_gate in their names. Those mentioned boards all share the same SoC and are pretty much compatible regarding the ported Linux device drivers.

As mentioned above, the main difference in between both examples is: in the first example a new initcomponent gets spawned, and the configuration of that sub-init is delivered by a driver meta-package (depot), which typically also includes needed driver binaries and/or DTB files in case of ARM drivers ported from Linux. Probably, you’ll find something similar to the following at the beginning of your run-script:

import_from_depot [depot_user]/src/[base_src] \
                  [depot_user]/pkg/[drivers_nic_pkg] \
...

Here, you import a package including the base-library for your platform, and a meta-package including a configuration and all ingredients to spawn a network runtime, which provides access to exactly one NIC card. We use this to drive nightly network tests that do not depend on an individual platform.

In your case, given that you want to drive more than one network card, or several other peripherals in parallel, it is no good option to use this meta-package. However, it might serve as a starting point to look into the configuration to learn how to tweak your own runtime. You’ll find most configurations of these meta-packages regarding the i.MX family within: genode-imx/recipes/raw/drivers_*/drivers.config

In general, there are no device tree blobs used in Genode, e.g. by native drivers. However, when using ported ARM drivers, cut out from the Linux kernel, we also use automatically stripped down variants of the board’s DTB that includes everything necessary for that one peripheral only. The information within the DTB is used by the driver component internally only. The policy, which hardware resources can be accessed by which driver is independently of it, and part of the platform driver configuration that uses the same overall configuration language used by Genode (currently XML).

Genode respectively Sculpt-OS was already run successfully on the i.MX 8MP Armstone including tested network connection with respect to the FEC NIC. In general, we also have support for the second NIC of this SoC, namely STMMAC. However, support for the STMMAC NIC was tested on MNT Pocket and Compulab IOT Gateway only. Nevertheless, both boards share the same i.MX 8MP SoC with the Armstone variant. Therefore, it shouldn’t be an issue to make that second NIC available too. As a reference, you might have a look at the following run-script: genode-imx/run/mnt_pocket_stmmac_nic.run at master · genodelabs/genode-imx · GitHub

Please, be aware that we didn’t extracted an individual DTB for the STMMAC for Armstone yet. However, I think you can try out the very same DTB of the MNT Pocket board in the first place.

If you already created a drivers_nic-imx8mp_armstonepackage, I assume using the FEC NIC(?), you can run for instance the lwip.runscript. It is located within: repos/libports/run/lwip.runin Genode’s main repository. It combines a very simple http server with the network driver runtime and a nic_routercomponent (our networking multiplexer. The machine that executes the run-script will automatically try to access the webpage of the test-machine.

Yes, we use the FEC NIC. Under the current Genode ecosystem, is this theoretically feasible?

It sounds like this means that in order to successfully deploy Genode on our imx8mp board, we cannot directly use the generic script but instead need to adapt the scripts for specific platforms found in the genode-imx repository. I noticed that this script imx8mp_qcacld2_wifi.run specifically configures the driver for the imx8mp_qcacld2_wifi module to function correctly. What would the adaptation process generally involve? If we are adapting the fec_nic driver for the imx8mp_armstone, does this require starting from scratch, or can we achieve the goal by identifying and assembling existing components? Additionally, you mentioned that these scripts were written for testing purposes. Does the existence of this script imx8mp_qcacld2_wifi.run imply that the Genode community has at least tested the Wi-Fi functionality on the imx8mp_armstone board and successfully passed the test?

Yes definitely, the FEC driver was already used on this board practically running Sculpt OS.

1 Like

No, this is not what I wanted express. You do not necessarily need to create a bunch of new board-specific run-scripts. If you want to test specific scenarios on your target board, e.g. the lwip TCP/IP stack using the lwip.run run-script, it is perfectly fine to create a depot package like drivers_nic-imx8mp_armstonetherefore, like you did it.

If you want to re-use a generic run-script that provides some GUI, and you need framebuffer and input I/O peripherals therefore, it is enough to create a similar depot package consistently named drivers_interactive-imx8mp_armstone. You can search for existing run-scripts that include “drivers_interactive-*”.

But if it comes to the point that you want to create an own scenario, which combines arbitrary peripherals resp. device drivers in one scenario (for instance both NIC cards at once), you either need to write your own board-specific run-script, or follow the Sculpt OS approach, where you have a basic system that can be extended dynamically at runtime by installing new packages and so on.

For the time being, to dive into Genode and to not overburden yourself with too much new concepts, I think it is perfectly fine to follow the approach you were starting with, and let the drivers_nic-*based run-scripts fly on your target board.

Regarding the imx8mp_qcacld2_wifi.run: it got created to test wifi on the MNT Pocket Reform board, which is based on the very same i.MX 8MP SoC.

Regarding the adaption process of driver components for new boards: it might involve only the identification and integration of necessary components. You maybe have to look at the board resources involved, and whether there are differences in between boards using the same SoC. In that case the configuration of the components (for instance platform driver’s provided resources) has to be tweaked. But of course under rare circumstances it might happen that a ported driver steps into code portions that weren’t stressed before within a “new board environment”, which then necessitates adaptions of the driver emulation layer.

1 Like

I understand your point now, and I appreciate you helping me clear up the confusion I had due to my lack of understanding of the Genode system. I will continue to follow the approach you recommended. I also appreciate your understanding of my unfamiliarity with Genode and your consideration of these details. I will continue to provide updates if there is any progress. Additionally, I believe the Genode manual at https://genode.org/documentation/genode-platforms-23-05.pdf could help me solve this issue, as it seems to contain a lot of valuable knowledge. If so, could you recommend which chapters in this manual would be particularly helpful for solving this issue? Again, thank you for your help!

Yes, I think it is helpful to look at the Platforms book, especially chapters 2.9 - 2.12 and 2.15 might be interesting given your context. Moreover, it is advisable to read the Foundations book: Genode - Genode Foundations to understand the fundamental concepts.