Hello Genodians, Last year was a good year in Genode for me. I poke around with it at the hobby level, but this year I saw the drivers system substantially re-worked and I was able to successfully port a Linux driver.
What directions are you most excited about?
Although many others are excited about Sculpt on phones and SOC/SBC scenarios, I remain excited about the prospect of improving Sculpt on “conventional” machines like laptops and (mini)towers. My thoughts on where things could be:
1) The default Sculpt image can probably be made to boot already on almost any x86 system. A few tweaks could help such as allowing command-line arguments from the boot loader to boot in “safe” mode, forcing fallback to the boot loader’s frame buffer.
2) The default Sculpt configuration is great and provides a low barrier to new users to at least try Sculpt. But to work seriously in Sculpt one wants to install a VM, which is many steps, and to virtualize and already-installed OS is even more steps. It would be fantastic if one could, out-of-the box, virtualize an installed OS. If that’s too much, it might be worth curating USB stick images with pre-installed VM partitions.
Which topics do you deem as interesting to explore yourself?
I might poke around with (2) above, at least trying to follow the existing instructions.
I may also try to port some more Linux drivers. I’m curious where Sculpt will go with that - will it be towards live selection of drivers at boot time, like in most Linux distros, or is the idea for lean purpose-built images that contain only the drivers necessarily for a given system?
Happy new year to all!
Hello everyone, After much time of inactivity, I want to work on Genode Sculpt os, in those last 2 years, I worked on android kernel development intensively. Now, Norman, I have some questions for you: 1) do you want to port Genode also on other Smartphone models? 2) Do you think it would be possible to integrate Genode for working with 4/5G?
for 1), I think it could be possible to boot genode on other smartphone, ideally, we could try to change the android boot image: we maintain the header (or the aboot [the android bootloader/third stage bootloader] will refuse to load it] but, instead of taking the android kernel code, we write the genode code (an objdump trick will be helpful). From next week, I'll work directly on this, by using kexec on my modded android smartphone; Note that is also possible to do that at a lower level, with some qualcomm chipset (sdm845 and similar, if you search windows 10 on sdm845, you will see that many peoples have played with efi in order to allow the running of different OSes, this is possible only on a limited plethora of smartphones, but could give additional life to the Genode project).
for 2), the problem is pretty Big, I have worked on AT commands, but those are used for GSM/UMTS, for LTE and other, Qualcomm uses QMI, and the relative driver, IPA, which is pretty more complicated, so, if we want to have something for covering new smartphone models, I think that some drivers should be added to Genode, I am currently working on similar projects.
I would like to contribute in the creation of a third operating system for the mobile world, even if this will be extremely difficult, especially if we consider other components that I have read in your first email. Do you also implement the usb dwc3 driver? I think that the right direction can be to move on to the embedded world, the challenges are pretty big, for the power consumption, Qualcomms adopts a series of complex proxy voting drivers as well as some specific drivers, which change from model to model.
Happy new year to everyone.
Il giorno gio 29 dic 2022 alle ore 17:21 Colin Parker cvparker@gmail.com ha scritto:
Hello Genodians, Last year was a good year in Genode for me. I poke around with it at the hobby level, but this year I saw the drivers system substantially re-worked and I was able to successfully port a Linux driver.
What directions are you most excited about?
Although many others are excited about Sculpt on phones and SOC/SBC scenarios, I remain excited about the prospect of improving Sculpt on “conventional” machines like laptops and (mini)towers. My thoughts on where things could be:
- The default Sculpt image can probably be made to boot already on almost
any x86 system. A few tweaks could help such as allowing command-line arguments from the boot loader to boot in “safe” mode, forcing fallback to the boot loader’s frame buffer.
- The default Sculpt configuration is great and provides a low barrier to
new users to at least try Sculpt. But to work seriously in Sculpt one wants to install a VM, which is many steps, and to virtualize and already-installed OS is even more steps. It would be fantastic if one could, out-of-the box, virtualize an installed OS. If that’s too much, it might be worth curating USB stick images with pre-installed VM partitions.
Which topics do you deem as interesting to explore yourself?
I might poke around with (2) above, at least trying to follow the existing instructions.
I may also try to port some more Linux drivers. I’m curious where Sculpt will go with that - will it be towards live selection of drivers at boot time, like in most Linux distros, or is the idea for lean purpose-built images that contain only the drivers necessarily for a given system?
Happy new year to all! _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Edoardo,
Now, Norman, I have some questions for you:
- do you want to port Genode also on other Smartphone models?
since you are addressing me personally, I'm not planning to lead such an effort. My high motivation behind the PinePhone line of development stems from the following three points.
1. Proving that Genode can accommodate the (in my opinion) most demanding device category besides PCs. Running Sculpt on the PinePhone brings this point home. Now we know what it takes, and we dispelled countless technical and architectural risks along the way.
2. Attaining the guidance documentation needed by 3rd parties to port Genode to other platforms. For me, not the working code but the Genode Platforms [1] document is the most essential outcome of this work. It essential removes Genode's core team off the critical path for platform enablement.
3. Personally using Sculpt OS on both my laptop and my mobile companion device, satisfying my desire of ultimate control over the devices I rely on.
[1] https://genode.org/documentation/genode-platforms-22-05.pdf
Enabling a second smartphone myself would not contribute to these objectives.
Instead, having an independent developer (or team) proving that the "Genode Platform" documentation fulfills its purpose would be much more interesting to me.
Given this rationale, I would (very) gladly assist someone outside of Genode Labs with such an effort. Should you decide to go that way, you can count on my support.
for 1), I think it could be possible to boot genode on other smartphone, ideally, we could try to change the android boot image: we maintain the header (or the aboot [the android bootloader/third stage bootloader] will refuse to load it] but, instead of taking the android kernel code, we write the genode code (an objdump trick will be helpful). From next week, I'll work directly on this, by using kexec on my modded android smartphone; Note that is also possible to do that at a lower level, with some qualcomm chipset (sdm845 and similar, if you search windows 10 on sdm845, you will see that many peoples have played with efi in order to allow the running of different OSes, this is possible only on a limited plethora of smartphones, but could give additional life to the Genode project).
Reading that paragraph, I feel that I was very lucky that the PinePhone just allows me throwing an SD-card into the phone and boot from that. ;-)
If you happen to find a workable way to boot Genode on a broader range of consumer devices, that would certainly be appreciated.
- Do you think it would be possible to integrate Genode for working
with 4/5G?
We have used the MBIM protocol in earlier work [1] but haven't enabled QMI so far.
For the PinePhone, I picked the path of least complexity. By talking over UART with the modem, we don't need a USB host-controller driver for basic features like telephony. So when booting the phone up to feature-phone functionality, Genode does not even need to start an USB HCD driver. Additionally, the UART interface gives us the principle opportunity to let the SCP (a little system-control processor besides the ARM core) interact with the modem.
I agree, for a more general solution there will probably be no way around using a binary protocol over USB.
[1] https://genode.org/documentation/release-notes/21.02#LTE_modem_stack
As a bottom line, a porting effort to other smartphones is beyond the scope of the road map for 2023. But it goes without saying our actual ambitions go far beyond the PinePhone.
Cheers Norman
Hi Colin,
But to work seriously in Sculpt one wants to install a VM, [...] It would be fantastic if one could, out-of-the box, virtualize an installed OS.
this reminds me on the article [1] by Johannes, who created Linux vs. Linux-on-Genode dual-boot scenario.
[1] https://genodians.org/jschlatow/2021-04-23-start-existing-linux-from-sculpt
I’m curious where Sculpt will go with that - will it be towards live selection of drivers at boot time, like in most Linux distros, or is the idea for lean purpose-built images that contain only the drivers necessarily for a given system?
It is not clear-cut.
Speaking for the PC, some of such driver decisions are already taken at boot time, e.g., the Intel display driver is started only if an Intel graphics device is present. The same goes for the NVMe and AHCI drivers. I think this already works quite well. Should the arsenal of drivers become much larger - e.g., covering AMD in addition to Intel - we could consider providing dedicated images.
On ARM, each board requires a custom boot infrastructure and a kernel compiled for the board. So images are board-specific and don't need much probing.
Both directions are possible and useful. The modular nature of Sculpt gives us the freedom to decide case by case.
Cheers Norman
-
Colin Parker -
Edoardo Mantovani -
Norman Feske