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)
  • 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.

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.
  • 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

stskeeps 09:50, 1 November 2008 (UTC)

I believe there is a need for change in bringing Maemo more in alignment with "major" distributions. Maemo is it's own, it is targeted towards embedded systems, but on the other hand Maemo runs on systems that are as powerful as the computers these distributions were initially developed on, and many of the typical embedded tricks may simply not be needed and would help seeing Maemo as a combined "embedded system" and an actual Linux distribution - which would make porting much easier.

I agree with mvo's statement (see jaiku discussion), quote "As to what should happen: Nokia should embrace the Debian heritage of Maemo fully and put processes and practices into place that make Maemo a Debian derivative like Ubuntu, only better." I have for this proposal tried to see Maemo as a deriative of Ubuntu. The reasons I've chosen this direction is:

  • The existence of the research project of http://mojo.handhelds.org, sponsored by Nokia
  • Debian, for now, targets armv4t, and mojo has already done the hard work to target typical Maemo device processors.
  • Taking Ubuntu over Debian (for now), gives us upstart along (part of Task:Maemo_roadmap/Fremantle ), which has not been adapted properly (except in Debian experimental) in Debian just yet.

Maemo base includes:

  • 'minbase' Mojo handhelds Ubuntu 'Hasty' (based on Hardy, or later)
    • Motivation: This is a proof of concept. How far and how well performing is a standard minimal ubuntu base image on a N800? Our restrictions is about 250mb flash availiable to us, with ideally space to spare.
    • Details:
      • # cp /usr/share/debootstrap/scripts/hardy /usr/share/debootstrap/scripts/hasty
      • # debootstrap --arch=arm --variant=minbase hasty /target http://repository.handhelds.org/hasty-armv5el-vfp/
      • # chroot /target mount -t proc proc /proc
      • # chroot /target mount -t devpts devpts /dev/pts
      • # apt-get install apt-utils udev
      • # cd /dev; /sbin/MAKEDEV fb0 fb1 and such.
      • # apt-get autoclean; apt-get clean
      • add in a couple of boot scripts from and framebuffer console kernel drivers from Deblet
      • Now you have a bootable minimal ubuntu image (tested on N800 with bootmenu with linuxrc ability), with full coreutils and bsdutils, etc.
    • Performance: From selecting in boot menu to boot, 12 seconds to get to framebuffer console login, with ext3 mount, udev and all.
    • Size: uncompressed 131mb but, mkfs.jffs2 -r /target -o maemo-r.jffs2 -e 128 -l -n , 43.2m in JFFS2.
    • Contents: http://bsd.tspre.org/~stskeeps/minboot.txt
    • Other examples, http://bsd.tspre.org/~stskeeps/ubuntumin.txt (69m jffs2)
    • Discussion: Is busybox really needed on a tablet? In initfs, sure, but in actual running? Having sane coreutils and bsdutils (and debconf) -really- helps porting. Now that dash exists, is there a reason for busybox as sh?

Maemo SDK

stskeeps 17:31, 31 October 2008 (UTC)

The SDK is a basic thing of developing for Maemo. But there are occasional horrorstories. My idea of a SDK is the following (some which may already be pre-existing):

  • Easy setup SDK. SDK contents should be the Maemo base OS, with libraries and headers enough to get any application compiling that should work on Maemo "R". SDK should be a build box with developer friendly tools to get things running.
    • Motivation: You shouldn't have to go through hoops to get Scratchbox + Maemo minimal base + SDK (dev packages, really) going (general motivation, I don't have a proper example right now, other than the multiple .sh's to run and such..)
  • A Maemo "R" SDK may have Nokia specific dev packages but developers should be encouraged to develop for the Maemo minimal base + SDK combination, and Nokia specific dev packages should strive towards non-device-specific standardization of the interfacing if possible (a BME dev package may not be relevant on other devices).
    • Motivation: Maemo has great possibility to become a general platform for tablet like devices, and the possibility of additional device platforms which also embrace the Maemo minimal base + build-essential + dev packages direction will cause Nokia devices to have additional applications as well.
  • Embrace N800/Device emulation (http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/) and set up emulator to have sbrsh access from first boot, to avoid stupid qemu bugs. This makes it possible for users to instantly test their applications on a emulated device. Try to avoid Xephyr for instance and trying to make the SDK act like a tablet - we have an emulator for that.
    • Motivation: It's much better when you can test on an emulated device instead of dealing with a SDK trying to act like it's one.
  • Work on easy deployment of developed packages (# sb-copy-to-tablet -i usb, -i emu, etc) or running in similar manner to sbrsh with NFS and stuff.
    • Motivation: Easy development ability, and it's a question that's often seen when people start developing for Maemo (how do we transfer to the device? Try see Visual Studio's deployment ways)
  • Embrace VMware Applicances/VirtualBox with SDK + Emu inside, for windows / other OS users to get developing for Maemo "R".
    • Motivation: Linux isn't the only platform people use for development.
  • There should also be no hoops towards converting your tablet into having exact same dev packages and running/compiling on device
    • Motivation: The SDK should be a buildbox and base for transferring packages, and help with emulation and deployment, not be a closet tablet emulator. The tablet should be able to be a place of development as well, and the same dev packages and sdk tools will work on tablet too.
  • Packages for Maemo should not expect Scratchbox to be where they're compiled (I've seen examples of this amongst Nokia code.)
    • Motivation: Increases portability of Maemo platform. There might be some day people compile on ARM boards instead directly.
Retrieved from "https://wiki.maemo.org/Maemo_Reconstructed"