Porteus

This post is a placeholder, with more information to come.

As I've mentioned a few times on the forum, I have been working (off and on) on getting Porteus built for ARM devices. I'm nearly ready to ship some modules for initial testing by those who are interested in trying it and helping out.

Present status, as of 3/8:

I have working kernels for two devices (versatile express, which I emulate in Qemu, and my tablet, an Acer Iconia A500), a functional initramfs with a new 'excheat' feature which lets you apply porteus-specific (not kernel-specific) cheatcodes by entering them into a plain text file inside the /porteus folder (since embedded devices are likely to be a pain when dealing with modifying your cheatcodes), and the following modules:

000-kernel.xzm (board specific)
001-core.xzm
002-xorg.xzm
005-devel.xzm
0090-xfce.xzm

I also have half of my xfce-apps module built, as well as a module for e17, which has a good tiling interface and touch keyboard for use on my tablet. I'll also prepare an lxde module after I finish up a few other things

known bugs/missing packages:
1) slackyd does not function at all when compiled for ARM -- it simply spits out the help information no matter what parameters you give
2) avidemux will not compile for ARM devices. I've seen some hacks online to get it done, but it will probably be better to find some kind of an alternative.


Next week I'll prepare a kernel for the raspberry pi (which I can emulate to a certain degree inside qemu) and post the kernels and modules for folks to try. I'll also write some HOWTO's, such as how to run porteus-ARM inside qemu on an x86 host and how to crosscompile an ARM kernel in porteus.

I hope you all have a nice weekend!

Update:

I've got the following userland built and functioning:

001-core.xzm
002-xorg.xzm
003-lxde.xzm
005-devel.xzm
006-firefox-hf.xzm (note this requires an ARM processor with hard float support -- armv5 machines will not be able to run it)
0090-xfce.xzm
0091-apps.xzm

These modules follow fairly closely to their counterparts for x86. I'm not currently planning to build/release KDE as most ARM devices wont' be able to handle it.

You can get the userland here: http://porteus-arm.googlecode.com/files ... -11.tar.gz

You can also visit the download sections of my google code page, here: http://code.google.com/p/porteus-arm/downloads/list

I have kernels posted there for versatile express (I use this for emulating in Qemu) and raspberry pi boards. I also have a kernel that is functional on my Acer Iconia A500 tablet, which I can make available upon request, but it's not in very good shape (no graphics accelleration, the touch screen is buggy with evdev 2.7 series, no sound, no internet yet, hibernation is broken, etc.).

I want to give a HUGE round of thanks to Stuart Winter, who builds and maintains Slackwarearm. Without his efforts, Porteus-ARM would not have even gotten off the ground!

As I look towards the future, I have a couple of big "To-Do's". The largest thing looming on my radar at this point is that my userland is based on, and is binary-compatible with the armv5te architecture. This is the default for Slackwarearm 14.0, and allows slackwarearm to be run on older devices, but does not include support for "hard float" and "thumb-2" instructions, which improve performance (greatly, in some areas). To make it brief, hard float was added with armv6 (Rasberry Pi is armv6), and thumb-2 was added for armv7 (most of the modern android devices, such as the Tegra 2,3,4 and OMAP 3,4,5 devices are armv7). There's a spin of debian tailored for the raspberry pi ("raspbian") that is armv6 compliant, and there is also a armhf (hard float -- armv7 compatible) flavor of debian as well. I've poked around a little bit, and haven't found any Slackware ports for hard float.

As such, I'm at a decision point where I need to decide to stick with armv5 (with a performance loss on most machines that will render it worse than debian performance-wise) or attempt to rebase much of slackwarearm for armv6 (to pick up raspberry pi) or armv7 (forget about pi's and focus on machines with more horsepower). Needless to say, recompiling the entire system and all of the software that would go into a module repository on an ARM device is going to be a lot of work (additional patching and tweaking of compiler flags will likely be necessary here and there in the userland).

So, if any of you have found a hard-float Slackware repo out there, or if you have some experience with armv5 software versus armv6/armv7 and you'd like to weigh in to help me decide how to proceed, I'd surely appreciate it!