Is it possible to run aptosid on/from a mobile phone, like a blackberry pearl 8100, via a MicroSD-Card?
If it is not possible to run it on a blackberry, wich mobile phones have the ability to boot from a MicroSD-Card or other mediums?

There are no amd64/ i386 based phones (yet?), therefore you can't run aptosid on these (mostly armel based) phones. Depending on the candidness of of your phone hardware it might eventually be possible to adapt aptosid for it though, like it has been done for powerpc and sparc32 (unreleased due to lacking manpower and buildds), but doing so would require active porter groups for said hardware. On some of these, plain Debian chroots may be possible - maybe Debian can even achieve full support for some of these phones, but given that phones are still considered to be 'embedded' platforms, significant adaptions are needed for each phone, which makes generic support (at least beyond chroots) kind of difficult.

Most embedded or embedded-like hardware platform pose a different caveat though, namely dfsg-free hardware support... For most phones, the actual phone drivers and userspace applications are not available in source or under dfsg-free (or any kind of "free" for that matter) licenses, the same is unfortunately true for most accelerated embedded graphics chipsets (nvidia tegra, Intel GMA500, etc.), which makes them unsuitable for an aptosid release. Technically, it could likely still be 'supported', but a phone that can't make phone calls anymore and drops onto cli after booting likely isn't very useful for its potential users.

Porting aptosid to different (desktop-like) architectures has been proven to be quite possible, however in order to work on it, active porter groups (at least two developers) and reasonable buildd hardware is just unavoidable (besides general platform support in Debian); which unfortunately makes going beyond amd64/ i386 not very likely for the time being. However this would be welcome.

snvv

Post subject:Posted: 16.10.2010, 12:47

Joined: 2010-09-13
Posts: 300

Status: Offline

sx9 in some devices you can install debian and thus might it possible to use aptosid too (I haven't tried).

Those devices are armel arch, so you cannot use aptosid on it - pls see slh's post above.

I have played with the first generation HTC smartphones some years ago, and managed to get our operating system (kanotix those days) running on it. But do not expect too much, I had to fight with non-working wlan drivers, dialer apps, video drivers, crap boot loaders, etc.

Besides architecture and non-free driver problems, those devices usually offer very limited storage and memory, so a lot of love has to be put into tweaking everying for low ram and storage usage.

My best advice here is: shop for an Android device. They already comes with Linux, and are easy to root, hack and adapt.

I have played with the first generation HTC smartphones some years ago, and managed to get our operating system (kanotix those days) running on it. But do not expect too much, I had to fight with non-working wlan drivers, dialer apps, video drivers, crap boot loaders, etc.

Yep not all Linux are created equal, and just because a vendor can get Linux on a device does not mean you would like the result of using anything other then "their Linux" with their userspace.

Quote:

My best advice here is: shop for an Android device. They already comes with Linux, and are easy to root, hack and adapt.

Now here is where I cannot agree because it contradicts the last statement. Are there any Android phones where they are actively trying to push all the hardware drivers into the Linux kernel? Apart from that "easy to root" does not mean "you have root" and frankly if they want to make me download a dodgy app from a random site to get root on my own phone then I know my answer. Some of the android phones also will give you root (nefariously or honestly) but no access to load your own kernel (let alone bootloader). If you don't want to run Android on a phone then buying an Android phone should be researched very carefully.

So I have an N900 and while I have yet to port fullstory onto it I certainly plan to. Now it seems that all the most important hardware is supported by the upstream kernel, with some non-free firmware for wifi and bluetooth for example, it's probably going to happen sooner rather then later. Like the powerpc port though it may never go beyond the source changes in fullstory. For one thing I don't really fancy "releasing" anything when I've only one (sane) arm and one powerpc machine but also as slh mentioned the "two devs rule" applies so even if I did release anything it would not be aptosid but just a personal "toy".

The N900 is far from perfect either really (i.e. power management needs love and the video chips good drivers are horribly non-free). If you really want no surprises then the openmoko would be a better bet, however this is about the only way you can compare the N900 and an openmoko which is a much lower powered and featured device.

DonKult

Post subject:Posted: 16.10.2010, 20:28

Team Member

Joined: 2010-09-02
Posts: 482

Status: Offline

bfree wrote:

The N900 is far from perfect either really (i.e. power management needs love and the video chips good drivers are horribly non-free). If you really want no surprises then the openmoko would be a better bet, however this is about the only way you can compare the N900 and an openmoko which is a much lower powered and featured device.

Yeap, i have an openmoko and the only thing which is better than N900 is that it is completely free. Meaning that you don't need a non-free firmware, driver or software to use it as a phone, gps device or whatever you want to do with it. Its really not a powerhorse (e.g. fullscreen 640x480 video is not feasible, or at least not for now, there is some work ongoing…)… And that it is free doesn't mean that all made it into mainline already: The community make good progress in getting the missing bits into the mainline kernel (mostly wifi), upstream libdrm (the graphic card is called "glamo" and used nowhere but in the openmoko it seems…) and stuff. The good side is that you can install debian as it is described on the wiki page mentioned above (and even debian-installer support is in progress) and have a functional phone… - but you need the pkg-fso repo as not every package is in debian proper already (kernel flavor for example, but they are working on it…).

Talking about armel: I recently got a sheevaplug (which doesn't get too hot btw), so in theory i could even build stuff from the aptosid repositories without needing days until completion, but most of it isn't intended for such devices anyway: I don't need an aptosid-kernel for the openmoko for example and compiling it for the sheevaplug needed 8 hours (in that timeframe slh published two new revisions so it was already obsolete) [it could be that i did something wrong in porting the packaging as i am not too experienced in the kernel packaging, so this timing can be utterly crap - it was only a test anyway].

Uh, and btw: I don't know what you mean by storage slam. Internal NAND is relatively small, yes, so if you really want to push debian to it you need a few simple tricks (other mainstream openmoko distros provide premade special images for it), but you always have a (mirco)SD slot available or you can switch to usb-hostmode and attach a external usb-harddrive…

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

Thanks for all of your really great and partly brilliant posts!
And thank you for the links!

slam:
Right! Android is based on Linux, so I have some possibilties to modify it (I wonder if it has a shell...).

slh:
You've cleared up all my previous (even the hidden) questins in detail!

Is just a cross-compiler needed to compile the software for other archs?
If it is that easy, then I am going to try to compile the whole aptosid source-code (the F.U.L.L.S.T.O.R.Y.-Project) for your next preferred architecture.

DeepDayze

Post subject:Posted: 17.10.2010, 00:30

Joined: 2010-09-11
Posts: 616
Location: USA
Status: Offline

Aptosid on a phone? Now that's quite an ambitious project and wish you luck with the portage and I'm sure slh and the devs will give you some great technical advice. Let us know how your "unofficial" project goes

phen

Post subject:Posted: 17.10.2010, 01:06

Joined: 2010-09-11
Posts: 27

Status: Offline

Since I own an HTC Desire for a month now, one of the first things I wanted to know was whether its possible to run any other linux (like aptosid) on it.
What I found was this: http://www.nickles.de/c/n/linux-desktop ... s-7344.htm
Unfortunately its in German, saying someone figured out how to get X running on an Android-device. Of course such devices have limited performance, hence this would be more a proof of concept than anything useful. However, that site links another english one - perhaps worth a look: http://www.androidfanatic.com/community ... mp;id=1615
Since that process apparently contains a CLI including apt-get, more fancy stuff regarding aptosid-specifics might be possible?

I havent tried that though, not really feeling brave enough at this time;)

But compiling is actually the smallest part of porting work, much more important is actually developing support for platform specific issues, like how to deal with the device's bootloader (which is not grub2, but likely uboot or even more archaic ones, perhaps even hostile ones), setting up boot parameters (uboot for example needs to initialize quite some board specific hardware parameters, like serial console, network support, switch initialization, screen init, mtd partitioning scheme, etc.), coming up with a dedicated kernel (which again needs to be very device specific, as - contrary to desktop systems with hard disks measured in the TB) - you don't have any byte to 'waste' or simply fixing buildtime and runtime errors (debugging). None of this can be provided by cross-compilers, besides that Debian (and Debian packaging) doesn't account for cross compiling support (maybe with multi-arch one day, but that's wheezy or wheezy+1 material).

Desktop systems are 'easy', as they all behave the 'same' and can be covered by rather generic approaches, besides that the last bit or MHz generally doesn't matter, while it does for embedded devices. Just one example, phone rarely have a PCI bus, but rather SPI/ SDIO (or SSB). Likewise manufacturers for embedded wlan solutions save ~1 ct for an EEPROM, but rather store MAC address, calibration data and other core device data in a file on the embedded OS, which now has the burden of initializing the device correctly (the MAC address must be unique and stable between reboots, so just hardcoding one for the whole batch does not work; calibration data is not only chipset-, but also device/ antenna specific, which means wl1251_sdio on an N900 needs different calibration data than the same chipset on a (hypothetical) N901) - which in turn means that the correct vendor data needs to be extracted from the original OS before install $shiny_new_custom_OS.

While Android tries to abstract device specifics from userspace (it's relatively easy to provide a generic armel port of xclock, the "only" caveats are screen size and input methods, not to forget battery runtime (==perfect powersaving)), the OS still needs to be ported to each phone individually; in a way that is way more specific than imaginable from a desktop's point of view. It will likely take several new phone/ phone OS generations, until the hardware can be abstracted enough to allow generic HAL autoconfiguration (which involves enough RAM, storage, CPU processing power to use highly modular distro kernels, udev for device probing, etc.) on par with contemporary i386/ amd64 (or even alpha, hppa, classic mips workstations, powerpc, sparc) "desktop" systems. Until then, porting work of installer and boot methods (e.g. what makes up an operating system, in contrast to an app-store) will have to be done individually per device.

In other words, we'd not be looking for "trained monkey" running "make && make install", but someone who finds out which bootloader to use, what mtd partitioning to apply, which compression format the bootloader expects and which magic numbers are used for squashfs-lzma this time..., how to configure it for $particular_device, extract platfrom data from the original OS and how to adapt the installer (which likely means writing a new one almost from scratch). Only then, it becomes important to check if higher level packages (think Ceni, infobash and friends) compile (bad examples, as they're based on perl or bash and therefore don't need to be built on armel) and work as expected (infobash for example won't, as it doesn't know how to parse armel /proc/cpuinfo) - and if they don't build, to investigate what's needed to fix them, without breaking amd64/ i386. Only then buildds enter the picture, still important - especially when it comes to building packages in time, or even in lockstep with amd64/ i386 - but a lot of work needs to be done before a compiler gets used for the first time.

Is it likely that we'll "ever" see aptosid on a phone?

I guess not, as I don't expect us to gain enough experienced and dedicated manpower for such an approach any time soon, who can also deal with the fact that once $modell is barely supported, $modell+2 is already on the shelves and under the christmas tree. Besides simply standardizing on one phone to concentrate efforts on. And how would this "aptosid" look like on a phone? As there's simply a huge stretch between providing a desktop live CD/ installer and an embedded phone (no keyboard, small screen size, battery runtime and general snappiness ruling the world), which comes with a completely different usage pattern/ access mantra.

But maybe future phone generations make all of this easier, maybe vendors that actively contributing their customizations to the upstream kernel in time (it is slowly starting to work for wlan cards, so this is not totally impossible), maybe there are quantum leaps in regards to mobile processing power, input method an screen sizes (augmented reality) and battery runtime, so a phone becomes are generic as the workstation sitting on your desk, maybe - time will tell. Just that now, at this very moment, phones are still to be treated as embedded devices and not generic commodity desktop hardware (even embedded routers are more generic than phones these days). Android and its development/ market force may pave the way, as at least userspace ABI needs to be guaranteed (in order to keep the app store working), given that today's users demand their new toys to be supported by the new Android versions, this may force vendors to rethink their current approach of saving the last cent in hardware and writing huge customizations for each new model in order to ease upgrading to future OS versions. Perhaps, time will tell - but right now, there is a reason beyond simple vendor lock-in why you can't download a working (generic) Android 2.2 for your phone, but need to wait for your phone manufacturer and phone company to release a customized version for their phone (which might never happen).

Is it possible, yes.
Will it look anything like the aptosid as we know it today, unlikely.
Does it make sense to approach this within aptosid, not necessarily, but if there are enough developers working on it, it might be solved.
But it needs a dedicated developer force to even think about it.

Wow, great post (again)!
But, I just wanted to compile it to other archs for desktop aptosid.
But the UI plays a huge roll, too. It has to be completly changed to fit on that small screens on a well looking way. With KDE-Plasma-Netbook the first step is done for devices like the WeTab, but that's, like you've said it, not everything. But back to desktop cross-compiling now: I understand now that there is a much more effort than cross-compiling to port aptosid and that especially CROSS-compiling causes errors (I have ever thought that this couldn't be a clear thing and therefore have never done any cross-compiling). But if the aptosid team thinks about porting it to other archs for desktops, I will try to help you anytime and everywhere I can.

DeepDayze

Post subject:Posted: 17.10.2010, 15:12

Joined: 2010-09-11
Posts: 616
Location: USA
Status: Offline

A good idea would be to backup your phone's data and firmware before you mess with it

Researching the arch and device specific items beforehand will be a good thing too, which can help with making the port easier.

It would be great if you were able to get your hands on another phone similar to yours so you can "hack" on it without messing up your own device