Hi everyone,
I was reading the 2020 reflections on Genode.
Here is my plans for 2021 related to Genode:
1) Make the RK3399 port complete which for example includes PineBook Pro. HDMI will be easy, and I think eDP will be as well. The question is if doing it with DDE-Linux or from scratch. The RK3399 port is really only a exercise for me , since we already is on our way with a native port of RISC OS. But I guess a port of Genode can be useful for others. 2) RISC OS kernel running on top of base-hw , big project: 2a) The RISC OS kernel is written in ARM assembler, I will attempt to bring it over to C. 2b) Replace HAL with Genode facilities. 2c) Write some kind of emulation layer. RISC OS uses SWI for everything and that will not work on 64bit. It will be important to be able to run 32bit programs. 2d) Bring up Genode on all future aarch64 systems! 3) Bring up Genode on A64... I guess it might have been done partly already. It is the SoC that PinePhone is built on. I have been in the team porting RISC OS to A64 , so I know a few things. The only thing we haven't done natively is graphics. The only doc for DE 2.0 is a register description (VERY large document). No appnotes which makes it close to impossible to do without looking at BSP. We used simplefb , that is , starting graphics in uboot and use the resulting framebuffer. NetBSD also does graphics this way. 4) Learn to use the DDE-Linux.
I hope that 2021 will be healthier :)
Best regards, Michael Grundiitz
Hi Michael,
thanks for sharing your ambitious plan. It is intriguing!
On 18.12.20 15:22, Michael Grunditz wrote:
Make the RK3399 port complete which for example includes PineBook Pro. HDMI will be easy, and I think eDP will be as well. The question is if doing it with DDE-Linux or from scratch. The RK3399 port is really only a exercise for me , since we already is on our way with a native port of RISC OS. But I guess a port of Genode can be useful for others.
I sense that DDE-Linux will become a hot topic the in 2021 and really hope that the advances of tooling and methodology I hinted at in my email, will make our life easier. Great to know that you anticipate this direction.
we haven't done natively is graphics. The only doc for DE 2.0 is a register description (VERY large document). No appnotes which makes it close to impossible to do without looking at BSP. We used simplefb , that is , starting graphics in uboot and use the resulting framebuffer. NetBSD also does graphics this way.
My expectations regarding the Allwinner documentation were low. The happier I was about the result of a quick web search [1]. That looks quite useful to my untrained eye.
As a general plan, I will expose myself to the DDE-Linux approach as much as possible to streamline the developer experience as much as I am able to, and to document my work as I go. So I will definitely port the graphics driver of the Linux kernel as a part of this challenge.
That said, by skimming over the DE document, I'm really tempted to play around with the features directly, mapping them to Genode APIs in ways that would be difficult when solely reusing the Linux driver code. But I would not start with that before the Linux driver is working as a base line.
By the way, to get started with the DE, the code of the p-boot loader [2] looks like a nice starting point. It is far from trivial. But it is not daunting either.
[1] https://duckduckgo.com/?q=display+engine+allwinner+pdf [2] https://megous.com/git/p-boot/tree/src/display.c
Cheers Norman
-
Michael Grunditz -
Norman Feske