[Request + (long) progress report] How do I run M4/M5 (Hildon etc) on top of vanilla armel linux?
 

Message 1 / 9 (didn't know forum would require breaking messages up - sorry!)

Hi everyone!

First of all, just to clarify - crazy: [✔✔] double-check! :)

The goal

My goal/motivation is simple enough: I'd like to sandbox GVM so it will run within other environments. Like, say, a chroot on Android, or in qemu-system-arm on x86. GVM beta 6 is the most recent (2010!!) official runtime 4.x+5.x OS release out there, and this is likely to remain forever the case. With this being the case, it strikes me as a little odd that it seems nobody's tried to see if the platform can be made a little more portable than was maybe intended.

As for "why?!" (or maybe "why now?") - I got a head-cold a few days ago, and needed a temporary/throwaway distraction to focus on. Haha, "temporary"... I'm over the cold now, but dug into this project a bit deeper than I anticipated I would, and now I'm itching to see it working.

GVM itself appears to run just fine on vanilla armel Debian, once I manually copy a few libraries in. It's gvmlauncher - the shell/springboard/installer system (!!!) - that's the mess. It does actually launch (outside of Hildon (!) - albeit with a mess of windows on the screen...) and then successfully connect to GVM, but it crashes as soon as I try and click anything that would open a file picker. This is where I'm stuck.

On the one hand, it's definitely worth considering to see if gvmlauncher can be thrown away and an alternative shell UI and launcher put together. The gvm<->gvmlauncher IPC mechanism looks simple enough for this to seem viable, but I only say this because I haven't been able to actually test everything that gvmlauncher does in situ as I don't have an N8x0/N900 device (and, if I'm brutally honest with myself, am probably not going to get too much use out of one either generally or for this specific task, as my end+only goal here is sandboxing).

On the other hand, looking at the nuanced side of things, reimplementing a new gvmlauncher feels vaguely reminiscent of of that one time a bunch of crazy hackers took the Windows 2000 and Windows NT source code leaks and compiled a working NTOSKRNL out of the pieces. Near unbelievably cool, but... eeeh. I'm certainly not reverse-engineering anything to that extent here, but still... I can't help but wonder if it would be better to, instead of touching any GVM-specific components, get just enough of Hildon running on top of vanilla armel linux that the result coincidentally happens to run GVM perfectly inside qemu-system-arm and on Android. This really seems like the best approach anyway because GVM itself will always need an X server.

TL;DR: I'm missing / looking for specific instructions on how to run the Hildon environment on armel Linux in Xephyr.


After 4-5 days of trying things that have all (!!) ended in failure, I am posting here and asking for help. I'll probably lurk in this thread in a bit and weigh in in a little while once I've had some time to deflate and catch up on other things, and can spend some time properly following up on people's suggestions.


The following is very long and is mostly about failure. It will be boring unless you are an engineering type good at scanning through thorough bug reports quickly.


What I've tried

Running GVM inside qemu-system-arm: works, with caveats noted above

Two days of searching finally found garnet-vm-1.0.6b-itos2009-armel.deb under a rock at http://dl.mobilestan.net/download.ph...JH8kXmZ2v&v=11. (Most of the going around in circles was not knowing what filename to look for. My thanks to the person who submitted the totally random and very google-friendly bug report at https://bugzilla.redhat.com/show_bug...iple&id=620326 :) )

.deb was manually extracted (ar x + tar xvf). gvmlauncher successfully gets application list if gvm is in /usr/bin/gvm/ (yes, the subdir gvm).

Environment used was constructed by converting Squeeze image at https://people.debian.org/~aurel32/qemu/armel/ to ext4 (by copying its contents into a new ext4-formatted qcow2 disk image (via qemu-nbd), then mounting the old disk image and cp -arv-ing everything over), copying the /lib/modules/ dir from the filesystem at https://people.debian.org/~aurel32/qemu/armhf/ into the newly created ext4 filesystem, and then then using the armhf kernel from Wheezy. This was needed because the Squeeze armel kernel was built for the versatilepb target, which emulates an ARMv6-series CPU, while the Wheezy armhf kernel was built for vexpress-a8, which emulates an ARMv7 CPU - important because the gvm binary was compiled for ARMv7. See also: https://reverseengineering.stackexch...r-and-quitting

apt-get inside Squeeze is old enough that it does not have any facilities (!) to disable GPG package signature verification, and package signatures on archive.debian.org expired a very long time ago. This caused a good day or two of complete disorientation. Thanks to whoever it was on #debian that suggested fakedate and was the inspiration behind:No apt configuration changes required at all. Technically it preserves your security, too - provided the correct signatures are exclusively out of date :D

(Insert standard disclaimers here about security being your responsibility...)

Anyway, yeah. This gets me running GVM... but not in an especially useful form.

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 2 / 9

Running GVM inside qemu-arm on x86: segfault

Memory map continued...

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 4 / 9 - Memory map continued...

This is with the exact same libraries that make GVM work inside the VM.

The backtrace suggests a QEMU userspace emulation issue that I'm not especially inclined to want to follow up on :)

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 5 / 9

Copying random directory trees from Scratchbox into debian armel VM: variously produces segfaults, assertion failures, dbus errors, shared library errors, missing icon errors, missing theme errors, eye twitch errors, insanity errors

I'm somewhat certain that installing (or rather trying to install) Scratchbox on my Arch system would be a true exercise in "what size upgrade would you like for your migraine today?", so I was very grateful to find I've read some things that suggest there was an official development VM - was this it?

I can report that running gvm under the qemu-arm in Maemo_Ubuntu_Lucid_Desktop_SDK_Virtual_Image_Final .7z (from https://www.fladnag.net/downloads/telephone/n900/tools/) also segfaults.

But... then I discovered the FREMANTLE_ARMEL directory in that VM.... :D

Here's a rough example of what's I've copied in (I just learned that 50 xterm windows kind of... happened... but [being able to do] this is why you leave your terminals open, people ;P):

• usr/share/icons/*
• etc/dbus-1/
• etc/gconf
• etc/gnome-vfs-2.0
• etc/gtk-2.0/gdk-pixbuf.loaders
• etc/osso-af-init
• etc/pango/pango.modules
• gtk-2.0
• usr/lib/hildon*
• usr/bin/hildon-desktop
• usr/lib/libIMGegl.so*
• usr/lib/libSDL*
• usr/lib/libXcomposite.*
• usr/lib/libXcursor.*
• usr/lib/libXdamage.*
• usr/lib/libXfixes.*
• usr/lib/libXft.*
• usr/lib/libXi.*
• usr/lib/libXrandr.*
• usr/lib/libXrender.*
• usr/lib/libXtst.*
• usr/lib/libasound.*
• usr/lib/libatk-1.0.*
• usr/lib/libcairo.*
• usr/lib/libcanberra*
• usr/lib/libdbus*
• usr/lib/libfontconfig.so*
• usr/lib/libfreetype.so*
• usr/lib/libgconf*
• usr/lib/libgdk-x11*
• usr/lib/libgdk_pixbuf*
• usr/lib/libgio-2.0.*
• usr/lib/libglib-2.0.*
• usr/lib/libgmodule-2.0.*
• usr/lib/libgnomevfs-2.*
• usr/lib/libgobject-2.0.*
• usr/lib/libgthread-2.0.*
• usr/lib/libgtk-x11*
• usr/lib/libhildon*
• usr/lib/libltdl.*
• usr/lib/libosso*
• usr/lib/libpango*
• usr/lib/libpangoft2-1.0.so*
• usr/lib/libpangox*
• usr/lib/libpangoxft-1.0.so*
• usr/lib/libpixman-1.*
• usr/lib/libpng12.*
• usr/lib/libpulse*
• usr/lib/libsrv_um.so*
• usr/lib/libtrackerclient.so*
• usr/lib/maemo*
• usr/bin/dbus*
• usr/bin/gconf*
• usr/lib/gconf2
• usr/lib/gio
• usr/lib/gnome-vfs-2.0
• usr/lib/gvfs
• usr/lib/libEGL.so*
• usr/lib/libGLES*
• usr/lib/libbookmarkengine.*
• usr/lib/libclutter-eglx-0.8.so.0
• usr/lib/libgconf2
• usr/lib/libgio-2.0.*
• usr/lib/libgnome*
• usr/lib/libgvfs*
• usr/lib/libhal*
• usr/lib/libiphb*
• usr/lib/libjpeg*
• usr/lib/libprofile.so.0*
• usr/lib/maemo-launcher
• usr/lib/pango
• usr/libexec
• usr/share/dbus-1/system-services
• usr/share/fonts/
• usr/share/icons/*
• usr/share/themes/alpha
• usr/share/themes/default

Unfortunately I don't seem to have recorded screenshots or dumps of this but I remember at one point seeing in strace that disk information being sent over D-Bus (I distinctly remember seeing the Trash entry) after I requested a file picker! Seemingly to no effect though, it still crashed in the end anyway. I don't know how close this might have been.

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 6 / 9

Launching manually-copied-over hildon-home and hildon-desktop inside debian armel VM: EGL errors, many assertion failures

Here's what I get, with many identical duplicate lines removed:

This is with armhf Xephyr (borrowed from the Wheezy rootfs) over X forwarding (ie, Xephyr is running in the same memory space as Hildon et al, and SHM should be working). All extensions, particularly the Composite extension, are available. (For some reason Composite doesn't initialize if I run Xephyr on top of xtightvncserver!)

In spite of the errors, it seems some things have actually started up:

I'm quite confused by this - I was under the impression Xephyr provided (or could provide) some form of GL emulation. Apparently not. The GLX extension is listed as available...???


Copying whole FREMANTLE_ARMEL directory into Debian armel VM and using as chroot: produces similar errors to above :'(

The previous crash is with libraries manually copied over into root of debian armel installation (that poor poor disk image...).

Obviously chrooting is the slightly more common-sense way to do it.

But unfortunately chrooting doesn't work, either!

On a brand-new cleanly-installed debian armel system, with the FREMANTLE_ARMEL directory copied in and chrooted-into... I get exactly the exact same assertions and EGL failures as above, just (for some reason) hidden in syslog (with no syslogd running...) this time around. Had to dig the messages out with strace. No point posting them as they're exactly the same.

For what it's worth, the messages are coming out of maemo-launcher and run in an infinite loop, presumably as maemo-launcher attempts to endlessly restart hildon-home.launch.


Trying to run the N8x0 device images inside stock QEMU: white screen + hung emulator

Apparently this specific failure mode is a bit of a theme? https://talk.maemo.org/showpost.php?p=211906

Followed instructions at http://www.rkeene.org/projects/info/wiki/106. Grabbed images from https://web.archive.org/web/20131117...ev/nokia_N800/ and config.mtd from https://talk.maemo.org/showpost.php?p=211310.

Unfortunately, just like in the posts, I just get a slightly off-white screen, and QEMU sits there not doing anything. This is with:

• Stock QEMU
• The qemu-linaro branch which had N900 emulation (thanks to https://launchpad.net/qemu-maemo for the hint)
• QEMU SVN revision r4980 (as referred to in https://talk.maemo.org/showpost.php?p=214819)
• QEMU SVN revision r6679 (as referred to at rkeene.net (see above))

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 7 / 9

Trying to run the N8x0 device images inside QEMU compiled with GCC 3.x from Debian 4.0 (x86_64): N800... works?!

Don't understand this one at all. This was a long shot that I did not really expect to do anything different, and I tried it "just in case". Same source code checkout, in fact I just realized I cp -r'd the SVN checkout from my host system into the Debian VM and then ./configured and built it without running make clean first. So Debian 4 and GCC 3.3 definitely did something very interesting. Seems mainline QEMU's N8x0 device support is actually quietly broken on newer systems (unsurprising really).

(The outcome of using GCC 3.3 was that I tried to compile r4980 on my Arch box, and the ./configure from that era bailed out and asked for GCC 3. So, I went hunting for something with GCC 3, and using Debian was becoming a bit of a theme, so I just went straight for that.)

The good news: the N800 model works! Here's the very boring bootup debug log, which I'm posting because I couldn't find one on the internet anywhere, and I want to preserve a copy:

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 8 / 9 - QEMU debug log continued...


The bad news: the N800 emulation is faithful to the real hardware to the point thaaaat I... cannot type. Yippee.

So, I made this:

I spent about 10 minutes figuring out the X,Y coordinates of all of the "keys" in the osso-xterm on-screen keyboard, and put them into the above shell script that pecks away at the OSK with the mouse for me as I type normally. With the (necessary) delays it's a bit like semi-remote SSH.

It uses xinput as a keylogger and xdotool to move and click the mouse. (Use it with a text editor or a terminal running cat focused, since sending the Enter key into the QEMU window will switch you to full-screen keyboard mode.)

This only allows me to type basic commands, though. I do NOT want to eg add the routines to handle uppercase letters or special characters etc etc unless I absolutely HAVE to...

Oh - and this is for a US keyboard layout, you'd have to go look at xmodmap -pk if you're on a different layout (I forgot where I put my code that parses xmodmap output and didn't feel like rewriting it so just left it with the fixed keycodes.)

(One last thing, leave it running and try and type elsewhere :D the result is hilariously disorientating :D)


Even more bad news: I don't have any networking!! I'm not sure what options to pass to get this working - if there are any. :/

(As an aside, ping appears to not have been made suid root. Nice one.)

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 2 / 9

Running GVM inside qemu-arm on x86: segfault

Memory map continued...

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 3 / 9 - Memory map continued...

Memory map continued...

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 4 / 9 - Memory map continued...

This is with the exact same libraries that make GVM work inside the VM.

The backtrace suggests a QEMU userspace emulation issue that I'm not especially inclined to want to follow up on :)

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 5 / 9

Copying random directory trees from Scratchbox into debian armel VM: variously produces segfaults, assertion failures, dbus errors, shared library errors, missing icon errors, missing theme errors, eye twitch errors, insanity errors

I can report that running gvm under the qemu-arm in Maemo_Ubuntu_Lucid_Desktop_SDK_Virtual_Image_Final .7z (from https://www.fladnag.net/downloads/telephone/n900/tools/) also segfaults.

But... then I discovered the FREMANTLE_ARMEL directory in that VM.... :D

Here's a rough example of what's I've copied in (I just learned that 50 xterm windows kind of... happened... but [being able to do] this is why you leave your terminals open, people ;P):

• usr/share/icons/*
• etc/dbus-1/
• etc/gconf
• etc/gnome-vfs-2.0
• etc/gtk-2.0/gdk-pixbuf.loaders
• etc/osso-af-init
• etc/pango/pango.modules
• gtk-2.0
• usr/lib/hildon*
• usr/bin/hildon-desktop
• usr/lib/libIMGegl.so*
• usr/lib/libSDL*
• usr/lib/libXcomposite.*
• usr/lib/libXcursor.*
• usr/lib/libXdamage.*
• usr/lib/libXfixes.*
• usr/lib/libXft.*
• usr/lib/libXi.*
• usr/lib/libXrandr.*
• usr/lib/libXrender.*
• usr/lib/libXtst.*
• usr/lib/libasound.*
• usr/lib/libatk-1.0.*
• usr/lib/libcairo.*
• usr/lib/libcanberra*
• usr/lib/libdbus*
• usr/lib/libfontconfig.so*
• usr/lib/libfreetype.so*
• usr/lib/libgconf*
• usr/lib/libgdk-x11*
• usr/lib/libgdk_pixbuf*
• usr/lib/libgio-2.0.*
• usr/lib/libglib-2.0.*
• usr/lib/libgmodule-2.0.*
• usr/lib/libgnomevfs-2.*
• usr/lib/libgobject-2.0.*
• usr/lib/libgthread-2.0.*
• usr/lib/libgtk-x11*
• usr/lib/libhildon*
• usr/lib/libltdl.*
• usr/lib/libosso*
• usr/lib/libpango*
• usr/lib/libpangoft2-1.0.so*
• usr/lib/libpangox*
• usr/lib/libpangoxft-1.0.so*
• usr/lib/libpixman-1.*
• usr/lib/libpng12.*
• usr/lib/libpulse*
• usr/lib/libsrv_um.so*
• usr/lib/libtrackerclient.so*
• usr/lib/maemo*
• usr/bin/dbus*
• usr/bin/gconf*
• usr/lib/gconf2
• usr/lib/gio
• usr/lib/gnome-vfs-2.0
• usr/lib/gvfs
• usr/lib/libEGL.so*
• usr/lib/libGLES*
• usr/lib/libbookmarkengine.*
• usr/lib/libclutter-eglx-0.8.so.0
• usr/lib/libgconf2
• usr/lib/libgio-2.0.*
• usr/lib/libgnome*
• usr/lib/libgvfs*
• usr/lib/libhal*
• usr/lib/libiphb*
• usr/lib/libjpeg*
• usr/lib/libprofile.so.0*
• usr/lib/maemo-launcher
• usr/lib/pango
• usr/libexec
• usr/share/dbus-1/system-services
• usr/share/fonts/
• usr/share/icons/*
• usr/share/themes/alpha
• usr/share/themes/default

Unfortunately I don't seem to have recorded screenshots or dumps of this but I remember at one point seeing in strace that disk information being sent over D-Bus (I distinctly remember seeing the Trash entry) after I requested a file picker! Seemingly to no effect though, it still crashed in the end anyway. I don't know how close this might have been.

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 6 / 9

Launching manually-copied-over hildon-home and hildon-desktop inside debian armel VM: EGL errors, many assertion failures

Here's what I get, with many identical duplicate lines removed:

This is with armhf Xephyr (borrowed from the Wheezy rootfs) over X forwarding (ie, Xephyr is running in the same memory space as Hildon et al, and SHM should be working). All extensions, particularly the Composite extension, are available. (For some reason Composite doesn't initialize if I run Xephyr on top of xtightvncserver!)

In spite of the errors, it seems some things have actually started up:

I'm quite confused by this - I was under the impression Xephyr provided (or could provide) some form of GL emulation. Apparently not. The GLX extension is listed as available...???


Copying whole FREMANTLE_ARMEL directory into Debian armel VM and using as chroot: produces similar errors to above :'(

The previous crash is with libraries manually copied over into root of debian armel installation (that poor poor disk image...).

Obviously chrooting is the slightly more common-sense way to do it.

But unfortunately chrooting doesn't work, either!

On a brand-new cleanly-installed debian armel system, with the FREMANTLE_ARMEL directory copied in and chrooted-into... I get exactly the exact same assertions and EGL failures as above, just (for some reason) hidden in syslog (with no syslogd running...) this time around. Had to dig the messages out with strace. No point posting them as they're exactly the same.

For what it's worth, the messages are coming out of maemo-launcher and run in an infinite loop, presumably as maemo-launcher attempts to endlessly restart hildon-home.launch.


Trying to run the N8x0 device images inside stock QEMU: white screen + hung emulator

Apparently this specific failure mode is a bit of a theme? https://talk.maemo.org/showpost.php?p=211906

Followed instructions at http://www.rkeene.org/projects/info/wiki/106. Grabbed images from https://web.archive.org/web/20131117...ev/nokia_N800/ and config.mtd from https://talk.maemo.org/showpost.php?p=211310.

Unfortunately, just like in the posts, I just get a slightly off-white screen, and QEMU sits there not doing anything. This is with:

• Stock QEMU
• The qemu-linaro branch which had N900 emulation (thanks to https://launchpad.net/qemu-maemo for the hint)
• QEMU SVN revision r4980 (as referred to in https://talk.maemo.org/showpost.php?p=214819)
• QEMU SVN revision r6679 (as referred to at rkeene.net (see above))

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 7 / 9

Trying to run the N8x0 device images inside QEMU compiled with GCC 3.x from Debian 4.0 (x86_64): N800... works?!

Don't understand this one at all. This was a long shot that I did not really expect to do anything different, and I tried it "just in case". Same source code checkout, in fact I just realized I cp -r'd the SVN checkout from my host system into the Debian VM and then ./configured and built it without running make clean first. So Debian 4 and GCC 3.3 definitely did something very interesting. Seems mainline QEMU's N8x0 device support is actually quietly broken on newer systems (unsurprising really).

(The outcome of using GCC 3.3 was that I tried to compile r4980 on my Arch box, and the ./configure from that era bailed out and asked for GCC 3. So, I went hunting for something with GCC 3, and using Debian was becoming a bit of a theme, so I just went straight for that.)

The good news: the N800 model works! Here's the very boring bootup debug log, which I'm posting because I couldn't find one on the internet anywhere, and I want to preserve a copy:

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 8 / 9 - QEMU debug log continued...


The bad news: the N800 emulation is faithful to the real hardware to the point thaaaat I... cannot type. Yippee.

So, I made this:

I spent about 10 minutes figuring out the X,Y coordinates of all of the "keys" in the osso-xterm on-screen keyboard, and put them into the above shell script that pecks away at the OSK with the mouse for me as I type normally. With the (necessary) delays it's a bit like semi-remote SSH.

It uses xinput as a keylogger and xdotool to move and click the mouse. (Use it with a text editor or a terminal running cat focused, since sending the Enter key into the QEMU window will switch you to full-screen keyboard mode.)

This only allows me to type basic commands, though. I do NOT want to eg add the routines to handle uppercase letters or special characters etc etc unless I absolutely HAVE to...

Oh - and this is for a US keyboard layout, you'd have to go look at xmodmap -pk if you're on a different layout (I forgot where I put my code that parses xmodmap output and didn't feel like rewriting it so just left it with the fixed keycodes.)

(One last thing, leave it running and try and type elsewhere :D the result is hilariously disorientating :D)


Even more bad news: I don't have any networking!! I'm not sure what options to pass to get this working - if there are any. :/

(As an aside, ping appears to not have been made suid root. Nice one.)

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Message 9 / 9

I also don't even have a working serial console. I've tried all of these console devices, all to no effect:

• ttyS1
• ttyS2
• ttyS3
• ttyO1
• ttyO2
• ttyO3
• tty01
• tty02
• tty03
• ttyAMA0
• ttyAMA1

Adding init=/bin/sh completely blocks the boot pretty much immediately, so this tells me where/when the kernel initialization is taking place and equivalently when/where I should definitely be seeing tty output. No dice though.

So... even though I can boot OS2008 in the N800, I don't consider this successful as I can't really use the resulting device. I can't get GVM into it, for starters!!

I'm not entirely sure how this is working at all though to be honest. At one point when using r4980 and RX-34-RX-34_2008SE_1.2007... I think .44-4, nothing was working, and straceing qemu-system-arm showed that it was slowly lseeking around and lazily reading the flash. And then something twigged internally inside the VM and QEMU went into a hard loop executing clock_gettime 20,000 times a second. That was weird. It didn't emit any more lseeks or reads after going into that hard loop, so after giving it a few moments, I ^C'd it.


Trying to run same QEMU using -M n810: nnnope

-M N810 just results in

and

no matter how long I leave them for. I get the impression QEMU is just spinning and not doing anything (no disk seeks etc).

I tried the partition table change noted at https://talk.maemo.org/showpost.php?p=211906 but to no effect.

I think something's deadlocking waiting for some emulated hardware to enter a certain state or something. I've had a look at hw/nseries.c but that's just poking lots of magic values into registers. I tried forcing the N800 model to also initialize the N810 keyboard, but that didn't work (I would have been very surprised if it did). Chances are the deadlock would probably be debugged/fixed from hw/omap2.c, which... I am slightly not so inclined to want to touch :P

NOTE. I am intrigued to emulate an N series device in QEMU but I am hesitant this will get me any closer to my goal - Xomap provides the exact GL environment that Hildon is expecting, and my goal here is reproducing this GL environment (software-emulated or not - I really really don't care) with vanilla Debian.


Trying to run OS2009 on N900: insufficient instructions found

I cannot find good instructions on how to run OS2009 on an N900.

In fact am uncertain this endeavour would be successful - https://talk.maemo.org/showpost.php?p=591969 notes that QEMU did not have SGX graphics support back in 2010, and looking in the source code today, I'm uncertain how to interpret what I see - there are not that many references to "SGX" and "sgx":

The instructions for booting N900s seem very different to N8x0 series devices: https://talk.maemo.org/showpost.php?p=879015

I tried googling the listed filenames for fun, and this led me to find http://46.249.74.23/qemu/, which contains the exact files mentioned in the command!

What's very nice is that this setup automatically routes Linux to the tty console:

I didn't realize ^C wouldn't go into the guest image :( the qemu-linaro fork is a bit old it would seem.

Unfortunately, after all this, the resulting image does not boot up correctly; it just displays a "Twitter" tile on a black screen... and that's basically it. I can't interact with it at all. The only thing I can do is press F2, which turns the touch layer on and off - producing the messages toward the end of the above scrollback.

Interestingly, at one point, while I was tinkering around with Hildon in my vanilla Debian image, I actually got the exact same result - a lone Twitter tile on an otherwise-blank display, which didn't do anything when I clicked it. This suggests to me that, considering this failure happened while I was struggling with getting GL working, perhaps the N900 setup doesn't have working GL, and it's failing in exactly the same way?? If true, this would be consistent with "SGX not working". But I'm truly stumped.

(For archival, since IP addresses to tend to bitrot eventually, google finds references to an "ivo" connecting to IRC from that IP, along with a similar/consistent "From:" email at https://lkml.org/lkml/2016/1/7/490 (which also references the IP).)

If you got to the end of this without skipping through anything, then even if you have no suggestions, please leave a comment so I can properly congratulate/thank you! :P

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Darn. Wont get congrats cause skipped that much. And can't help cause don't understand those things. But your thread with a walkthrough is very educating in many ways. So thanks. Hope some will know how to help you.

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

First things first.
I believe that this whole thread should be relocated to the one of the maemo subforums ...perhaps ...since it engulfs both the n8x0s and n900 ...
stipulated in the thread title "M4 and M5" for maemo 4 and 5 os's in the title to differentiate it so folks know it concerns the two os's and the device lines.

Otherwise the hard work you have done will get drowned under future posts residing here in "General"
And that would be a shame.

That is the first suggestion.

Second ...and pertaining specifically to your work you have done .
Good on you.
Even though you are new to the forum ...it is obvious you have been messing about with the NIT line for a while before joining us here.
As well ...your tackling of such issues as you have demonstrated here is admirable and I can fathom you will be an asset to our mad collection of fellows here.
So welcome.

Now to the meat of things.
without going into technicals...and rambling on ...on those...
the blunt end of the stick is ...
Hildon is not an easy thing to implement on anything else other than our devices ..and running the os's properly....as well.

It is documented that even the attempt to bring hildon to gnome was long and very difficult and not entirely successful....though not entirely a failure either.
Back in the day I worked on implementation of Hildon into gnome ...and it was no small feat...on my own....Hildon is a right mess.
Always has been.

Currently if you wish to understand more of your issues and how to possibly (and I say that word in the most tentative fashion...since you may or may not get your issues sorted out ...) get them sorted...
I would suggest referring to the Maemo Leste work being done.
They are currently miles ahead of most every other attempt at working with Hildon ...that has been previously done.
If anything ...the Leste team may be able to help you answer a few questions ...

More importantly ...if you are as sharp as you seem to be...
then I think perhaps the Leste team could use you ...if they felt they could use your skill set.

It may be you can give them a hand and also at the same time accomplish your ambitions.

Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
 

Maemish: it's okay :cool: and thanks :)

endsormeans:

Ah, I didn't know there were specific subforums - by all means when a mod notices this thread they can relocate it wherever seems most appropriate.

And I changed the thread title too, thanks.

Wow, cool :) so you actually did the UI integration work. Nice.

Very interesting, thanks for the pointer. I definitely didn't see Leste during my specific focus on "get Maemo working" and "emulate N8x0/N900". Glad I posted here.

What would be really really nice is if Leste has binary compatibility with original Maemo. Because I'm not going to be able to recompile Garnet :D



Thanks for the replies! I'll go say hello to the Leste team and see what happens from that. (Edit with thread URL pending...)

Re: [Request + (long) progress report] How do I run M4/M5 (Hildon etc) on top of vanilla armel linux?
 

Haha
More akin to "attempted" UI integration...
Some of the sharpest brains did work on it back in the day...but they couldn't do it. And I did no better following their lead and trying to puzzle out what the hell to do to make it work....
As I said ..it has always been a mess...
and not just any old mess...
A freakin' hot mess...
from its creation...to the present.

Waiting for a mod to move this thread to a better home in a subforum ...isn't a good idea...
What few mods we have are overworked as it is...
I would suggest approaching a mod and asking directly.