|
[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: Code:
cd /usr/bin/(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 Code:
$ qemu-arm -L /mnt/tmp10/scratchbox/users/maemo/targets/FREMANTLE_ARMEL ./gvm |
Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
Message 4 / 9 - Memory map continued...
Code:
ff101000-ff129000 r-xp 00000000 2b:21 791042 /mnt/tmp10/scratchbox/users/maemo/targets/FREMANTLE_ARMEL/usr/lib/libfontconfig.so.1.3.0The backtrace suggests a QEMU userspace emulation issue that I'm not especially inclined to want to follow up on :) Code:
Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. |
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):
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: Code:
# maemo-invoker /usr/bin/hildon-desktop.launch In spite of the errors, it seems some things have actually started up: Code:
# DISPLAY=:0 xwininfo -root -treeCopying 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:
|
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: Code:
$ ~/debian4/root/qemu-svnr6679/arm-softmmu/qemu-system-arm -kernel zImage -M n800 -mtdblock qemu-n800.img -m 130 -append "root=/dev/mtdblock3 rootfstype=jffs2" |
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...
Code:
omap_gpio_module_write: Read-only register 00000000The bad news: the N800 emulation is faithful to the real hardware to the point thaaaat I... cannot type. Yippee. So, I made this: Code:
#!/bin/bashIt 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 Code:
$ qemu-arm -L /mnt/tmp10/scratchbox/users/maemo/targets/FREMANTLE_ARMEL ./gvm |
Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
Message 3 / 9 - Memory map continued...
Code:
fec66000-fec76000 r-xp 00000000 2b:21 790364 /mnt/tmp10/scratchbox/users/maemo/targets/FREMANTLE_ARMEL/usr/lib/libz.so.1.2.3 |
Re: [Request + (long) progress report] How do I run Maemo (+ Hildon etc) on top of vanilla armel linux?
Message 4 / 9 - Memory map continued...
Code:
ff101000-ff129000 r-xp 00000000 2b:21 791042 /mnt/tmp10/scratchbox/users/maemo/targets/FREMANTLE_ARMEL/usr/lib/libfontconfig.so.1.3.0The backtrace suggests a QEMU userspace emulation issue that I'm not especially inclined to want to follow up on :) Code:
Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. |
| All times are GMT. The time now is 20:29. |
vBulletin® Version 3.8.8