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@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@lists.genode.org https://lists.genode.org/listinfo/users