maemo.org - Talk - View Single Post

	daperl	2009-01-28 , 01:26
	Posts: 2,427 \| Thanked: 2,986 times \| Joined on Dec 2007	#70

Originally Posted by fanoush

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?

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.

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.

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.

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.

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.

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.

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.

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

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]

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.

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.

__________________
N9: Go white or go home

Quote & Reply |