Roadmap 2019

[Bob Stewart]

Hi Tomasz,

I'm working on implementing a base-hw kernel on a Cortex A53 platform 
(not Rpi) which is what the Rpi 3x is based on. So, that means a 
significant amount of work to convert from the existing Genode code 
supporting the armv7 architecture to support the armv8 architecture. I'm 
focused initially on only the aarch64 instruction set, but will later 
add support for aarch32. This is a retirement project for me so my 
progress is not driven by any great need and is slow. After about six 
months of casual working I'm at the stage of debugging a virtual memory 
translation table enhancements need to support 64-bit memory (a new 
Level-0 table in the page table code in lpae.h). The means all the 
assembly code changes required have been made (and about 12 other areas 
of change) and I clean compile a from a log run script.

For debugging at this level, you really only have two choices: Either 
delve into the ARM hardware debugging facilites (CoreSight) or insert 
small pieces of code to poke variable values or a trace number into a 
currently unused region of memory. Code like:

             using ull = unsigned long long;
             ull volatile * debug_ptr = (ull *)0x91000600;
             *debug_ptr = MAX_ENTRIES;
             debug_ptr += 0x01;
             *debug_ptr = BLOCK_SIZE_LOG2;
             debug_ptr += 0x01;

if your booting into uboot to start up, you can inspect the memory 
region through uboots' md command. Breakpoints can be implemented with 
the assembly code line:  asm volatile("hlt #01\n"); . Objdump gives you 
the assembly code listing if you need it.

I sincerely hope Genode does not implement a version of the Linux DT. It 
is an error prone approach developed many years ago in the embedded 
world. There are more elegant, syntax checkable, configuration 
description approaches available today.

Let me know if I can help with any compile/link issues you have, I 
probably came across most of them in my work to-date. I'm using a Linaro 
tool chain for aarch64. There is a separate one for aarch32 which I 
don't currently use.


Bob Stewart


On 1/2/19 5:22 AM, Tomasz Gajewski wrote:
> Hi,
>
> My main observation is that every aspect of modifying of and integrating
> with Genode should be made as easy as possible. Due to the nature of
> Genode there are many things that are different from commonly known
> solutions and I think especially those parts should be made more easy to
> handle. Below I enumerate those that I find important.
>
>
> Norman Feske <norman.feske at genode-labs.com> writes:
>
>> Please don't hesitate to share your thoughts. You may consider the
>> following questions:
>>
>> * What are your ambitions for 2018?
> Recently I've purchased RPI 3B+ - it is my first arm device and
> currently all aspects of making Genode work on it are on my radar.
>
> I've seen comments from Alexander Weidinger about his attempts and
> looked briefly at his work and he started from copying all rpi specific
> code to rpi2 version. Given that until now there is about eight variants
> of Raspberry Pi I felt that this shouldn't be the way to go. So I
> started checking how Linux is handling different raspberry pi boards
> (and other ARM variants) and found out about device tree and its
> usage. So my first ambition is to integrate device tree usage into
> Genode. I think that work could make much EASIER integration of devices
> with Genode.
>
> Unfortunately my attempts currently are a seqence of different
> problems/surprises which I try to overcome one step after another and it
> isn't going as smooth as I expected. Currenlty I'm forced to work with
> assembly code after almost 25 years (and it was for 80286). I'll write
> more about it in another thread along with questions that maybe someone
> will be able to answer.
>
>> * Which areas of Genode would you like to see improved?
>>    How would you possibly contribute to these improvements?
> Bare metal
>
> In my current work with RPI (I'm attempting to make base-hw work) it
> would be very useful to have some very early debugging facility -
> probably serial output. Given that currently I'm not even able to
> successfully execute code from crt0.s I'd like to see it (this output)
> initialized there although maybe I want too much. It took me two days
> (due to my lack of experience) to have any diagnostics from that code -
> I can enable and disable leds attached to gpio pins :-). So early output
> from initialization enabled in some standard way (build flag?).
>
>
> Porting
>
> Writing initialization files that define access to all resources and
> routing rules is something completely Genode specific and requires good
> understanding design principles behind capabilities and resource
> providers, etc. Even though I think I understand concepts well I find it
> hard to analyze all dependencies (at least it was hard for me in
> Sculpt). I think that for "typical" ported software it can require only
> some of "standard" resources and configuration could be made by clicking
> options what given application is allowed to access. Something similar
> to privileges on current phones. I know that Genode solution is better
> but only internally and currently is more complicated. Maybe this could
> become part of SDK. Maybe even SDK should be "generated" for concrete
> list of required resources and consequently APIs?
>
>
> Inspectability
>
> It should be easy to inspect running system internals. At least after
> enabling some debug mode if that can make system slower or less safe. I
> know that you know that it is important but I wanted to emphasize that.
>
>
> Sources
>
> I find difficult to find relevant places in sources when I look for
> something. Currently I heavily use find with grep:
>
>    find ~/projects/genode/genode \
>      -path "*/.git/*" -prune -o \
>      -path "*/depot/*" -prune -o \
>      -path "*/contrib/*" -prune -o \
>      -path "*/build/*" -prune -o \
>      -path "*.run" -prune -o \
>      -type f -exec egrep --color -nH -e 'pattern' {} +
>
> but it would make life much easier if there was some integration with
> some IDE (maybe there is) that would provide some notion of project
> where files would be automatically included to project if they are used
> to build concrete target. I'd like to be able to limit search only to
> files used e.g. for "run/log for rpi with kernel hw". Although in this
> case I have no idea how to achieve this :-) Some additional output from
> make as build system is built on top of that?
>
>
> Knowledge base
>
> Although there is a great book and greate articles about different
> design desicions are made and informations about each release it's hard
> to quickly find informations about what is currently working/tested,
> what is supposed to work and what not and why.
>
> I'd like to have some overview on state of particular configurations as
> some matrix with functions, boards and kernels.
>
>   High level examples:
>
>   * support for rpi is only for base-hw and foc, but not for Nova.
>   * virtualization is supported only on Nova (I think)
>
>   Low level:
>
>   * real case I stumbled some time ago - tried some filesystem tests and
>     for linux target there where errors for 'unlink' (if I correctly
>     remember) that it is not implemented. In such case I'd like to know
>     if it is not implemented because nobody did that yet or there are
>     some obstacles that make it hard or mayby dangeroues (it was
>     definitely about deleting so maybe). I know that such detailed
>     information cannot be accurate if it was maintained by a human
>     (probably I've messed this sentence) but it could be somehow
>     assembled from results of automatic tests that should be made public
>     (maybe they are but I just haven't found it) and marked with some
>     status about expected results for each configuration.
>
>
>> * Which technical topics do you find tempting?
> Currently ARM devices as it is completely new subject for me.
>
>
>> * Do you have further ideas that would help making Genode relevant
>>    at a larger scale than today?
> For enthusiasts: make changes that would allow to contribute more
> quickly - allow to make doing everything easier :-)
>
>
> For business I think it is important to find some niches where Genode
> could shine. Probably that should be use cases:
>
>   * not very complex - because otherwise initial cost and risk would be
>     too high.
>
>   * where security is important.
>
> Additionally I think that some comparison of efficiency of some
> workloads (e.g. against linux) would be needed for business to consider
> using Genode as a base for solutions. I'd consider efficiency problems
> as a high risk of using Genode if I wasn't presented some results. This
> information would be useful for everyone although I don't know if
> current results wouldn't be somewhat discouraging. I hope not.
>
>
> Tomasz Gajewski
>
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users