Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 3 days, 11 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 5 days, 8 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 6 days, 5 hrs ago - more...
| The Following 2 Users Say Thank You to i336_ For This Useful Post: | ||
|
2019-06-02
, 13:12
|
|
Posts: 20 |
Thanked: 27 times |
Joined on May 2019
@ Sydney, Australia
|
#12
|
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:
Last edited by i336_; 2019-06-02 at 13:37.
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 /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - SecondaryTextColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - DefaultBackgroundColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - SelectionColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - LargeSystemFont: unknown font /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - SystemFont: unknown font /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - SmallSystemFont: unknown font /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - DefaultTextColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - NotificationTextColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - NotificationSecondaryTextColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB WARNING ** GVFS-RemoteVolumeMonitor - cannot open directory /usr/share/gvfs/remote-volume-monitors: Error opening directory '/usr/share/gvfs/remote-volume-monitors': No such file or directory /usr/bin/hildonTERM=xterm[8499]: GLIB WARNING ** Tidy - unable to load shader: GLSL shaders not supported /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - TitleTextColor: unknown color /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** default - SystemFont: unknown font /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_cairo_font_map_create_context: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** GLib-GObject - g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** GLib-GObject - g_object_set_qdata_full: assertion `G_IS_OBJECT (object)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_cairo_context_set_font_options: assertion `PANGO_IS_CONTEXT (context)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_new: assertion `context != NULL' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_set_alignment: assertion `layout != NULL' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_set_single_paragraph_mode: assertion `PANGO_IS_LAYOUT (layout)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_set_font_description: assertion `layout != NULL' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_set_justify: assertion `layout != NULL' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_set_markup_with_accel: assertion `PANGO_IS_LAYOUT (layout)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_get_context: assertion `layout != NULL' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_context_get_font_map: assertion `PANGO_IS_CONTEXT (context)' failed /usr/bin/hildonTERM=xterm[8499]: $DBUS_SESSION_BUS_ADDRESS is not set - sessionbus autoconnect blocked /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_new: assertion `context != NULL' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_egl_realize: Unable to create an EGL surface /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_egl_realize: Unable to create an EGL surface /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_egl_realize: Unable to create an EGL surface /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_egl_realize: Unable to create an EGL surface /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_cairo_font_map_create_context: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** GLib-GObject - g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** GLib-GObject - g_object_set_qdata_full: assertion `G_IS_OBJECT (object)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** Pango - pango_layout_get_iter: assertion `PANGO_IS_LAYOUT (layout)' failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_egl_realize: Unable to create an EGL surface /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_get_configs: eglChooseConfig failed /usr/bin/hildonTERM=xterm[8499]: GLIB CRITICAL ** ClutterEGL - clutter_stage_egl_realize: Unable to create an EGL surface
In spite of the errors, it seems some things have actually started up:
Code:
# DISPLAY=:0 xwininfo -root -tree
xwininfo: Window id: 0x112 (the root window) (has no name)
Root window id: 0x112 (the root window) (has no name)
Parent window id: 0x0 (none)
5 children:
0x400004 "desktop": () 800x800+0+0 +0+0
0x200003 (has no name): ("/usr/bin/hildon-desktop" "Hildon-desktop") 200x200+0+0 +0+0
2 children:
0x20001e (has no name): () 1x1+-1+-1 +-1+-1
0x200004 (has no name): () 1x1+-1+-1 +-1+-1
0x600001 (has no name): () 10x10+-20+-20 +-20+-20
0x400001 "hildon-desktop": () 5x5+-200+-200 +-200+-200
0x200001 (has no name): ("hildon-desktop" "Hildon-desktop") 10x10+10+10 +10+10
1 child:
0x200002 (has no name): () 1x1+-1+-1 +9+9
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))
Last edited by i336_; 2019-06-02 at 13:37.
| The Following 2 Users Say Thank You to i336_ For This Useful Post: | ||
|
|
2019-06-02
, 13:12
|
|
Posts: 20 |
Thanked: 27 times |
Joined on May 2019
@ Sydney, Australia
|
#13
|
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:
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" mipid_reset: Display off omap_prcm_read: Bad register 0x000040 omap_prcm_read: Bad register 0x000040 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_badwidth_read16: 16-bit register 00000000 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_i2c_write: I^2C slave mode not supported omap_i2c_write: I^2C slave mode not supported omap_i2c_write: I^2C slave mode not supported omap_i2c_write: I^2C slave mode not supported omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040 omap_disc_write: Bad register 00000000 omap_disc_write: Bad register 00000000 omap_disc_write: Bad register 00000000 omap_disc_write: Bad register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_dma4_write: Read-only register 0x000034 omap_dma4_write: Read-only register 0x000038 omap_dma4_write: Read-only register 0x00003c omap_dma4_write: Read-only register 0x000040
| The Following 2 Users Say Thank You to i336_ For This Useful Post: | ||
|
|
2019-06-02
, 13:14
|
|
Posts: 20 |
Thanked: 27 times |
Joined on May 2019
@ Sydney, Australia
|
#14
|
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
the result is hilariously disorientating )
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.)
Code:
omap_gpio_module_write: Read-only register 00000000 tsc2102_control_register_read: no such register: 0x07 tsc210x_read: SPI underrun! omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 tsc2102_audio_register_write: wrong value written into Audio 1 tsc2102_audio_register_write: wrong value written into reg 0x01 tsc2102_audio_register_write: wrong value written into reg 0x03 tsc2102_audio_register_write: wrong value written into Audio 3 tsc2102_audio_register_write: wrong value written into Audio 3 tsc2102_audio_register_write: wrong value written into Power omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 n800_mmc_cs_cb: MMC slot 2 active tsc2102_audio_register_write: wrong value written into Power tsc2102_audio_register_write: wrong value written into Audio 3 tsc2102_audio_register_write: wrong value written into Audio 3 omap_prcm_write: Bad register 0x000048 omap_prcm_write: Bad register 0x000030 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 omap_gpio_module_write: Read-only register 00000000 n800_mmc_cs_cb: MMC slot 1 active tsc2102_audio_register_write: wrong value written into Audio 3 tsc2102_audio_register_write: wrong value written into Power tahvo_write: LCD backlight now at 59 / 127 omap_prcm_write: Bad register 0x000040 omap_prcm_read: Bad register 0x000040 omap_prcm_read: Bad register 0x000040 tahvo_write: LCD backlight now at 61 / 127 tahvo_write: LCD backlight now at 63 / 127 tahvo_write: LCD backlight now at 65 / 127 tahvo_write: LCD backlight now at 67 / 127 tahvo_write: LCD backlight now at 69 / 127 tahvo_write: LCD backlight now at 71 / 127 tahvo_write: LCD backlight now at 73 / 127 tahvo_write: LCD backlight now at 75 / 127 tahvo_write: LCD backlight now at 77 / 127 tahvo_write: LCD backlight now at 79 / 127 tahvo_write: LCD backlight now at 81 / 127 tahvo_write: LCD backlight now at 83 / 127 tahvo_write: LCD backlight now at 85 / 127 tahvo_write: LCD backlight now at 87 / 127 tahvo_write: LCD backlight now at 89 / 127 tahvo_write: LCD backlight now at 91 / 127 tahvo_write: LCD backlight now at 93 / 127 tahvo_write: LCD backlight now at 95 / 127 tahvo_write: LCD backlight now at 97 / 127 tahvo_write: LCD backlight now at 99 / 127 omap_disc_write: Bad register 00000000 omap_disc_write: Bad register 00000000 omap_disc_write: Bad register 00000000 tahvo_write: LCD backlight now at 101 / 127 tahvo_write: LCD backlight now at 103 / 127 tahvo_write: LCD backlight now at 105 / 127 tahvo_write: LCD backlight now at 107 / 127 tahvo_write: LCD backlight now at 109 / 127 tahvo_write: LCD backlight now at 111 / 127 tahvo_write: LCD backlight now at 113 / 127 tahvo_write: LCD backlight now at 115 / 127 tahvo_write: LCD backlight now at 117 / 127 tahvo_write: LCD backlight now at 119 / 127 tahvo_write: LCD backlight now at 121 / 127 tahvo_write: LCD backlight now at 123 / 127 tahvo_write: LCD backlight now at 125 / 127 tahvo_write: LCD backlight now at 127 / 127 omap_prcm_read: Bad register 0x000030 omap_prcm_write: Bad register 0x000030 omap_prcm_read: Bad register 0x000048 omap_prcm_write: Bad register 0x000048 omap_prcm_write: Read-only register 00000000 tahvo_write: LCD backlight now at 125 / 127 tahvo_write: LCD backlight now at 123 / 127 tahvo_write: LCD backlight now at 121 / 127 tahvo_write: LCD backlight now at 119 / 127 tahvo_write: LCD backlight now at 117 / 127 tahvo_write: LCD backlight now at 115 / 127 tahvo_write: LCD backlight now at 113 / 127 tahvo_write: LCD backlight now at 111 / 127 tahvo_write: LCD backlight now at 109 / 127 tahvo_write: LCD backlight now at 107 / 127 tahvo_write: LCD backlight now at 105 / 127 tahvo_write: LCD backlight now at 103 / 127 tahvo_write: LCD backlight now at 101 / 127 tahvo_write: LCD backlight now at 99 / 127 tahvo_write: LCD backlight now at 97 / 127 tahvo_write: LCD backlight now at 95 / 127 tahvo_write: LCD backlight now at 93 / 127 tahvo_write: LCD backlight now at 91 / 127 tahvo_write: LCD backlight now at 89 / 127 tahvo_write: LCD backlight now at 87 / 127 tahvo_write: LCD backlight now at 85 / 127 tahvo_write: LCD backlight now at 83 / 127 tahvo_write: LCD backlight now at 81 / 127 tahvo_write: LCD backlight now at 79 / 127 tahvo_write: LCD backlight now at 77 / 127 tahvo_write: LCD backlight now at 75 / 127 tahvo_write: LCD backlight now at 73 / 127 tahvo_write: LCD backlight now at 71 / 127 tahvo_write: LCD backlight now at 69 / 127 tahvo_write: LCD backlight now at 67 / 127 tahvo_write: LCD backlight now at 65 / 127 tahvo_write: LCD backlight now at 63 / 127 tahvo_write: LCD backlight now at 61 / 127 tahvo_write: LCD backlight now at 59 / 127 tahvo_write: LCD backlight now at 57 / 127 tahvo_write: LCD backlight now at 55 / 127 tahvo_write: LCD backlight now at 53 / 127 tahvo_write: LCD backlight now at 51 / 127 tahvo_write: LCD backlight now at 49 / 127 tahvo_write: LCD backlight now at 47 / 127 tahvo_write: LCD backlight now at 45 / 127 tahvo_write: LCD backlight now at 43 / 127 tahvo_write: LCD backlight now at 41 / 127 tahvo_write: LCD backlight now at 39 / 127 tahvo_write: LCD backlight now at 37 / 127 tahvo_write: LCD backlight now at 35 / 127 tahvo_write: LCD backlight now at 33 / 127 tahvo_write: LCD backlight now at 31 / 127 tahvo_write: LCD backlight now at 29 / 127 tahvo_write: LCD backlight now at 27 / 127 tahvo_write: LCD backlight now at 25 / 127 tahvo_write: LCD backlight now at 23 / 127 tahvo_write: LCD backlight now at 21 / 127 tahvo_write: LCD backlight now at 19 / 127 tahvo_write: LCD backlight now at 17 / 127 tahvo_write: LCD backlight now at 15 / 127 tahvo_write: LCD backlight now at 13 / 127 tahvo_write: LCD backlight now at 11 / 127 tahvo_write: LCD backlight now at 9 / 127 tahvo_write: LCD backlight now at 7 / 127 tahvo_write: LCD backlight now at 5 / 127 tahvo_write: LCD backlight now at 3 / 127 tahvo_write: LCD backlight now at 0 / 127 mipid_txrx: Display off blizzard_reg_write: The display must be disabled before entering Standby Mode omap_prcm_write: Bad register 0x000040
The 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/bash
win_id=$(xdotool search --classname qemu-system-arm)
eval $(xdotool getwindowgeometry --shell $win_id)
win_x=$X
win_y=$Y
qemu_window=$WINDOW
declare -A k
k[24]=360,200 #q
k[25]=360,239 #w
k[26]=360,277 #e
k[27]=360,310 #r
k[28]=360,346 #t
k[29]=360,379 #y
k[30]=360,415 #u
k[31]=360,449 #i
k[32]=360,491 #o
k[33]=360,521 #p
k[38]=395,189 #a
k[39]=395,219 #s
k[40]=395,253 #d
k[41]=395,390 #f
k[42]=395,329 #g
k[43]=395,359 #h
k[44]=395,398 #j
k[45]=395,432 #k
k[46]=395,464 #l
k[52]=430,200 #z
k[53]=430,243 #x
k[54]=430,282 #c
k[55]=430,310 #v
k[56]=430,346 #b
k[57]=430,379 #n
k[58]=430,415 #m
k["11,0x1"]=360,569 #@
k[47]=394,500 #;
k[48]=394,537 #'
k["10,0x1"]=394,578 #!
k[60]=430,489 #.
k[61]=430,521 #/
k[65]=464,410 #<space>
k[10]=355,623 #1
k[11]=355,657 #2
k[12]=355,699 #3
k[13]=392,623 #4
k[14]=392,657 #5
k[15]=392,699 #6
k[16]=427,623 #7
k[17]=427,657 #8
k[18]=427,699 #9
k[19]=461,623 #-
k[19]=461,657 #0
k[19]=461,699 #=
xinput test-xi2 --root |\
stdbuf -i0 -o0 grep '(KeyPress)' -A 7 |\
stdbuf -o0 sed -n 's/.*effective: //p; s/.*detail: //p' |\
stdbuf -o0 sed 'N;s/\n/,/;s/,0$//' |\
while read x; do
echo $x
eval $(xdotool getmouselocation --shell)
old_x=$X
old_y=$Y
case $x in
22) # backspace
z=(356 755)
;;
36) # enter
z=(392 755)
;;
*)
[[ "${k["$x"]}" == "" ]] && continue
IFS=, z=(${k["$x"]})
;;
esac
xdotool \
mousemove $((win_x+${z[1]})) $((win_y+${z[0]})) \
mousedown 1 \
sleep 0.1 \
mouseup 1 \
sleep 0.1 \
mousemove $old_x $old_y
done
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
the result is hilariously disorientating )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.)
| The Following 3 Users Say Thank You to i336_ For This Useful Post: | ||
|
|
2019-06-02
, 13:15
|
|
Posts: 20 |
Thanked: 27 times |
Joined on May 2019
@ Sydney, Australia
|
#15
|
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:
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
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
Code:
$ ~/debian4/root/qemu-svnr6679/arm-softmmu/qemu-system-arm -kernel zImage -M n810 -mtdblock n810.img -m 130 -append "root=/dev/mtdblock3 rootfstype=jffs2" mipid_reset: Display off ^C
Code:
$ ~/debian4/root/qemu-svnr4980/arm-softmmu/qemu-system-arm -kernel zImage -M n810 -mtdblock n810.img -m 130 -append "root=/dev/mtdblock3 rootfstype=jffs2" mipid_reset: Display off ^C
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":
Code:
$ rg SGX
hw/arm/omap3.c
93: {0x0400, L3TYPE_IA}, /* SGXSS_IA */
110: {0x0400, L3TYPE_TA}, /* SGXSS_TA */
1673: /* SGX_PRM */
1678: /* TODO: support SGX wakeup control. For now let's keep the
1679: * SGX domain always in ON state, never changing */
1996: /* SGX_CM: base + 0x0b00 */
2648: /* SGX_CM */
2857: /* SGX_CM */
2860: case 0xb40: s->cm_clksel_sgx = value; break; /* TODO: SGX clock */
include/hw/arm/omap.h
482:#define OMAP_INT_3XXX_SGX_IRQ 21 /* 2D/3D graphics module */
Code:
$ rg sgx hw/arm/omap3.c 1254: struct omap3_prm_domain_s sgx; 1356: memset(&s->sgx, 0, sizeof(s->sgx)); 1357: s->sgx.rm_rstst = 0x1; 1358: s->sgx.pm_wkdep = 0x16; 1359: s->sgx.pm_pwstctrl = 0x30107; 1360: s->sgx.pm_pwstst = 0x3; 1439: case 0x0b: d = &s->sgx; break; 1674: case 0x0b58: s->sgx.rm_rstst &= ~(value & 0xf); break; 1675: case 0x0bc8: s->sgx.pm_wkdep = value & 0x16; break; 1677: s->sgx.pm_pwstctrl = 0x030104 | (value & 0x3); 1680: s->sgx.pm_pwstst = 0x3; 1681: s->sgx.pm_prepwstst = s->sgx.pm_pwstst; 1997: uint32_t cm_fclken_sgx; /* 00 */ 1998: uint32_t cm_iclken_sgx; /* 10 */ 1999: uint32_t cm_idlest_sgx; /* 20 */ 2000: uint32_t cm_clksel_sgx; /* 40 */ 2001: uint32_t cm_sleepdep_sgx; /* 44 */ 2002: uint32_t cm_clkstctrl_sgx; /* 48 */ 2003: uint32_t cm_clkstst_sgx; /* 4c */ 2527: s->cm_fclken_sgx = 0x0; 2528: s->cm_iclken_sgx = 0x0; 2529: s->cm_idlest_sgx = 0x1; 2530: s->cm_clksel_sgx = 0x0; 2531: s->cm_sleepdep_sgx = 0x0; 2532: s->cm_clkstctrl_sgx = 0x0; 2533: s->cm_clkstst_sgx = 0x0; 2649: case 0x0b00: return s->cm_fclken_sgx; 2650: case 0x0b10: return s->cm_iclken_sgx; 2651: case 0x0b20: return s->cm_idlest_sgx & 0x0; 2652: case 0x0b40: return s->cm_clksel_sgx; 2653: case 0x0b44: return s->cm_sleepdep_sgx; 2654: case 0x0b48: return s->cm_clkstctrl_sgx; 2655: case 0x0b4c: return s->cm_clkstst_sgx; 2858: case 0xb00: s->cm_fclken_sgx = value & 0x2; break; 2859: case 0xb10: s->cm_iclken_sgx = value & 0x1; break; 2860: case 0xb40: s->cm_clksel_sgx = value; break; /* TODO: SGX clock */ 2861: case 0xb44: s->cm_sleepdep_sgx = value & 0x2; break; 2862: case 0xb48: s->cm_clkstctrl_sgx = value & 0x3; break;
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:
Code:
$ /data/qemu-linaro/arm-softmmu/qemu-system-arm -M n900 -mtdblock RX-51_2009SE_20.2010.36-2.nand -sd RX-51_2009SE_20.2010.36-2.emmc -serial mon:stdio -clock unix -redir tcp:2224:10.0.2.15:22 -redir tcp:13219:10.0.2.15:10000 (process:29852): GLib-WARNING **: 00:01:44.551: ../glib/glib/gmem.c:490: custom memory allocation vtable not supported NOLO X-Loader (v1.4.14, Jun 3 2010) Secondary image size 98440 Booting secondary [ 0.001] Nokia OMAP Loader v1.4.13 (Dec 1 2009) running on Nokia N900 S4.0 GP (RX-51) [ 0.013] I2C v3.12 [ 0.018] System DMA v4.0 [ 0.024] OneNAND device ID 0040, version ID 0121 (256 MiB, 66 MHz) [ 0.036] OneNAND blocks unlocked in 18055 us [ 0.042] Flash id: ec4021 [ 0.062] Partition table successfully read [ 0.197] TWL4030 PWR ISR: 01 [ 0.199] Forcing power key boot reason (R&D flag set) [ 0.203] Reset reason: pwr_key [ 0.205] McSPI v2.1 [ 0.208] ERROR: LP5523 not found [ 0.210] SMB138C: Not loading driver (version reg. 0x49) [ 0.213] BQ24150 (rev. 1) found on I2C bus 1, address 0x6b [ 0.214] SSI version 1.0 [ 0.215] Battery voltage 6.012 V, BSI: 0 [ 0.215] Disabling charging (R&D flag set) [ 0.216] Initializing LCD panel [ 0.216] Detecting LCD panel moscow [ 0.218] Panel ID: 101234 [ 0.218] Detected LCD panel: acx565akm [ 0.218] DISPC: version 3.0 [ 0.222] LCD pixel clock 24000 kHz [ 0.231] Logo drawn in 15 ms (3900 kB/s) [ 0.359] Über-cool backlight fade-in took 128 ms [ 0.360] Initializing USB [ 0.362] No USB host detected [ 0.362] Loading kernel image info Loading kernel (1961 kB)... done in 565 ms (3469 kB/s) [ 0.919] Loading initfs image info [ 0.920] Total bootup time 1591 ms [ 0.922] Serial console enabled U-Boot 2013.04 (Apr 20 2013 - 11:00:56) OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz Nokia RX-51 + LPDDR/OneNAND I2C: ready DRAM: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In: vga Out: vga Err: vga SD: ACMD41 in a wrong state SD: CMD1 in a wrong state SD: ACMD41 in a wrong state SD: CMD1 in a wrong state SD: ACMD41 in a wrong state SD: CMD1 in a wrong state SD: ACMD41 in a wrong state SD: CMD1 in a wrong state Uncompressing Linux................................................................................................................... done, booting the kernel. tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled tsc2005_txrx_word: touchscreen sense disabled tsc2005_write: touchscreen sense enabled QEMU: Terminated
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
| The Following 3 Users Say Thank You to i336_ For This Useful Post: | ||
 |
|
2019-06-02
, 14:52
|
|
Posts: 1,702 |
Thanked: 4,752 times |
Joined on Apr 2018
@ Helsinki, Finland.
|
#16
|
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.
__________________
"I don't know how but I can try!" (active)
Master of not knowing (active)
For me it is possible to get lost in any case (active)
Learning to fall from high (DONE)
Learning to code with BASIC (WIP)
"I don't know how but I can try!" (active)
Master of not knowing (active)
For me it is possible to get lost in any case (active)
Learning to fall from high (DONE)
Learning to code with BASIC (WIP)
| The Following 7 Users Say Thank You to Maemish For This Useful Post: | ||
 |
|
2019-06-02
, 19:46
|
|
Posts: 3,139 |
Thanked: 8,156 times |
Joined on Feb 2013
@ From my Gabriola Island hermitage, near the Edge of the World
|
#17
|
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.
Last edited by endsormeans; 2019-06-03 at 00:57.
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.
__________________
Lurker since 2007, Member since 2013, Certifiable since 1972
Owner of :
1-n770 (in retirement), 3-n800's / 3-n810's (still in daily use), 5-n900's ((3 are flawless, 1 loose usb ( parts), 1 has no telephony (parts))
3-nexus 5's : 1 w/ Floko Pie 9.1 (running beautifully) waiting for Stable Droid 10 rom, 1 w/ ̶Ubuntu Touch, 1 with Maru OS (intend maemo leste when ready)
1/2 - neo900 pre- "purchased" in 2013. N̶o̶w̶ ̶A̶w̶a̶i̶t̶i̶n̶g̶ ̶r̶e̶f̶u̶n̶d̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶l̶a̶s̶t̶ ̶f̶e̶w̶ ̶y̶e̶a̶r̶s̶ - neo900 start up declared officially dead -
Lost invested funds.
PIMP MY N8X0 (Idiot's Guide and a video walkthrough)http://talk.maemo.org/showthread.php?t=94294
THE LOST GRONMAYER CATALOGShttp://talk.maemo.org/showthread.php...ight=gronmayer
N8X0 VIDEO ENCODING THE EASY WAYhttp://talk.maemo.org/showthread.php...ght=mediacoder
242gb ON N800http://talk.maemo.org/showthread.php?t=90634
THE PAIN-FREE MAEMO DEVELOPMENT LIVE DISTRO-ISO FOR THE NOOB TO THE PROhttp://talk.maemo.org/showthread.php?t=95567
AFFORDABLE MASS PRODUCTION FOR MAEMO PARTShttp://talk.maemo.org/showthread.php?t=93325
Meateo balloons now available @ Dave999's Meateo Emporium
Lurker since 2007, Member since 2013, Certifiable since 1972
Owner of :
1-n770 (in retirement), 3-n800's / 3-n810's (still in daily use), 5-n900's ((3 are flawless, 1 loose usb ( parts), 1 has no telephony (parts))
3-nexus 5's : 1 w/ Floko Pie 9.1 (running beautifully) waiting for Stable Droid 10 rom, 1 w/ ̶Ubuntu Touch, 1 with Maru OS (intend maemo leste when ready)
1/2 - neo900 pre- "purchased" in 2013. N̶o̶w̶ ̶A̶w̶a̶i̶t̶i̶n̶g̶ ̶r̶e̶f̶u̶n̶d̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶l̶a̶s̶t̶ ̶f̶e̶w̶ ̶y̶e̶a̶r̶s̶ - neo900 start up declared officially dead -
Lost invested funds.
PIMP MY N8X0 (Idiot's Guide and a video walkthrough)http://talk.maemo.org/showthread.php?t=94294
THE LOST GRONMAYER CATALOGShttp://talk.maemo.org/showthread.php...ight=gronmayer
N8X0 VIDEO ENCODING THE EASY WAYhttp://talk.maemo.org/showthread.php...ght=mediacoder
242gb ON N800http://talk.maemo.org/showthread.php?t=90634
THE PAIN-FREE MAEMO DEVELOPMENT LIVE DISTRO-ISO FOR THE NOOB TO THE PROhttp://talk.maemo.org/showthread.php?t=95567
AFFORDABLE MASS PRODUCTION FOR MAEMO PARTShttp://talk.maemo.org/showthread.php?t=93325
Meateo balloons now available @ Dave999's Meateo Emporium
Last edited by endsormeans; 2019-06-03 at 00:57.
|
|
2019-06-03
, 02:57
|
|
Posts: 20 |
Thanked: 27 times |
Joined on May 2019
@ Sydney, Australia
|
#18
|
Maemish: it's okay 
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.
so you actually did the UI integration work. Nice.
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
Thanks for the replies! I'll go say hello to the Leste team and see what happens from that. (Edit with thread URL pending...)
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.
Originally Posted by endsormeans
Wow, cool
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.
so you actually did the UI integration work. Nice.
Originally Posted by endsormeans
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.
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 ...
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
Thanks for the replies! I'll go say hello to the Leste team and see what happens from that. (Edit with thread URL pending...)
| The Following 2 Users Say Thank You to i336_ For This Useful Post: | ||
|
|
2019-06-03
, 03:38
|
|
Posts: 3,139 |
Thanked: 8,156 times |
Joined on Feb 2013
@ From my Gabriola Island hermitage, near the Edge of the World
|
#19
|
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.
Last edited by endsormeans; 2019-06-03 at 03:44.
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.
__________________
Lurker since 2007, Member since 2013, Certifiable since 1972
Owner of :
1-n770 (in retirement), 3-n800's / 3-n810's (still in daily use), 5-n900's ((3 are flawless, 1 loose usb ( parts), 1 has no telephony (parts))
3-nexus 5's : 1 w/ Floko Pie 9.1 (running beautifully) waiting for Stable Droid 10 rom, 1 w/ ̶Ubuntu Touch, 1 with Maru OS (intend maemo leste when ready)
1/2 - neo900 pre- "purchased" in 2013. N̶o̶w̶ ̶A̶w̶a̶i̶t̶i̶n̶g̶ ̶r̶e̶f̶u̶n̶d̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶l̶a̶s̶t̶ ̶f̶e̶w̶ ̶y̶e̶a̶r̶s̶ - neo900 start up declared officially dead -
Lost invested funds.
PIMP MY N8X0 (Idiot's Guide and a video walkthrough)http://talk.maemo.org/showthread.php?t=94294
THE LOST GRONMAYER CATALOGShttp://talk.maemo.org/showthread.php...ight=gronmayer
N8X0 VIDEO ENCODING THE EASY WAYhttp://talk.maemo.org/showthread.php...ght=mediacoder
242gb ON N800http://talk.maemo.org/showthread.php?t=90634
THE PAIN-FREE MAEMO DEVELOPMENT LIVE DISTRO-ISO FOR THE NOOB TO THE PROhttp://talk.maemo.org/showthread.php?t=95567
AFFORDABLE MASS PRODUCTION FOR MAEMO PARTShttp://talk.maemo.org/showthread.php?t=93325
Meateo balloons now available @ Dave999's Meateo Emporium
Lurker since 2007, Member since 2013, Certifiable since 1972
Owner of :
1-n770 (in retirement), 3-n800's / 3-n810's (still in daily use), 5-n900's ((3 are flawless, 1 loose usb ( parts), 1 has no telephony (parts))
3-nexus 5's : 1 w/ Floko Pie 9.1 (running beautifully) waiting for Stable Droid 10 rom, 1 w/ ̶Ubuntu Touch, 1 with Maru OS (intend maemo leste when ready)
1/2 - neo900 pre- "purchased" in 2013. N̶o̶w̶ ̶A̶w̶a̶i̶t̶i̶n̶g̶ ̶r̶e̶f̶u̶n̶d̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶l̶a̶s̶t̶ ̶f̶e̶w̶ ̶y̶e̶a̶r̶s̶ - neo900 start up declared officially dead -
Lost invested funds.
PIMP MY N8X0 (Idiot's Guide and a video walkthrough)http://talk.maemo.org/showthread.php?t=94294
THE LOST GRONMAYER CATALOGShttp://talk.maemo.org/showthread.php...ight=gronmayer
N8X0 VIDEO ENCODING THE EASY WAYhttp://talk.maemo.org/showthread.php...ght=mediacoder
242gb ON N800http://talk.maemo.org/showthread.php?t=90634
THE PAIN-FREE MAEMO DEVELOPMENT LIVE DISTRO-ISO FOR THE NOOB TO THE PROhttp://talk.maemo.org/showthread.php?t=95567
AFFORDABLE MASS PRODUCTION FOR MAEMO PARTShttp://talk.maemo.org/showthread.php?t=93325
Meateo balloons now available @ Dave999's Meateo Emporium
Last edited by endsormeans; 2019-06-03 at 03:44.
| The Following User Says Thank You to endsormeans For This Useful Post: | ||
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....
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.
Last edited by i336_; 2019-06-02 at 13:36.