Hi Reinier,
After that i have modified the arora.run script based on demo.run to support the service Platform, this is a patch version of the changes:
diff --git a/repos/ports/run/arora.run b/repos/ports/run/arora.run index c229bd6..a4a7207 100644 --- a/repos/ports/run/arora.run +++ b/repos/ports/run/arora.run @@ -9,10 +9,14 @@ set feature(Nic) 1 set build_components [qt5_build_components feature] append build_components { + drivers/input
this line is not needed because on the Rpi, the "Input" service is provided by the USB driver.
server/loader server/tar_rom server/nit_fb app/launchpad test/nitpicker app/arora } +lappend_if [have_spec gpio] build_components drivers/gpio
This line can be omitted because the Rpi platform does not enable the "gpio" spec value anyway. But it does not do harm either.
+lappend_if [have_spec platform_rpi] build_components drivers/platform + build $build_components create_boot_directory @@ -44,6 +48,13 @@ append config { append config [qt5_start_nodes feature] +append_if [have_spec platform_rpi] config { + <start name="platform_drv"> + <resource name="RAM" quantum="1M"/> + <provides><service name="Platform"/></provides> + <config/> + </start>} + append config { <start name="loader"> <resource name="RAM" quantum="2M"/> @@ -131,6 +142,8 @@ if {[have_spec qt4_deprecated]} { } } +lappend_if [have_spec platform_rpi] boot_modules platform_drv + build_boot_image $boot_modules append qemu_args " -m 512 "
The remainder of the patch looks good to me.
When try to run the Arora example get the framebuffer initialized but don't start the arora browser on the framebuffer, this is the serial output:
Genode 14.08 int main(): --- create local services --- int main(): --- start init --- int main(): transferred 165 MB to init int main(): --- init created, waiting for exit condition --- [init -> fb_drv] --- fb_drv started --- [init -> platform_drv] --- Raspberry Pi platform driver --- [init -> usb_drv] Services::Services(): No <storage> config node found - not starting the USB Storage (Block) service [init -> usb_drv] Enabled UHCI (USB 1.0/1.1) support [init -> usb_drv] Enabled EHCI (USB 2.0) support [init -> usb_drv] Using configured mac: 2e:60:90:0c:4e:01 [init -> usb_drv] dev_info: DWC OTG Controller [init -> usb_drv] dev_info: new USB bus registered, assigned bus number 1 [init -> usb_drv] dev_info: irq 17, io mem 0x00000000 [init -> usb_drv] dev_info: USB hub found [init -> usb_drv] dev_info: 1 port detected [init -> nitpicker] create session with args: label="wm", ram_quota=28672 [init -> nitpicker] create session with args: label="pointer", ram_quota=28672 [init -> nitpicker] create session with args: label="wm -> decorator", ram_quota=28672 [init -> arora] tar archive 'qt5_fs_arora.tar' local at 230000, size is 503808 [init -> arora] void init_libc_lock_pipe(): init_libc_lock_pipe() [init -> arora] using the pipe libc plugin [init -> arora] void init_nic_dhcp(): init_nic_dhcp() [init -> arora] Using DHCP for interface configuration. [init -> arora] {anonymous}::Plugin::Plugin(): using the lwIP libc pluginI think that "No <storage> config node found ..." should not be causing the problem running the Arora browser.
You are right. The problem must be somewhere else. I have two ideas:
First, the USB driver may got stuck because it missed one of the high-frequent SOF interrupts. Not only do those interrupts occur at a very high rate but they must be serviced in a timely manner too. Otherwise the USB host controller or hub gets stuck. The LOG output shows that the USB hub is found (so the communication of the driver with to the host controller is working) but there is HID device popping up (you may compare the above output of the USB driver with the output produced by the demo.run script to see the difference). When running a complex scenario including Qt5 programs, a CPU-intensive process (i.e., Arora) may defer the operation of the USB driver. So the USB driver will service the interrupt too late. I observed a similar problem with the gems/run/wm.run script on the Rpi:
https://github.com/genodelabs/genode/blob/master/repos/gems/run/wm.run
To remedy this effect, the static priorities of the base-hw kernel come to the rescue. For the wm.run script, I downgraded the priorities of the heavy-weight processes. Look out for the "prio_levels" and "priority" attributes in the run script. You can find the corresponding documentation here:
http://genode.org/documentation/developer-resources/init#Priority_support
The second possible issue might be related to the networking driver, which is provided by the USB driver, too. The Rpi relies on networking-over-USB. Personally, I have not used networking on the Rpi, yet. So you are conquering uncharted land here.
Have you successfully tried to run a simpler Qt5 application on the Rpi. I would recommend to test the qt5.run script first. This one does not rely on a working networking driver. Once you got the qt5.run script working, have a look at the networking as a separate step by testing (and adapting) the libports/lwip.run script on the Rpi. I would not try to get the arora.run script working unless both run scripts qt5.run and lwip.run work fine.
Good luck!
Norman