Re: Mer v0.6 released
 

hi

i didn't read the thread completly from the beginning to the end, but is it possible to put mer into scratchbox + xephyr?

i really would like to be the first with my project (easy-sdk), who provides this kind of installation..

greatings, thopiekar

Re: Mer v0.6 released
 

You don't even have to :) You can use Xephyr + a chroot (described at http://wiki.maemo.org/Mer_Blueprint#...n_.28chroot.29, run it in it's own virtual machine (VDI) - it runs on x86 so you don't need to test on a scratchbox.

Re: Mer v0.6 released
 

You need to compile your kernel with CONFIG_BOOT_PRINTK_DELAY set and pass the boot parameter 'boot_delay=X' where X is ms. I pass 100ms and it works without the need for serial-console R&D flag. Please keep us posted on your findings.

I tried to kexec the 2.6.21 kernel from a kexec capable 2.6.28 and it only works with serial-console flag. On the other side a 2.6.28 kexeced kernel works without serial-console flag iff you insert the above printk delays. I didn't tried a 2.6.21 kernel with delays tho.

BTW I have not tried to insert delays before jumping nor switching to slower CPU freqs as I'm not a very bright kernel hacker :p

Re: Mer v0.6 released
 

I've updated the Mer pages and split them up properly, as to structure the work with Mer more.

If you would like to participate in Mer actively, please read http://wiki.maemo.org/Mer and http://wiki.maemo.org/Mer/Sprints - it's a matter of signing up by e-mail and getting listed, and then participating in the sprints, no tests or interviews :)

We will try to employ microblogging as a means to deal with the fact it can be difficult to have real-time conversations, and to be able to render eachothers activities visible to eachother. More information in the Sprints wiki page.

Re: Mer v0.6 released
 

Thanks for the info, but I am no kernel hacker. Sometimes I get lucky with a conservative, naive (minimize the variables) approach when I accept that I'm in over my head. :) Thus, I have a simple goal with a simple approach.

My goal:

To enhance my tablet, not significantly modify it. That means it will work as is with the added ability to kexec into at least one other kernel/OS.

My approach:

I'm currently running an unmodified maemo 5.2008.43-7 kernel (latest Diablo SSU). I will patch this kernel only for successful kexec ability. When I'm satisfied with this kernel I will then:

• clone an initfs (for this, maybe Nokia's instead of fanoush's) and modify this clone if needed
• clone my primary OS partition (/dev/mmcblk0p3) and modify this clone if needed
• add the new kernel to /boot of one of these cloned partitions
• add a kexec entry to the flash initfs bootmenu for the cloned kernel/initfs/OS

If I can "successfully" boot and run this new entry the goal will be satisfied.

Because I'm very happy with my n800 as is, I would hope that a slightly modified maemo 5.2008.43-7 (2.6.21-omap1) kernel could be a good enough slave/boot kernel for any kernel/OS combination that can be thrown at it. If not, well...

Also, consider this a challenge to the rest of the hack monsters out there to beat me to the punch. Some of you already seem fairly close to the finish line; because of my parenting responsibilities, I probably won't even start patching till Friday. So, on your mark...Get set...Go!

More as I know.

Re: Mer v0.6 released
 

This kexec patch was just submitted yesterday inside the Ubuntu Kernel Team. Could be interesting:

The kexec syscall function is broken on ARM due to it not properly calling
the relocation stub with the correct arguments. This patch puts machine_kexec
in line with the other architectures, and allows kexec to work peroply on ARM.
It has been tested on the versatile kernel successfully.

Re: Mer v0.6 released
 

Will try and report back...

Re: Mer v0.6 released
 

Are the mer repositories down? http://repository.mer.tspre.org/ has been unavailable from the UK (at least) since yesterday.

Re: Mer v0.6 released
 

Sorry for the delay in responding. I was laid up in hospital for a few days.

The second download was successful and matched your md5sum. This is my first try at virtualbox. The instructions given were clear enough but I wound up with the attached screenshots.

What am I doing wrong?

thailbill

Re: Mer v0.6 released
 

I had no problems running Mer in VB. Maybe you should rename the image and add it to the disk manager.

Re: Mer v0.6 released
 

Latest FireFox is as fast to use as midori.

Re: Mer v0.6 released
 

And has SSL? :)

Re: Mer v0.6 released
 

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

Re: Mer v0.6 released
 

It's FF 3.1 beta 2, i don't know if it shoud have..

Re: Mer v0.6 released
 

I meant that Midori/WebKit Gtk doesn't support self-signed certificates :)

Re: Mer v0.6 released
 

Hi, can someone post step-by-step instruction? I install both files from Mer page on wiki.maemo.org, but I can`t mount my Mer partition. :rolleyes: I`m try to install Mer on N800.

Re: Mer v0.6 released
 

I spent this weekend playing with N810 external keyboard and looking why doesn't work as in Maemo. I have no solution yet, but I can name the problem. Xorg and HAL. Xorg depend on HAL, which should provide keyboard info. HAL will recognize hardware keyboard as "Internal keyboard", working with evdev driver.

Problem is, that Fn key is sending keycode 464 (according to /usr/include/linux/input.h it's really right keycode for FN key), but X server can't handle keycode > 255.

It seems, that Xomap use some ugly hack for this key (see this: https://bugs.maemo.org/show_bug.cgi?id=3021) and remap keycode 464 to 216.

I tried to use HAL to remap keyboard and I created following fdi:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">
<device>

<!-- These are raw scancodes produced by the atkbd driver -->
<match key="info.product" string="Internal keyboard">
<append key="input.keymap.data" type="strlist">0x1d0:chat</append>
<append key="info.capabilities" type="strlist">input.keymap</append>
</match>
</device>
</deviceinfo>

This should remap key 464 to 216(chat). In lshal, I can see my new rule

root@michal-tablet:~# lshal | grep keymap
info.capabilities = {'input', 'input.keyboard', 'input.keys', 'button', 'input.keymap'} (string list)
input.keymap.data = {'0x1d0:chat'} (string list)

But Xorg still don't catch any keycode for Fn key. Any suggestion how to continue? I would like to find clear solution using HAL, instead of dirty hacking evdev driver :)

Re: Mer v0.6 released
 

Any key of my n810:s hw-keyboard isn't working in Mer atm.

Re: Mer v0.6 released
 

They works for me, just without fn button... try to:

1. Delete InputDevice for keyboard from xorg.conf. All informations will come from HAL.
2. Install xserver-xorg-input-evdev
3. Restart HAL
4. Restart xorg

Re: Mer v0.6 released
 

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

Re: Mer v0.6 released
 

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
 

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
 

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:
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:
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
 

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.
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.

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
 

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.

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. :)

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:

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.

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

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.

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

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.

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.

Re: Mer v0.6 released
 

Sadly the more experienced person the less time they have for such experiments. There is plenty of people with skills far better than ours, linux-omap list is place to meet them. OTOH sometimes skill can be replaced by luck or lot of time spent trying semi-random things :-)
Oh I see, I was confused with '/sbin/init 2' and wifi driver kernel thread and the minishutdown reference too so I thought you tried it at device shutdown time.

Using qemu may be easier, I'll try that when I have some time (pretty scarce thing for me nowadays and no sign of it getting better). qemu can boot kernel directly but in our case the better mode is to let it boot from bootloader and let the emulation run NOLO and load kernel. With real device enabling framebuffer console in both kernels (and/or having serial console attached) could help to see where it fails.

yes, jffs2 does not work directly with block devices (=mmc), tar clone or cp -a of initfs would be better and also ext2 in kernel could help a lot :-)

Yes and in that case the version of the first kernel doesn't matter much as long as it can load the diablo one from somewhere. Having one kernel as you suggested would be certainly much easier if we can get it to work.

Re: Mer v0.6 released
 

Wow, fanoush, you summarized my entire approach to hacking on the tablet, right there: ".... skill replaced by ... a lot of time spent trying semi-random things"

And you're right, occasionally that approach succeeds!

Re: Mer v0.6 released
 

The sad, universal constant is that their documentation skills are inversely proportional to their technical skills. These people need personal writing assistants. They could also fetch coffee.

And for them, it would be a project, not an experiment. :)

You're probably right, but see my kernel-diversion comments below. I have major-kernel-releases on the brain. Maybe I'll revisit this later.

If I understand you correctly, it sounds like I was trying to mix and match my character and block device metaphors. I think the initfs hard-coded mmcblock devices are valid. And I notice that these 2 [mmcqd] kernel processes are running before the 2nd init. Maybe I'll try this experiment again by compiling ext2 into the kernel and changing my cmdline to "root=fe09 rootfstype=ext2 ..."

But on a jffs note, I've used your jffs mount solution many times, something everyone should have in their toolbox.

I'm probably not spending my time wisely, but I want to know more why Nokia hasn't moved Diablo way passed 2.6.21. Fremantle is currently at 2.6.27 something. So, I'm currently going down this very deep patch and diff rabbit hole. Sorry, but I gotsta know what's on my devices. And I'm convinced I'll have a 2.6.22 running on a n8x0 in the next few days. Although not that big of a deal, I'm already running 2.6.21.7.