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 <[email protected]> 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
[email protected]
https://lists.genode.org/listinfo/users
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
