I’m recently been experimenting with Genode and have followed the book to implement the hello world demo. This seems to work and run fine for x86/linux/linux and armv8a/hw/virt_qemu_arm_v8a, but I can’t see any serial output when I build for armv8a/hw/imx8mq_evk. This is the command that I’m using to build the image (with KERNEL=hw and BOARD=imx8mq_evk specified in etc/build.conf)
RUN_OPT='--include image/uboot' make run/hello
and this is the output that I’m seeing when I attempt to boot the produced image
u-boot=> dhcp
BOOTP broadcast 1
DHCP client bound to address 172.16.1.11 (11 ms)
u-boot=> tftpboot 0x42000000 imx8mq/uImage
Using ethernet@30be0000 device
TFTP from server 172.16.0.2; our IP address is 172.16.1.11
Filename 'imx8mq/uImage'.
Load address: 0x42000000
Loading: ###############################################################
9.6 MiB/s
done
Bytes transferred = 915145 (df6c9 hex)
u-boot=> bootm 0x42000000
## Booting kernel from Legacy Image at 42000000 ...
Image Name:
Image Type: AArch64 Linux Kernel Image (gzip compressed)
Data Size: 915081 Bytes = 893.6 KiB
Load Address: 40010000
Entry Point: 40010000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
After this, I don’t observe any other output. It seems like the UART driver is functional, as the following patch
--- a/src/include/hw/spec/arm/imx_uart.h
+++ b/src/include/hw/spec/arm/imx_uart.h
@@ -251,6 +251,11 @@ class Hw::Imx_uart: Genode::Mmio<0xa2>
Genode::Mmio<SIZE>({(char*)base, SIZE})
{
init();
+
+ for (int i = 0; i < 10; i++) {
+ put_char('a');
+ }
+ put_char('\n');
}
adds
aaaaaaaaaa
to the output as you would expect.
This makes me think there’s something I haven’t configured correctly to allow the logger to write to the UART, but I’m at a bit of a loss why the same code works fine for other architectures/platforms.
well that is interesting. I’ve just now tested this scenario using our current staging branch, and it works well.
So most important, are you really using the NXP i.MX 8M Quad EVK board? Because there are other variants existing like i.MX 8MP EVK, which is using another SoC variant of the i.MX8 family. Maybe, you can have a look at the complete product name including revision?
Second, I’m not sure whether the u-boot of your board has changed somehow in contrast to the ones we use for testing at Genode Labs. To exclude it has something to do with the way u-boot loads the image, first you might load the uImage to an address way more away from the beginning of memory like 0x60000000 - just as a test, e.g.:
Secondly, you can use our tested version of u-boot together with Genode all together assembled into one SD-card image that you can write to SD-Card and boot from SD-card instead of eMMC. Therefore, you need to add another RUN_OPT like so:
RUN_OPT+='--include image/imx8mq_mmc' make run/hello
The resulting image will reside at var/run/hello.img and can be written to SD-card using dd. With that SD-card in place, and after toggling the switches on the board correspondingly to boot by card, you should see the scenario booting. If it is working with the u-boot from SD-card, you should be able to use it for network booting too.
The Uboot output when I boot the board is the following:
U-Boot 2017.03 (Apr 11 2018 - 10:04:36 +0800)
CPU: Freescale i.MX8MQ rev2.0 1500 MHz (running at 1000 MHz)
CPU: Commercial temperature grade (0C to 95C) at 28C
Reset cause: POR
Model: Freescale i.MX8MQ EVK
DRAM: 3 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In: serial
Out: serial
Err: serial
so I’m pretty sure it’s an imx8mq_evk.
My actual goal was to boot the image on the Avnet MaaXboard, which is based on the same SoC, and in the process of banging my head against the wall, I just ran the image on that board instead. Interestingly, the same image seems to work fine on that, so you’re probably right that it’s something to do with the UBoot or a problem with the board itself (though I don’t really understand how).
I’ll update this thread about whether changing the load address or flashing your UBoot to the SD card works some time next week.