Genode on RPI

[Tomasz Gajewski]

Hello,

thanks for your response. My comments also inline.


Stefan Kalkowski <stefan.kalkowski at genode-labs.com> writes:

> Hello Tomasz,
>
> thank you very much for sharing your experimentation efforts and
> insights and for starting the discussion. Please, see my comments
> inline below.

...

>> For writing traces to memory I've created a simple utility (set of
>> macros in assembly and C++) to write simple debug values to a buffer in
>> memory. I used it to diagnose what is going on before serial connection
>> is working.
>>
>> It is specified by a buffer address and size. At the beginning a pointer
>> to current position in buffer is stored. A 1-1 mapping is inserted into
>> TLB for this region and I had to make changes in virtual memory layout
>> of core. Currently addresses are hardcoded but I can polish it to a
>> state where it could be enabled/disabled with some build option or some
>> defines in one place in the code if you'd like to use this. I pushed
>> current state of my work [1] (without any cleanup yet). Utility macros
>> are in:
>>  - repos/base/include/base/memtrace.h
>>  - repos/base-hw/src/bootstrap/spec/arm/crt0.s
>> Would you be interested in adding something like this to Genode? I would
>> create issue and propose some version.
>>
>
> Very cool that you could help yourself that way!
> In general, we already have a tracing mechanism in Genode, where
> tracing points are collected in memory, and might get aggregated even
> from many different components for debug or optimization reasons.
> Anyway, that mechanism is based on core's functionality and therefore
> only appropriated for components running on top of core/kernel.

It was meant only for debugging parts before I could access Genode::log.

> Another option used in NOVA/Genode is to write all kernel messages
> into a memory buffer and export it to the userland. Thereby, you can
> aggregate messages in headless systems or systems without AMT or
> serial line. I think this way might be appropriated to be used in
> base-hw too. Anyway, I would not introduce new debug macros, but
> just add a simple serial driver, which isn't using a special device
> but a portion of memory for printing. Then one can switch UART to that
> model if there is no one, or it is troublesome. What do you think
> about that approach?
>
> I have to admit that usually I can use a JTAG debugger on most
> platforms to tackle such early initialization problems. On the other
> hand I'm quite cautious in adding pure debug feature in the
> "microkernel" ;-).

Well, I had problems with getting out of crt0.s and didn't have stack
yet. And second place with problem was during enabling mmu. I suppose
this driver could be made to work just after this part.  Am I wrong?

I don't have a JTAG debugger. At least not yet, so I use those macros
as a substitute for it.

Anyway I didn't propose adding much debug messages but only a tool for
that could be used if someone would need to debug early boot process
like me. And only with a dedicated option to enable it.

Generally an idea of dummy serial driver that would write to memory if
UART is not available is nice, but it would not help me much as on
Raspberry Pi there is UART available.


...

> Don't get me wrong, striving for the stars is welcome, but I think the
> goal of having a generic kernel image for all RPIs or even all ARM
> devices is a bit too ambitious right now.
> Although, Linux ARM developers are working on it since many years,
> they aren't there yet. Look at current RPI distro images like Raspian,
> they deliver at least two different kernels _and_ multiple device
> trees. The bootloader code has to decide, which one is loaded.
> Currently, there is no generic convention followed by all SoC/board
> vendors, bootloaders etc.. We have to be pragmatic here.

Ok.

> Given the current state of e.g. the Rasperry Pi universe, where you
> have to decide what needs to be loaded, I do not see in general the
> advantage to differentiate in between configuration data and some
> small, statically linked image.

As I understand proper dts is selected by firmware part. I wouldn't have
to decide what to load. I'll confirm that when I have a diffent model at
hand.


...

>>  2. Do you think that creating generic platform driver for ARM (to
>>     support A) that work using informations provided by device tree
>>     support is generally a good idea? What alternatives you consider
>>     better?
>
> All functionality described above is realized using open firmware /
> flattened device tree in Linux and Co. I agree that it is appealing to
> be able to access all the platform data for free. But this only half
> the truth for the following reasons:
>
> # Device tree support was a moving target within the last years
>   with lots of changes in the implementation and in the trees
>   themselfs, it is not forseeable that this will change
> # There are reams of device-specific attributes. Please, have a look
>   at Documentation/devicetree in the Linux kernel. There are over
>   3000 files. The whole "of_" bureaucracy in the Linux kernel
>   shows its complexity.
> # Different device trees and its "generic" language should not suggest
>   that we will have one platform driver to rule them all. There are
>   tons of "platform devices" in the Linux kernel necessary to provide
>   the resources that toplevel devices need. That means for each SoC
>   you still need a specific platform driver that support all the
>   multiplexing units for pins, power, clocking etc.
> # Device trees describe also a lot of relations in between devices.
>   For instance, a device might get its interrupts from the interrupt
>   controller or from a GPIO controller. All routes to some kind of
>   multiplexer device are part of the tree. It is much easier if you
>   want to apply this configuration to a monolithic component containing
>   all multiplexer devices than to split this in multiple components.
>
> To sum it up. I'm not sure whether it is the right way to go to
> support device trees by Genode's ARM platform driver, but I do not
> want to exclude it completely. Maybe I'm wrong and the complexity of
> the core functionality is over-estimated by me.
> Surely we need something comparable at some point. Maybe, it would be
> good to start it as an experiment for one specific SoC.

Ok. I have very little experience and it is very probable that I'm
underestimating the complexity.


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

Thanks again.

Tomasz Gajewski