Based on my observations from the QEMU environment, I believe if the network service were functioning correctly, the log should show the dynamically acquired IP address where it currently says [uplink] dynamic IP config: none. Furthermore, the [uplink] NIC sessions: should be 1, not 0.
To clarify a previous point with another observation: when I boot without loading the device tree, the U-Boot output does change (it shows an error)
output of boot without loading the device tree
forlinx=> fatload mmc 1 0x40800000 sp_tcp
3204712 bytes read in 208 ms (14.7 MiB/s)
forlinx=> bootm 0x40800000 - 0x40000000
## Booting kernel from Legacy Image at 40800000 ...
Image Name:
Image Type: AArch64 Linux Kernel Image (gzip compressed)
Data Size: 3204648 Bytes = 3.1 MiB
Load Address: 40200000
Entry Point: 40200000
Verifying Checksum ... OK
ERROR: Did not find a cmdline Flattened Device Tree
Uncompressing Kernel Image
Starting kernel ...
kernel initialized
Genode 25.08
2035 MiB RAM and 64536 caps assigned to init
[init] parent provides
[init] service "ROM"
[init] service "IRQ"
[init] service "IO_MEM"
[init] service "PD"
[init] service "CPU"
[init] service "LOG"
[init] child "timer"
[init] RAM quota: 776K
[init] cap quota: 66
[init] ELF binary: timer
[init] priority: 0
[init] provides service Timer
[init] child "platform"
[init] RAM quota: 1800K
[init] cap quota: 116
[init] ELF binary: imx8mp_platform
[init] priority: 0
[init] provides service Platform
[init] child "fec_nic_drv"
[init] RAM quota: 16136K
[init] cap quota: 216
[init] ELF binary: fec_nic
[init] priority: 1
[init] child "nic_router"
[init] RAM quota: 9992K
[init] cap quota: 166
[init] ELF binary: nic_router
[init] priority: 0
[init] provides service Nic
[init] provides service Uplink
[init] child "tcp_terminal"
[init] RAM quota: 7944K
[init] cap quota: 166
[init] ELF binary: tcp_terminal
[init] priority: 0
[init] provides service Terminal
[init] child "test-terminal_echo"
[init] RAM quota: 776K
[init] cap quota: 66
[init] ELF binary: test-terminal_echo
[init] priority: 0
[init -> fec_nic_drv] --- i.MX FEC nic driver started ---
[init] child "timer" announces service "Timer"
[init -> nic_router] [uplink] dynamic IP config: none
[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 -> tcp_terminal] lwIP Nic interface down
[init -> tcp_terminal] Using DHCP for interface configuration.
the difference is below
However, despite this difference in the U-Boot log, the Genode kernel still boots successfully, and its subsequent output is identical to the scenario where the device tree was loaded. I want to know why is that?
Exactly. Moreover, the FEC driver normally produces some more log messages. So obviously the driver is waiting for something (typically resources, other services like platform service) therefore you do not see an uplink appearing, and therefore the nic_router doesnât request an IP address.
I had tested your originally posted configuration and made the changes suggested (moreover, I had to increase the ram quota of the FEC driver a bit), and it worked on the i.MX 8MP ArmStone board we have at Genode Labs. So I am wondering what the difference should be. It is quite similar to the one, you have posted at last:
create_boot_directory
import_from_depot [depot_user]/src/[base_src] \
[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 \
[depot_user]/src/test-terminal_echo
build {
driver/platform/imx8mp
driver/pin/imx
driver/nic/fec
server/tcp_terminal
}
install_config {
<config verbose="yes">
<parent-provides>
<service name="ROM"/>
<service name="IRQ"/>
<service name="IO_MEM"/>
<service name="PD"/>
<service name="CPU"/>
<service name="LOG"/>
</parent-provides>
<default caps="100" ram="1M"/>
<start name="timer">
<provides> <service name="Timer"/> </provides>
<route> <any-service> <parent/> </any-service> </route>
</start>
<start name="platform" caps="150" ram="2M" managing_system="yes">
<binary name="imx8mp_platform"/>
<provides> <service name="Platform"/> </provides>
<config>
<policy label="fec_nic_drv -> " info="yes">
<device name="fec"/>
</policy>
</config>
<route>
<any-service> <parent/> </any-service>
</route>
</start>
<start name="fec_nic_drv" caps="250" ram="20M">
<binary name="fec_nic"/>
<route>
<service name="Uplink"> <child name="nic_router"/> </service>
<service name="ROM" label="nic.dtb">
<parent label="fec_nic-imx8mp_armstone.dtb"/>
</service>
<service name="Timer"> <child name="timer"/> </service>
<service name="Platform"> <child name="platform"/> </service>
<any-service> <parent/> </any-service>
</route>
</start>
<start name="nic_router" caps="200" ram="10M">
<provides>
<service name="Nic"/>
<service name="Uplink"/>
</provides>
<route>
<service name="Timer"> <child name="timer"/> </service>
<any-service> <parent/> </any-service>
</route>
<config verbose_domain_state="yes">
<policy label_prefix="tcp_terminal" domain="downlink"/>
<policy label_prefix="fec_nic_drv" domain="uplink"/>
<domain name="uplink">
<nat domain="downlink"/>
<tcp-forward port="8888" 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"/>
</domain>
</config>
</start>
<start name="tcp_terminal" caps="200" ram="8M">
<provides> <service name="Terminal"/> </provides>
<config>
<policy label_prefix="test-terminal_echo" port="8888"/>
<vfs>
<dir name="dev"> <log/> </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>
<service name="Timer"> <child name="timer"/> </service>
<any-service> <parent/> </any-service>
</route>
</start>
<start name="test-terminal_echo">
<route>
<service name="Terminal"> <child name="tcp_terminal"/> </service>
<any-service> <parent/> </any-service>
</route>
</start>
</config>
}
set fd [open [run_dir]/genode/system w]
puts $fd {
<system state=""/> }
close $fd
build_boot_image [list {*}[build_artifacts] fec_nic-imx8mp_armstone.dtb]
append qemu_args " -nographic "
append_qemu_nic_args "hostfwd=tcp::5555-:8888"
run_genode_until forever
Because, as Iâve stated in an earlier post of this forumâs thread, Genode does not evaluate the device-tree blob delivered by the u-boot loader. All devices resources the kernel needs are hard-coded in the platform code of the corresponding board. All other device resources are delivered in another configuration form (nowadays XML) via the previously mentioned devices ROM that is evaluated by the platform driver. Therefore, we do not need the DTB of u-boot, and whether that fails or not is not relevant for our system.
Anyway, u-boot potentially prepares the boot environment differently depending on the boot command and DTB delivered. In some cases it may even not boot at all when using bootm with an uImage but without a DTB provided. Actually, I did not use an uImage to boot Genode on the ArmStone board at all, but the newer ITB format (image-tree-blob I guess?). To gain such an image as result of your run-script execution, you need to add the following statement: RUN_OPT += âimage-uboot-fitto your build configuration. As result you will find a var/run/<run-script-name>.itbfile that you can load and run with the bootm command in u-boot. If you do so, it will load your Genode scenario without a DTB but without any error message regarding a missing DTB. I donât think this is the reason for your issue with the FEC driver, just for clarification, and you might give it a try.
Thanks for helping me with the hardware testing! Does this mean it can be successfully found by DHCP service? If so, could you tell me the the specific model of your development board? Maybe we can compare the difference of this to board?
Thanks for the advice, Iâll definitely give it a try !
Thanks for the suggestion. I followed your guidance by adding RUN_OPT += --image-uboot-fit to my build.conf and rebuilt the image.
I was able to successfully create the .itb image. However, when I load this .itb file directly with the bootm command in U-Boot, I encounter the following error during the boot process:
output when use itb file to boot
forlinx=> fatload mmc 1 0x48000000 image.itb
3206638 bytes read in 200 ms (15.3 MiB/s)
forlinx=> bootm 0x48000000
## Loading kernel from FIT Image at 48000000 ...
Using 'conf-1' configuration
Trying 'kernel-1' kernel subimage
Description:
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x48000168
Data Size: 3204743 Bytes = 3.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x40200000
Entry Point: 0x40200000
Hash algo: crc32
Hash value: 3ab485df
Verifying Hash Integrity ... crc32+ OK
## Loading fdt from FIT Image at 48000000 ...
Using 'conf-1' configuration
Trying 'fdt-1' fdt subimage
Description: dummy
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x4830e854
Data Size: 72 Bytes = 72 Bytes
Architecture: AArch64
Hash algo: crc32
Hash value: e442aef3
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0x4830e854
## Loading loadables from FIT Image at 48000000 ...
Trying 'kernel-1' loadables subimage
Description:
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x48000168
Data Size: 3204743 Bytes = 3.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x40200000
Entry Point: 0x40200000
Hash algo: crc32
Hash value: 3ab485df
Verifying Hash Integrity ... crc32+ OK
Loading loadables from 0x48000168 to 0x40200000
Uncompressing Unknown Image
Uncompressing Kernel Image
Using Device Tree in place at 000000004830e854, end 000000004831189b
Unable to update property /soc@0/bus@32c00000/lcd-controller@32e80000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/lcd-controller@32e90000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/lcd-controller@32fc6000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmi-pai-pvi@32fc4000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmi@32fd8000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmiphy@32fdff00:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/irqsteer@32fc2000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmimix@32fc0000/clock-controller:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmimix@32fc0000/reset-controller:status, err=FDT_ERR_NOTFOUND
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@
No Space for dtb
ERROR: system-specific fdt fixup failed: FDT_ERR_NOTFOUND
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
While analyzing the build script, I noticed this piece of logic:
set fd [open [run_dir]/dummy.dts w]
puts $fd "/dts-v1/;\n / {};"
close $fd
exec $dtc [run_dir]/dummy.dts -o [run_dir]/dummy.dtb
It appears to intentionally create and package an empty (dummy) device tree. Is this the expected behavior?
If this (packaging a dummy DTB) is indeed the expected behavior, why does my system still fail to boot? I have a theory: is it because a specific device tree is hardcoded inside the Genode image, and this particular DTB is incompatible with my boardâs specific hardware revision, which is causing the failure?
If my theory is correct, what would be the recommended steps to resolve this? Also, as a potentially faster solution, would I be able to solve this issue simply by purchasing the same model of board that your team uses?
As Iâve stated repeatedly, we do not use the device-tree delivered by the boot-loader. In fact, we do not use a DTB at all, but use either hard-coded I/O addresses for the kernel part (serial line, interrupt-controller), or XML configuration provided to the platform driver. However, some DTBs (stripped down variants) are used to make the ported Linux device drivers happy, but this is another topic.
I doubt that a specific revision of the board is the problem here, because all I/O resource relevant in your example are only dependent on the SoC, and this should be the same for all board revisions resp. variants. Here is the board we are using:
Here is detailed output from u-boot:
U-Boot SPL 2021.04-nboot-fsimx8mp-2023.09 (Sep 01 2023 - 09:16:24 +0200)
BOARD-ID: armStoneMX8MP-FERT4.100
U-Boot 2021.04-F+S-fsimx8mp-Y2023.09 (Aug 31 2023 - 12:56:23 +0000) for F&S
CPU: i.MX8MP[8] rev1.1, 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C)
Reset: POR
Model: armStoneMX8MP
Board: armStoneMX8MP Rev 1.00 (2x LAN, WLAN, eMMC, 1x DRAM)
DRAM: 2 GiB
Thanks a lot for sharing the specific information about the board youâre using! Iâm now considering purchasing this board.
To ensure this is the right direction, Iâd like to confirm one more thing with you.
When you mentioned âit workedâ on your board, does this mean that the network was fully connected and able to communicate normally with the outside world? (e.g., could it successfully ping an external address?)
Your confirmation will be a key reference for my decision on whether to buy the hardware. Thanks again!
I wouldnât recommend to buy extra hardware to you. It is not sure that the differences we are observing are related to hardware differences, or is it? What about the output of u-boot that you can see when starting the board?
However, when I said the setup worked on my board, I was meaning: (obviously it needs to be physically connected), an IP address was requested and delivered by my local network DHCP server to the target board resp. the nic_router component, which also prints the IP address it gained, and the simple HTTP component running on top could be addressed from outside and delivered its simple web page example.
U-Boot SPL 2020.04-00016-gc934c03999 (Apr 10 2023 - 05:59:11 +0000)
forlinx eep: 2024-09-10 ver 3
eep: now update emmc pins for bootrom
using eep parameter
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from BOOTROM
image offset 0x0, pagesize 0x200, ivt offset 0x0
NOTICE: BL31: v2.2(release):rel_imx_5.4.70_2.3.0-0-gf1d7187f2
NOTICE: BL31: Built : 03:31:00, Apr 8 2021
Forlinx
U-Boot 2020.04-00016-gc934c03999 (Apr 10 2023 - 05:59:11 +0000)
CPU: i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 37C
Reset cause: POR
Model: Forlinx OK8MPlus LPDDR4 EVK board
DRAM: 4 GiB
MMC: FSL_SDHC: 1, FSL_SDHC: 2
try kernel dtb
Error binding driver 'gpio_led': -22
Some drivers failed to bind
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
lvds0_panel enable
mipi_panel_uboot enable
eth0 enable
eth1 enable
Loading Environment from MMC... OK
video link is full
[*]-Video Link 0 (1024 x 600)
[0] lcd-controller@32e80000, video
[1] mipi_dsi@32e60000, video_bridge
[2] mipi_panel_uboot, panel
[*]-Video Link 1 (1280 x 800)
[0] lcd-controller@32e90000, video
[1] ldb@32ec005c, video_bridge
[2] lvds0_panel, panel
[ ]-Video Link 2
[0] lcd-controller@32e90000, video
[1] ldb@32ec005c, video_bridge
In: serial
Out: serial
Err: serial
BuildInfo:
- ATF f1d7187
- U-Boot 2020.04-00016-gc934c03999
switch to partitions #0, OK
mmc2(part 0) is current device
secure check passed
audio codec is NAU88C22, skip set fdt
flash target is MMC:2
Net: config yt8521
eth0: ethernet@30be0000
Fastboot: Normal
Normal Boot
Autoboot in 1 seconds
-------------------------------------
1: shell
2: boot linux
3: Display select
0: reboot uboot
-------------------------------------
forlinx=> fatload mmc 1 0x48000000 image.itb
3206638 bytes read in 200 ms (15.3 MiB/s)
forlinx=> bootm 0x48000000
## Loading kernel from FIT Image at 48000000 ...
Using 'conf-1' configuration
Trying 'kernel-1' kernel subimage
Description:
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x48000168
Data Size: 3204743 Bytes = 3.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x40200000
Entry Point: 0x40200000
Hash algo: crc32
Hash value: 3ab485df
Verifying Hash Integrity ... crc32+ OK
## Loading fdt from FIT Image at 48000000 ...
Using 'conf-1' configuration
Trying 'fdt-1' fdt subimage
Description: dummy
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x4830e854
Data Size: 72 Bytes = 72 Bytes
Architecture: AArch64
Hash algo: crc32
Hash value: e442aef3
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0x4830e854
## Loading loadables from FIT Image at 48000000 ...
Trying 'kernel-1' loadables subimage
Description:
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x48000168
Data Size: 3204743 Bytes = 3.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x40200000
Entry Point: 0x40200000
Hash algo: crc32
Hash value: 3ab485df
Verifying Hash Integrity ... crc32+ OK
Loading loadables from 0x48000168 to 0x40200000
Uncompressing Unknown Image
Uncompressing Kernel Image
Using Device Tree in place at 000000004830e854, end 000000004831189b
Unable to update property /soc@0/bus@32c00000/lcd-controller@32e80000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/lcd-controller@32e90000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/lcd-controller@32fc6000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmi-pai-pvi@32fc4000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmi@32fd8000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmiphy@32fdff00:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/irqsteer@32fc2000:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmimix@32fc0000/clock-controller:status, err=FDT_ERR_NOTFOUND
Unable to update property /soc@0/bus@32c00000/hdmimix@32fc0000/reset-controller:status, err=FDT_ERR_NOTFOUND
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@
No Space for dtb
ERROR: system-specific fdt fixup failed: FDT_ERR_NOTFOUND
- must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
Here is my board output
Am I right that youâre using a board from Forlinx actually? If yes, the title of this thread, and your initial post was misleading, and we were searching in the wrong direction.
i.MX8MP ArmStone is a board from the vendor F&S Embedded. It obviously uses the very same SoC (which is good) like your board from Forlinx, but nonetheless there are mostly some differences in between different boards, like for instance the concrete ethernet PHY or regarding powering of PHYs.
Now, you can either buy the F&S Embedded ArmStone i.MX8MP, the Compulab IoT Gateway using the i.MX8MP (the latter gets actively used by Gapfruit using Genode), or we concentrate on the differences of your board.
To fully enable the Ethernet controller of your board, you first need to identify, which ethernet controller is actually in use (i.MX8MP provides two different ones), or whether both are led out of the SoC to ethernet connectors? According to the u-boot output I would expect that both ethernet controllers are available. Then you would need to inspect the device-tree of your specific board, and need to identify how it does differentiate resp. what might be board-specific parts related to the ethernet controller. One first shoot in the dark would be to use network inside u-boot (e.g., by the dhcp command) and thereby implicitly let u-boot initialize needed board peripherals.
Thank you for your insight. You are correct that I am using a Forlinx board, and I sincerely apologize for the confusion caused by my initial post and the thread title. I initially assumed the boards were from the same series due to the shared SoC, which led me to believe the issue was more related to my lack of familiarity with embedded development rather than hardware adaptation. I now realize this may have been misleading, and I apologize for any confusion.
Regarding your suggestion, I have already confirmed that the network functions correctly when the board is running Linux, so I am wondering if testing in u-boot might not be necessary after all. However, if I want to get the network running under u-boot, should I focus on finding the appropriate XML files to modify? Do I need to parse the device tree information provided by the hardware vendor and adapt it accordingly in the XML?
Additionally, I have a question. When I booted without loading the dtb and directly used UImage, the system ran, but the peripheral devices didnât seem to be properly detected. However, when I switched to using the ITB format, I encountered a direct error. Iâm not sure why this is happening. Could you shed some light on this?
You do not need to apologize. I understand that the different layers of CPU cores, SoC, sometimes SoM, and board and their potentially different vendors is confusing when starting to dive into it. When looking more carefully at the image of your initial post, I should have recognized that you are using a different board initially.
My suggestion is not to use u-boot to validate that the network controller is working in general, but to use network within u-boot, and directly to load and start your Genode image then without rebooting in between. Then there is a chance that u-boot prepares necessary board essentials, and with some luck you are able to use it in your scenario. Of course, there are several potential stumbling blocks that otherwise need to be addressed gradually, when enabling a different board with the same SoC, like different SoC pin settings (so called IOMUX controller in the i.MX series), additional ICs to power an ethernet PHY, and so on.
To let u-boot drive the ethernet card(s) you do not need to change any configuration.
Iâm not sure what kind of error you encountered. Maybe, I can help you therewith, but therefore I would need the concrete error output.
Here is the error output I mentioned
Thank you again for the invaluable advice. I now clearly understand that I should use U-Bootâs network capabilities as a workflow tool to load my Genode image, which will greatly help my development process.
Your comment about U-Boot preparing ânecessary board essentialsâ made me think more deeply about the long-term strategy for hardware adaptation. This has led me to two different interpretations of the underlying hint in your suggestion, and I would be extremely grateful if you could clarify which path is the correct one to follow.
-
Interpretation A (The Reference/Porting Path): My first interpretation, which seems the most logical to me, is that I should treat U-Bootâs working implementation as a âknown good reference.â This would mean my next task is to study its source code (like the device tree or board-specific files) to extract the essential hardware detailsâsuch as pin configurations (IOMUX), clock settings, and PHY addressesâand then use that information to manually write the correct XML configuration for Genodeâs own native driver.
-
Interpretation B (The Direct Leverage Path): My second, more speculative, interpretation is whether there is an advanced technique for Genode to somehow directly leverage or continue using the network hardware state that U-Boot has already perfectly initialized.
I must admit, I find Interpretation B less likely, based on my understanding that a bootloader typically relinquishes all control and its context is lost once it jumps to the operating system kernel. However, I wanted to ask this directly in case there is a âhand-offâ mechanism or a feature I am not aware of.
Could you please confirm which interpretation is correct?
Okay, to me it seems that your u-boot version is not happy with the dummy DTB provided within your FIT image, because it uses it to overlay certain properties. Of course, you can replace the dummy DTB with a valid one for your board, just to make u-boot happy and let it continue to load your image, but anyway as you can already successfully load Genode when using no FIT image, I would not dig deeper into this issue.
Both interpretations are partly correct. I meant - for the moment - to use the âleverage pathâ, but it doesnât mean we takeover/handover the ethernet card IP core itself and its configuration, because this piece of hardware gets fully (re-)initialized by the driver running in Genode. However, if there is some hardware configuration not directly corresponding to the ethernet functionality, but indirectly, e.g. a power source for the external ethernet connector residing on the board, then there is a chance that u-boot enables it, and keeps it up when loading our OS.
In the long run, of course it is necessary to identify the missing piece, and integrate it (the reference/porting path) either in the ethernet driver itself, or the platform driver - dependent on what is missing. But here I would concentrate on a runnning Linux kernel as reference, because we ported the driver from it, have dedicated tools to ease that part, and the comparison will be more straightforward.
Okay, I understand now. However, the porting work is a significant challenge for me, and Iâm not sure yet if I want to commit to that path.