Maemo Reconstructed

This wiki page has the purpose of bringing together developers both internally in Nokia and community developers, who have an interest in the Maemo platform. The goal is trying to reach a vision of how a future Maemo system architecture could be like, that's satisfying to both Nokia and community. This is meant as the actual low level -technical- system goals (use of upstart, busybox specifics, initfs or not) not high level items such as "ogg in media players" or "open source everything".

This discussion was sparked by:


Contents

Kernel

Initfs

stskeeps 16:06, 31 October 2008 (UTC)

I believe that a initfs is a useful thing for a tablet. It can help you in many cases when the main system has crashed for whatever reason, and help you fix the problem or rescue your data. For Maemo "R" I believe it should contain the following things:

  • Boot menu alike fanoush's bootmenu , with a /etc/bootmenu.d like setting (inspiration from grub menu.lst, http://internettablettalk.com/forums/showthread.php?t=23051)
    • Motivation: Cloning to SD is a popular activity amongst community users, to gain more application space. A bootmenu item system should be brought to Maemo to avoid a lot of hacks laying about for the same thing, which makes it difficult for SSU to deal with.
    • Note: Bootmenu should be unintrusive and invisible to the "normal" user (but may be activated to be more verbose in control panel)
  • Rescue menu, possibly alike http://www.youtube.com/watch?v=h24f2YjzWBE (or in text form). That can both activate certain services from initfs or set boot settings such as framebuffer console or other settings for the system (think F8-while-boot in windows.)
    • Motivation: Many community users often run into the dreaded reboot loops. This can be solved by having various things in initfs to solve the general problems. One can be usbnet/g_serial (for emergency shell - or PC accesory programs for dumping the files from NAND /home/user/ through usbnet telnet) , acting like a file storage (expose LUN of MMC cards), dump NAND contents to files on MMC, - the possibilities are endless. These abilities should be modelled with a "plugin" structure, to encourage innovation in this area.
  • Contain closed-source hardware specific firmware, drivers (cx3110x, etc), daemons (BME, hw watchdog kicker), but should not try to load wifi drivers and such initially except for FS drivers needed to boot, leaving it up to the post-initfs OS to do this.
    • Motivation: Fact is, there as certain trade secrets and we're not going to get around them easily. Let's have them in initfs as a kind of "Hardware Abstraction Layer" for each kind of device. Kernel drivers should ideally be open source but this may not always be possible. Recompilation services for newer kernels could be considered - maybe easier access for community versions? (automated "I would like this driver for kernel X, and I hope that the API didn't change inside the kernel so it breaks..", output .ko)

Behaviour and documentation:

  • Communication protocols with closed source daemons should ideally be documented (it should be possible to get remaining battery time and bars to show and such from BME.).
    • Motivation: This will satisfy most OSS OS developers, but the problem about closed source daemons is that there should optimally be updates, even for old devices (backwards compatible daemons maybe, maybe automated build services again/community/head contributors access to recompile, so Nokia wouldn't have to invest time.)
  • The initfs should mount the rootfs at /mnt/rootfs, pass on control to a /linuxrc (which runs in initfs namespace), which will then deal with the typical items such as pivot_root and passing control to init/upstart.
    • Motivation: Many of the items in current init/linuxrc in traditional initfs is very Maemo specific. If someone wants to run Mamona, Angstrom or Poky, why not let them without having to do Maemo-specific tricks to unwrangle things to look like they were just booted from kernel?
  • Daemon communication from post-initfs should rely on daemon unix sockets being in /mnt/initfs/tmp/, not /tmp as many typical
    • Motivation: Other OS'es than Maemo has a tendancy to clean out /tmp when booting.
  • Busybox+uclibc to ensure minimal initfs. Toolkit for the right combination should be as easy to get as Maemo SDK.
    • Motivation: This will definately aid in the development of rescue menu abilities.
  • Initfs should be updated with apt-get in Maemo "R", but updated (/mnt/initfs paths in packages?), not reflashed with a static image.
    • Motivation: This will ease work on rescue menu abilities, work on pre-OS processes.
  • Basic device/Mobile service DSME should be open sourced, but may load modules of closed source modules (CAL access, watchdog kicker, etc), and DSME protocol should be documented and the modules associated with it (CAL access seems to be a touchy subject though).
    • Motivation: DSME is a good part of a mobile platform (process watchdog, etc), but needs documentation of the communication protocol (even though most of it has been reverse engineered) for community OS developers to work properly with it. Can it really be true things like Advanced Backlight (http://adv-backlight.garage.maemo.org/) has to use undocumented DSME protocol to do what it should?

Initfs should be a initial step towards booting, a rescue possibility and a way to get the system in a sane state to get Maemo "R" or anything else started.

Maemo Minimal Base

Retrieved from "https://wiki.maemo.org/Maemo_Reconstructed"