maemo.org - Talk - Mer v0.6 released

maemo.org - Talk (https://talk.maemo.org/index.php)

- Alternatives (https://talk.maemo.org/forumdisplay.php?f=36)

- - Mer v0.6 released (https://talk.maemo.org/showthread.php?t=26310)

Re: Mer v0.6 released

Quote:

Originally Posted by meizirkki (Post 259975)

yeah i know, keyboard was working in 0.6 release. But all keys of n8x0 hw-keyboard are dead in later versions made with imager

Can you check if HAL recognize the keyboard?

$ lshal | grep "Internal keyboard"

If yes, can you paste the Xorg.0.log ?

Re: Mer v0.6 released

Keyboard works now, Stskeeps pointed me to upgrade hal.

Re: Mer v0.6 released

Hint:

For right button emulation do following:

apt-get install libgtkstylus

create file /etc/X11/Xsession.d/98x11-gtk_stylus and write there simply

export GTK_MODULES=libgtkstylus.so

Unfortunately, it works for gtk based apps only

Re: Mer v0.6 released

On IRC they say no wireless for 770 at this time. What is missing? A quick overview of the state of 770 wireless, which pieces (kernel, userspace, calibration) are problematic for new kernels, etc or a link, as well as advice for how to proceed with trying to get mir/770/wireless working for someone with who is willing to learn scratchbox etc would be enormously helpful.

Re: Mer v0.6 released

Quote:

On IRC they say no wireless for 770 at this time. What is missing? A quick overview of the state of 770 wireless, which pieces (kernel, userspace, calibration).

Pretty simple really - I haven't made a kernel .ko of cx3110x with wireless extensions of it yet for that kernel - if anyone want to gather up all the patches and build it for the kernel, they're most welcome

Re: Mer v0.6 released

Quote:

Originally Posted by solca (Post 259916)

It doesn't work with that patch. Exactly same as before.

My experiment failed. I added that patch and other ATAG and kexec patches (some by hand) from this site to the diablo 4.1.2 kernel. I then patched kexec-tools for armv6l. All was a no-go, but it wasn't like I really knew what I was doing. From a fanoush-like bootmenu, here was the script that caused my n800 to go blank and eventually shut off:

Code:

#! /bin/sh



/usr/local/sbin/kexec -l /boot/zImage "--append=root=1f03 rootfstype=jffs2 ro console=t

chvt 1 || true

killall5 -15

sleep 2

killall5 -9

umount -r /mnt/initfs

umount -r /

/usr/local/sbin/kexec -e

The middle part of this script is from /etc/init.d/minishutdown. Comments about what this script should be trying to do would be appreciated. But because of the active kexec development since 2.6.21, I'm less-than-skeptical that patching a 2.6.21 kernel is the right way to go. And this is also the reason, unless anyone can suggest something obvious, that I'm unlikely to try and further debug this simple experiment.

Here's what processes were running at the time:

Code:

  PID  Uid        VSZ Stat Command

    1 root       1888 RW  /bin/sh /sbin/init 2

    2 root            SWN [ksoftirqd/0]

    3 root            SW  [watchdog/0]

    4 root            SW< [events/0]

    5 root            SW< [khelper]

    6 root            SW< [kthread]

   14 root            SW< [dvfs/0]

   66 root            SW< [kblockd/0]

   67 root            SW< [kseriod]

   79 root            SW< [OMAP McSPI/0]

   86 root            SW< [ksuspend_usbd]

   89 root            SW< [khubd]

  113 root            SW  [pdflush]

  114 root            SW  [pdflush]

  115 root            SW< [kswapd0]

  116 root            SW< [aio/0]

  119 root            SW< [mipid_esd]

  238 root            SW  [mtdblockd]

  280 root            SW< [kondemand/0]

  281 root            SW< [kmmcd]

  292 root            SW< [krfcommd]

  307 root            SW< [mmcqd]

  343 root            SW< [mmcqd]

  350 root       1072 SW< dsme -d -l syslog -v 4 -p /usr/lib/dsme/libstartup.so

  358 root        804 SW  /usr/bin/bme_RX-34

  360 root        564 SW  /usr/sbin/kicker

  494 root            SW< [cx3110x]

  539 root       1960 RW  ps

And here is my current opinion:

If Nokia is serious about minimal mid-term support of n8x0 hardware, they need to release the NoLo secondary code. Much time, energy and resources could be saved. I would go as far as saying that some people would sign ND agreements if necessary. We need a flexible, grub-like, blob.

Most people like smooth transitions, so unless they can easily bounce back to their working Maemo 4.1.2, they're less likely to experiment with a 2.6.27 Mer bleeding edge. I'm not sure I could be convinced otherwise, but I don't think on-tablet kernel/initfs flashing is a solution. It's cool... but not a solution. Just look at the ease of trying-out the other OS/WM projects that shared a kernel. Now it's time for multiple kernels and their modules to share some hardware.

In the meantime, I'll see if there's anything I can do for the Mer project and I'll be patiently waiting for n8x0-compatible Fremantle binaries.

Re: Mer v0.6 released

kexec thought: kick watchdog just before booting the new kernel?

Re: Mer v0.6 released

Quote:

Originally Posted by daperl (Post 260212)

My experiment failed.
...
But because of the active kexec development since 2.6.21, I'm less-than-skeptical that patching a 2.6.21 kernel is the right way to go.

IMO you're too pesimistic. kexec was working on arm on other devices even with earlier kernels. I doubt there was any big development except keeping up with kernel changes. So you did expect success on first try?

Well, even if solca was luckier with recent kernel, it may still be something trivial or relatively easy. And even kexecing 2.6.21 from 2.6.27 is not much worse as long as diablo kernel runs and system boots.

Quote:

Originally Posted by daperl (Post 260212)

Here's what processes were running at the time:

It may be safer to run it right after boot, not at shutdown time. At boot time less hardware is initialized to unknown state. But anyway I tried similar experiment directly from linuxrc in initfs even before dsme bme etc is started but with same result, it hangs and powers off after some time.

Quote:

Originally Posted by daperl (Post 260212)

If Nokia is serious about minimal mid-term support of n8x0 hardware, they need to release the NoLo secondary code. Much time, energy and resources could be saved.

would be really nice for many reasons but I'm not sure it is strictly needed and would do miracles. I doubt NOLO could load kernel from mmc (or jffs2) anyway. And BTW if linux kernel/kexec is too heavy one could always replace the kernel with something easier (like uboot?), linux kernel entry point is documented so one can start there.

Here are my speculations why it doesn't work with diablo 2.6.21 kernel:
- newer kexec userspace loader is incompatible with older kexec kernel code, going to earlier versions could help
- hardware is not intialized to same state so drivers in second kernel get confused, stripping drivers from first kernel could help. Also if kexec calls drivers in first kernel to stop the hardware before jumping into second kernel there may be some bugs there since this may not be used in normal situation at all. Or it may stop too much, one example is video driver, framebuffer is initialized in bootloader and linux does not mess with it too much at startup time to not to disturb boot logo but the driver shutdown code may turn off too much.

But since solca got success with recent kernel we may be quite lucky and it is not so bad. My first random guess is the DSP since it is most probably not touched by recent kernels at all (unlike with 2.6.21). At least I think dspgateway is not present/enabled/working in recent kernels (?). But it can be anything else too.

Anyway, the point of my post is that there is a lot of ideas to try before giving up.

As for watchdog, there should be plenty of time. I takes long time before it powers itself off. IIRC the retu watchdog is set to ~60 seconds and is kicked every 5 seconds or so.

Re: Mer v0.6 released

And BTW it would be interesting to debug kexec from recent qemu n8x0 system emulation. It does not emulate everything (most notably the DSP) and timing may not be accurate but troubleshooting generic kexec stuff could be easier than with real hardware.

Re: Mer v0.6 released

Quote:

Originally Posted by fanoush (Post 260264)

I expected a monkey to fly out of my butt... And it did!

But seriously, this stuff interests me. And after a quick chat @ IRC and your post, I've decided to stick with it. But I know that someone else could get there light years sooner. Like Russell King! The god of all things ARM-linux.

Quote:

Well, even if solca was luckier with recent kernel, it may still be something trivial or relatively easy. And even kexecing 2.6.21 from 2.6.27 is not much worse as long as diablo kernel runs and system boots.

It could be trivial. I would like to stay on a naive path, but if I end up adding debug to kexec I'll know I'll be deep in the muck. That's okay. :)

Quote:

Yes, I'm with you. Starting up the Nokia stuff could be delayed as needed. For about 7 months now, I've been using something I call "the double fanoush." You have to say it real fast; it kinda sounds like "baba ghanoush." I'ts just a menu script replacement for /sbin/init on the SD OS partition. I did this so I could hack before booting without thrashing the internal flash. And obviously the internal initfs could be reworked to pass more responsibility to this 2nd init. I just bought a new n810 that should arrive tomorrow, I'm hoping the hardware keyboard will let me fake a terminal at this point in the boot. I was too lazy to create a d-pad keyboard for the n800 and I never looked into the USB options. :rolleyes:

Quote:

It's funny you should mention this. Just yesterday, I took an SD card and I dd' initfs.jffs to the first partition. I then rebuilt the kernel with root=fe09 (/dev/mmcblock1p1) as a cmdline change. Needless to say, it didn't work. But when I saw that MMC was built into the kernel I had to try. Also, why is the initfs /dev hardcoded with all those mmcblock devices if someone wasn't suppose to try this? The major and minor codes are the same after udev, so I just thought... Scary, isn't it?

Thanks for reminding me, I started this quest looking at the u-boot stuff over at the Pandora and Beagle Board projects. Maybe I'll go back there when kexec is done kicking my a*s. I wonder if that's where Russell King is hanging out.

Quote:

Here are my speculations why it doesn't work with diablo 2.6.21 kernel:
- newer kexec userspace loader is incompatible with older kexec kernel code, going to earlier versions could help

Yes, this is one of my fears. This will take some concentration and some good bookkeeping. Currently, I'm in denial.

Quote:

- hardware is not initialized to same state so drivers in second kernel get confused, stripping drivers from first kernel could help. Also if kexec calls drivers in first kernel to stop the hardware before jumping into second kernel there may be some bugs there since this may not be used in normal situation at all. Or it may stop too much, one example is video driver, framebuffer is initialized in bootloader and linux does not mess with it too much at startup time to not to disturb boot logo but the driver shutdown code may turn off too much.

This might be the golden goose. Great idea. My original plan was to use just one kernel for my proof-of-concept. But if linux is going to boot linux, a minimal loading-linux is certainly the way to go.

Quote:

But since solca got success with recent kernel we may be quite lucky and it is not so bad. My first random guess is the DSP since it is most probably not touched by recent kernels at all (unlike with 2.6.21). At least I think dspgateway is not present/enabled/working in recent kernels (?). But it can be anything else too.

[bullhorn]solca, we need more info about your kexec success.[/bullhorn]

Quote:

Anyway, the point of my post is that there is a lot of ideas to try before giving up.

Yes, of course. And I appreciate you taking the time to respond. Like I said, this stuff interests me, and maybe there's no time like the present.

Quote:

As for watchdog, there should be plenty of time. I takes long time before it powers itself off. IIRC the retu watchdog is set to ~60 seconds and is kicked every 5 seconds or so.

The guys at IRC gave me this value to set: /sys/devices/platform/retu-watchdog/period. I dumped it to my debug and it said it was 63. So I think that's good already.

Time to digest some things. New plan to follow.