Dual-booting Mer on Nokia N900

As of Mer 0.17testing10 we have an image that is fairly easy to try out on Nokia N900. This guide is for advanced users and there is NO WARRANTY. It might turn your N900 back into the crazy guy from this video or chew out your microSD, so be careful.

You will need:
* A microSD
* A SD/microSD card reader for your PC
* A Linux installation on your PC.
* A copy of a Mer rootfs for N900 (0.17testing10)
* A copy of the files in your /lib/firmware from your N900. This includes WiFi and Bluetooth firmware.
* PR1.0, PR1.0.1 or PR1.1 on your N900
* That you have installed fanoush's bootmenu (dpkg -i it and run 'Install bootmenu' application icon)

Instructions (must all be done as root):
* Partition your microSD to first partition being Linux and format it as ext3 using mkfs.ext3.
* Mount the ext3 partition on your PC, let's say in /mnt/mer.
* Make sure using 'mount' that your ext3 partition is -not- mounted 'nosuid' or 'nodev'
* cd /mnt/mer
* tar --numeric-owner -pzxf /full/path/to/mer-armel-n900-rootfs-v0.17testing10.tar.gz
* cd lib/firmware
* cp in the files from /lib/firmware from your N900
* umount /mnt/mer
* Make a file "mer.item" in /etc/bootmenu.d on your N900, containing:

ITEM_NAME="Mer (external SD, partition 1)"
ITEM_ID="mer"
ITEM_DEVICE="${EXT_CARD}p1"
ITEM_MODULES="mbcache jbd ext3"
ITEM_FSTYPE="ext3"
ITEM_FSOPTIONS="noatime,ro"

* Reboot your device, have the keyboard slid out. A bootmenu will appear where you can select Mer with the cursor keys.
* Mer booting.. wait for touchscreen calibration step
* And then you can run through the first boot wizard
* And a non-accelerated Mer desktop appears.

What works:
* WiFi
* Touchscreen
* Charging
* Watchdog handling

Of closed source blobs used in Mer (for N900):
* DSME (open source) with libcal (closed source) running from the Maemo5.0 rootfs
* BME running from the Maemo5.0 rootfs
* Firmware files for WiFi and Bluetooth chip amongst others.

Either way, I hope you enjoy playing with an alternative OS on your N900. Feel free to report bugs at http://wiki.maemo.org/Mer/Releases/0.17 and talk to us on #mer on irc.freenode.net if you'd like to contribute to Mer.

To shut down Mer, either sudo reboot or pop the battery.

Making flashable rootfs's for the N900

For the N8x0 the way to create flashable rootfs's - that is, rootfs's usable in flasher-3.5 -r rootfs.jffs2 -f -R was through these two steps:

mkfs.jffs2 -d $ROOTFS_DIRECTORY -l -n -e 128KiB
-o rootfs.jffs2.raw
sumtool -l -n -e 128KiB -o rootfs.jffs2 -i rootfs.jffs2.raw

Now that the N900 uses ubifs for rootfs instead, how do you do create a flashable rootfs?

You need to make a file, ubinize.cfg:

[ubifs]
mode="ubi"
image="/full/path/to/base.ubi.img"
vol_id="0"
vol_size="200MiB"
vol_type="dynamic"
vol_name="rootfs"
vol_alignment="1"
vol_flags="autoresize"

Then, you run these two commands - you have to grab mtd-utils - Ubuntu Karmic has mtd-utils with ubifs support.

mkfs.ubifs -m 2048 -e 129024 -c 2047 -R 4MiB -r $ROOTFS_DIRECTORY -v /full/path/to/base.ubi.img
ubinize -o /full/path/to/ubi.img ubinize.cfg -m 2048 -p 128KiB -s 512

You can now run flasher-3.5 -r ubi.img -f -R.

What can this information be used for?

* Generate a full snapshot of your NAND rootfs and restore it with flasher after trying out something stupid that failed.

* Flash alternative OS'es onto your N900 NAND.

* Possibilities in rescue menu as in my previous post about bootmenu.sh hook - dump my rootfs to SD and I'll fix it on my PC and reflash it back to my N900.

A small but important update in PR1.1

This is slightly technical, but PR1.1 included a small but interesting patch to /sbin/preinit (part of getbootstate). /sbin/preinit is the first thing that gets run on Maemo5 for N900. Some history first: In the past we've always had to patch initfs or /sbin/preinit in order to get any sort of bootmenu on 770/N8x0(W)/N900. This has changed with PR1.1 - the patches are now part of Maemo5.0!

Besides some patches to aid MMC booting, what is added is few very important lines:

SLIDE_STATE=`cat /sys/devices/platform/gpio-switch/state`
if [ x"$SLIDE_STATE = "xopen" ]; then
echo_g "slide open, attempting to use bootmenu"
[ -f /bootmenu.sh ] && . /bootmenu.sh
fi

What does this mean? This means, that when you have the keyboard slid out at power on, it will look for /bootmenu.sh and try to include it in the boot process. If it doesn't exist, it goes on with business as usual.

This means, you can add have fanoush's bootmenu or your own rescue menu, or whatever could be interesting to have this early in the process.

Thanks to fanoush for his bootmenu and to Peter De Schrijver from Nokia for applying my patches.

A creative use of MADDE: A new way for theme makers to make themes for Maemo5

Recently, three source packages that were published in Diablo times was released in their Fremantle versions which I had waited for a long time for. These are:

* A source package which generates a theme, hildon-theme-variant-example
* This is done on the basis of hildon-theme-layout-5 (also published in Maemo5.0 update2 SDK), a package that provides the GTK theming and how to slice and dice a template into the theme elements.
* The slicers and dicers and dithers are provided in hildon-theme-tools (also published in Maemo5.0 update2 SDK).

hildon-theme-variant-example is CC BY SA 2.5, hildon-theme-layout-5 is CC BY SA 3.0 and hildon-theme-tools is GPL 2.0 for those who are interested in that.

Now, on to what this article is actually about.

What I am going to provide you theme makers of Maemo, is a way to make theme packages similar to how the vendor-provided themes on your device is made. We had this ability in Diablo and now we have it in Fremantle.

There was a catch with the Diablo method - it required you installing Maemo SDK, well, under Linux and this isn't always commonly found on graphics designers computers which typically ran Windows or MacOS X.

Thus, cross-platform solutions like Kontorri's Theme Maker was made which emulated what these packages described are doing. It made a binary Debian package, which could only be uploaded to Maemo Extras in the non-free section.

Normally, developers upload a source package to Maemo Extras and the autobuilder builds it for us.

Now, the ballgame has changed with MADDE. MADDE is a cross-platform Maemo SDK (Linux, Windows, MacOS X), which basically implements just about enough to cross-compile a Qt application. But why is this interesting for theme makers?

I've discovered that it is possible to generate the source package for a theme package within MADDE. What does this mean for your workflow as designers? Let me guide you through a workflow of theme design with the help of MADDE and the Maemo Extras repository.

Requirements:

* Install MADDE on your computer - it's a quite big download but it may be useful when you'd like to wander into Qt development as well. In this example I will be referring to paths from Windows MADDE but it should be transferable to your

* Something to open tar.gz files, such as WinRAR or similar.

* The garage.maemo.org and Extras upload invitation from http://wiki.maemo.org/Uploading_to_Extras-devel. Currently you will need to set a SSH key (write 'blahblahblah' if this is nonsense to you)

* Patience and willingness to learn :)

Workflow when beginning a new theme:

Step 1: Downloading the theme source package template

On this page there is a link that is called Download master as tar.gz. What is this? This is a theme template source package which you can customize to your own needs. Unpack the directory inside this into C:\MADDE\0.5\home\your username. Feel free to rename the directory to your intended theme name.

Step 2: Executing MADDE

In your start menu (or whatever your OS calls it's launcher), there should be MADDE -> MADDE Terminal.

You will now end up in your 'home directory' in MADDE, which is C:\MADDE\0.5\home\your username.

In there, you can 'cd directory name' where directory name is the name you gave the folder/directory from before.

Step 3: Customizing the source package template, basics

In the folder you should now 'sh try_it_out.sh'. This will ask you a couple of questions. You only have to do this once.

It will ask you the following questions:

* What should the package name of your theme be? (Example: hildon-theme-example)

* What should be theme name be? (Example: My example theme)

* Who is the maintainer of this theme?

* What should the directory name be (Example: example)

It will then set up the theme template.

Step 4: Customize the graphics - the fun step!

You can see in the directory several interesting places. The primary place for your work is in the template directory. This contains template.svg (SVG version of the basis template) and template.png (PNG version of the template). While it is up to you which one you want to edit, remember to always export template.png from the SVG.

Similar directories, icons, background images and other things to customize can be found in the applications directory.

Step 5: Building the source package

When you're done customizing, you can finally build your source package. In MADDE, you can do this:

username $ mad dpkg-buildpackage -S -us -uc -d

This will generate a .dsc and .tar.gz in the parent directory which you can use in the next step.

Step 6: Uploading to Maemo Extras

You can now upload this .dsc and .tar.gz file to Maemo Extras through the Maemo Extras Assistant. The autobuilder will then build the theme package for you and your theme will show up in Extras-devel.

As a bonus, anyone can base their themes upon yours as they have the 'source code' of your theme (under CC SA BY 2.5 conditions) - something not possible with ThemeMaker.

There are probably more maintaining issues which I hope the real theme makers will explore such as adding new versions to changelogs and such and tell about in their blogs.

If you have problems with any of the steps, prod me (Stskeeps) on #maemo , irc.freenode.net or comment this post.

Enabling RTC (clock), battery charging and watchdogs on alternative OS'es on N900

Just spent a day getting RTC (clock), battery charging and watchdogs working for Mer on N900 and I thought I'd like to share how it was done for those of you wanting to run other OS'es on N900. The watchdog package in typical Debian does not by default work with two watchdogs, so we are using DSME.

This example assumes that you have made a /mnt/initfs directory on your rootfs and that you're running this from fanoush's bootmenu which will put the Maemo5 root file system in /mnt/initfs

You should as early in your boot process (after udev has been started), run the following script:


# Set up initfs environment


hwclock --hctosys

chroot /mnt/initfs mount -n -t proc proc /proc

chroot /mnt/initfs mount -n -t sysfs sysfs /sys

mount --bind /dev /mnt/initfs/dev

chroot /mnt/initfs mount -n -t tmpfs -o size=1M,noatime tmpfs /tmp

chroot /mnt/initfs mount -n -t tmpfs -o size=256k,mode=0755,nosuid,noatime tmpfs /var/run

# Check current boot state. Could be 'USER'
export BOOTSTATE=`chroot /mnt/initfs getbootstate 2>/dev/null`

touch /mnt/initfs/tmp/$BOOTSTATE

echo $BOOTSTATE > /mnt/initfs/tmp/STATE

chroot /mnt/initfs /sbin/dsme -p /usr/lib/dsme/libstartup.so &

until chroot /mnt/initfs waitfordsme; do

sleep 1

done

LOGGER='/usr/bin/logger -s -tBME'

SYSFS_VBUS_PATH=/sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus


# check dead battery pre-charge

if [ $(cat $SYSFS_VBUS_PATH) -eq 1 ]; then

chroot /mnt/initfs /usr/sbin/bme_RX-51 -b

case $? in

0)

$LOGGER -pdaemon.notice 'precharge -> ok'

;;

2)

$LOGGER -pdaemon.crit 'precharge -> power off'

exit 1

;;

*)

$LOGGER -pdaemon.crit 'precharge -> failure'

;;

esac

fi

# Start battery management entity
chroot /mnt/initfs /usr/sbin/bme_RX-51 &

# Bonus: To get hald-addon-bme working (bad bad voodoo). We need to test if toggles_w's hald-addon-bme replacement works on N900.
# dpkg-repack hald-addon-bme from rootfs and dpkg -i it
mount --bind / /mnt/initfs/mnt/new_root
chroot /mnt/initfs ln -s /mnt/new_root/tmp/bme-dbus-socket /tmp/bme-dbus-socket
ln -s /mnt/initfs/tmp/.bmesrv /tmp/.bmesrv
ln -s /mnt/initfs/tmp/dsmesock /tmp/dsmesock

On the perceived openness of Maemo, part one: Your target audience

Some time ago, I stumbled over a rather aggressive comment in Quim's blog, which made me wonder if we are approaching the topic of open sourcing Maemo components in the right manner.

The comment in question took big offense to the way the page Why_the_closed_packages presents reasons for keeping things closed source and it appeared to me that the meaning of the different reasons in his world view was completely different to how I perceive them. I usually classify myself as a open source lover with a realistic sense of why there sometimes has to exist closed source software but I'll try to remain objective and respectful to both sides of the spectrum in this article.

To further understand this problem, I asked Paul Fertser of #maemo – one of the people I've had most intense debates with about licensing issues in Maemo and why things are the way they are, to read Why_the_closed_packages sections 1 and 3 (Reasons, Requesting the opening of closed components) with his bias towards free software and document his thoughts of it. The quotes are presented with his permission. His background is in the OpenMoko community which is on the more liberal end of the open source software spectrum in the mobile Linux space.

Why did I ask someone with a huge bias to do this? Because he has been showing willingness to try to understand why things are they are in order to make more sense of the open source situation in Maemo – and that is something I respect. In his reaction to WTCP, he writes pretty clearly why it is useful to approach it with this angle:

“I assume that the purpose of the page is to make the process of open-sourcing in particular and development in general efficient and constructive.

That means that neither your time, nor time of your colleagues should be spent on void talks about something you can't change anyway and that people proposing opensourcing a particular component should concentrate on providing the most relevant arguments instead of taking part in religious debates.

To fulfill this purpose the page should be understandable and acceptable by the target audience.“ --Paul Fertser

The people who are going to make the most noise about open source policies are who our target audience of this page should be in order to be able to move away from time consuming religious debates and into constructive debates and discussions. That said, the page should also target developers for whom open sourcing a component would help their development.

The important thing is to spend more time on the actual open sourcing process than in time consuming discussions.

PF suggests some guidelines for the page, which I quote verbatim as see mostly no argument in what he states, emphasis mine:

First of all, you mainly target developers. And you take into account that among those interested in open-sourcing there will be a considerable amount of "free software zealots" who are sceptical and irritated about the proprietary software by default. So to avoid aversion that will be later reflected upon you and your fellows in form of negative emotions and useless quarrels i think it would be beneficial to follow several guidelines:

* Write from a hacker point of view, that way they'll feel you're "with" them and not "against", that makes people feel much more comfortable, take emotional response of your readers into account.

* Avoid buzzwords and formal style, a convincing page should look nothing like a press-release as we all know everything that comes from a PR department smells like(added by editor) lies.

* Add technical details, that makes you look understanding the issues in deep, increasing credibility of other information.

* Do not use really questionable arguments, that's like a red flag to a bull.

* Take into account many developers do not understand business and business reasons, so those should be explained in a more detailed way.

To me it seems it would be nice to have some introductory words on the page, at least that would make me less irritated and more constructive right from the beginning. I would gladly accept something like:

"We all know proprietary software sucks. Indeed it does, many of the headaches could have been avoided if there was less of it. Unfortunately, the reality is working in such a way we have to make compromises, that's unavoidable. On the other hand, there are actual possibilities to free more of Maemo and Maemo-related software, read on to find out what can be done and how to perform that."

That would make me feel comfortable because it looks informal, friendly and understanding. Also it gives hope. A nice way to get a pleased and listening reader.

While I don't fully agree with the wording of the text or opinions of PR departments, there's some parts I do find worth to mention. The best way to deal with an emotional response due to a default irritation of proprietary software is to provide technical details how the process actually work.

Like what happens when someone requests the open sourcing of a component. Does it go to a manager who agrees or disagrees or is there a wider process of checking with lawyers etc?.

These processes are not documented and transparency of these processes will help understanding how things are proceeding and provide examples of how open sourcing is done in practice from within a company. It is important to note that open sourcing does not happen overnight and present the practices.

The next part of this series will be about the exceptions to open sourcing and discussing the different reasons for having some components closed source.

Thanks to Paul Fertser for his input to this article.