Help testing arora,qt5 and sdl examples on RaspberryPI

[Norman Feske]

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
>     plugin
> 
> I 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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth