Genode on RPI - second round

Tomasz Gajewski tomga at
Sun Feb 17 17:12:32 CET 2019

Hi to all.

In my last message I wrote:

 "Now I'm starting again from start but with different knowledge level."

and now I have some preliminary results and another set of

After making run/log work on single core I had two possible directions
to take: device drivers or enable smp. I started with smp as with the
device drivers I need an advice about build system (later in this

For SMP on RPI I implemented new timer driver as the current one was not
capable to support multiple independent timers for cores and new PIC
driver - for timer and inter processor interrputs.

Current code is in (rewritten) same branch as previously at [1] in case
you wanted to look. run/smp test is almost working on all cores with the
exception for thread cleanup (which will be another question later in

1. Register sets.

On multicore Raspbery Pi there are sets of registers in which each
register has the same structure and each is "assigned" to different
core. Currently I replicated definitions of registers for each core [2]
but it's obviously not a good solution. Additionally it forces to write
ugly code when cpu_id is in the variable as in [3].

Is there some support in Genode for such structures? If not, do you see
how that could be implemented? Some wrapper for Register? I fail to see
how dynamic value of 'cpu_id' could be nicely mixed with register
offsets passed as template arguments.

I think ideally it would be to define something like this:

  struct CoreTIrqCtl : RegisterSet<0x40, 32, COUNT, OFFSET>

and use it like this:

  write<CoreTIrqCtl>(CPU_ID, 0);

Any thoughts?

2. Interrupts handling

I have doubts about interrupts processing. I have limited knowledge in
this area so I may be totally wrong but based on what I read for RPI I
think that:

 a. On one IRQ there can be more than one interrupt flag marking an
    exception. During this one entry to 'Thread::exception(Cpu&)' and
    later to 'Cpu_job::_interrupt(unsigned const)' all pending
    interrupts should be handled in some loop. Without that some
    interrupts may stay unhandled. And I don't see such loop in this
    code. One exception is taken from Pic driver, handled and that's

 b. I don't know where clearing an interrupt should be handled. I would
    have thought that 'Pic::finish_request()' would be good for this,
    but there are many empty implementations. Should code in
    'Pic::take_exception(...) also clear the exception condition? My
    doubts come from feeling that if I do this too early "something" can
    happen before handling of interrupt is finished.

    If 'finish_request()' is a proper place to clear interrupt as
    handled than it would be useful to pass to it interrupt number
    earlier returned from 'take_request'. Otherwise there would have to
    be separate storage for each core in Pic to store information about
    currently handled exception on a given core. Am I right? Does it
    work properly in [4]?

3. run/smp test hangs during threads destruction

Like I wrote earlier run/smp test is almost working on multiple
cores. It hangs somewhere in [5] during destructing thread running
non-zero core (destroying first one does not cause problems).

I don't have any concrete questions here. The only ones are:

 a. Does this test properly work on arndale?

 b. Do you have any thoughts what can go wrong? Maybe I haven't
    implemented something important for smp yet? Only timer and IPI?

4. Drivers reused for different configurations

Currently to support RPI3 I created configurations named
'rpi3bplus'. How should I proceed to reuse a driver written for rpi? For
example framebuffer driver has 'REQUIRES = rpi' in [6] and
that causes that it does not compile for my 'rpi3bplus'. It would be
nice to have: 'REQUIRES = rpi|rpi3bplus' but I don't think it is
possible. Can you suggest something?

Tomasz Gajewski


More information about the users mailing list