Zaurus Kexecboot-enabled Kernels

[ant]

Latest 2.6.26 and beta 2.6.33-rc6 images here:  http://projects.linuxtogo.org/projects/zaurus/

Ant

[klaxon]

Latest 2.6.26 and beta 2.6.33-rc6 images here:  http://projects.linuxtogo.org/projects/zaurus/

Ant

I still can't boot Cacko from NAND with my C860. I've used the 2.6.26 image.

[ant]

>I still can't boot Cacko from NAND with my C860. I've used the 2.6.26 image.

I don't think this can be done with unpatched cacko kernel.
There is unfortunately a fundamental issue: the 2.4 kernels look for the bootparams in an old deprecated way/location.
The old sharp/cacko kernel has own hacks for reading the params passed by the bootloader and just ignores the cmdline passed by kexec...so mtdparts (for nand partitioning) are wrong.

Pity, because kexecboot-kernel can now read the partitioning from nand so you can repartition the device as you like.
All 2.6.2x/2.6.3x kernels will get the mtdparts from kexecboot appended commandline.

FYI, this was my test of cacko lite 1.23 on SL-C860.

1) install cacko and repartition e.g. mtd2 to 19mb as suggested
2) flash kexecboot kernel
3) create a small (few mb) partition on SD/CF and copy Cacko kernel on it as /boot/zImage
4) create on that partition on SD/CF a /boot/boot.cfg like this:

LABEL=Cacko
KERNEL=/boot/zImage
APPEND=console=ttyS0,115200n8 console=tty1 noinitrd
root=/dev/mtdblock2 rootfstype=jffs2 debug

Result: Cacko flashed on nand recognizes the params (passed from bootloader), booted from SD wrongly defaults to 30mb...(on SL-C860)

Regards
Ant

[klaxon]

SL-C1000 and newer models have also a 2.4 kernel.

Why multibooting with Cacko is possible with them ?

[xamindar]

SL-C1000 and newer models have also a 2.4 kernel.

Why multibooting with Cacko is possible with them ?

Because the kexec 2.6 kernel boots up the 2.4 kernel.

[klaxon]

SL-C1000 and newer models have also a 2.4 kernel.

Why multibooting with Cacko is possible with them ?

Because the kexec 2.6 kernel boots up the 2.4 kernel.

But it can't boot C7xx. It is because of the 2.6.18 vs 2.6.20 version of the kernel ?

[ant]

Hi,

new roundup of linux-kexecboot 2.6.2x kernels with new GUI.

http://projects.linuxtogo.org/projects/zaurus/

Soon 2.6.36 will follow (still with old ATA deprecated driver, giving /dev/hd* to the microdrive and CF cards).

Regards

Ant

P.S. rootfs images can be downloaded at http://www.angstrom-distribution.org/narcissus

[xamindar]

Great to see this is still being worked on. Did they do anything else besides a new GUI? Like fix the bugs that make it take 5 minutes to scan the internal flash? They should just disable the internal flash scan as it doesn't usually hold a kernel anyway.

By the way, which image do I use for a C3100? There is none for that model. I forget which one I used last time. I'm assuming spitz but not sure.

[xamindar]

Ok, I hope the person who made this kernel is reading this thread. Regarding the new gui - EWW! It displays in a huge splash "Angstrom" while hiding the kernel messages. I thought this was a kexec boot kernel, not an angstrom one. I don't even have Angstrom on my zaurus and as far as I can tell Angstrom has never been stable on the zaurus anyway.

Second issue, it still takes F.O.R.E.V.E.R to scan the internal flash. Please disable it or fix it.

Third issue, this new gui, once it has finally scanned and found the bootable kernels, does not show the name (label) of the selection like the old one did. Before I had a list that showed "Debian Eabi" and "Sharp JP rom". Now it just tells me on which partition it found the kernel. If I didn't already know which partition booted which OS from the previous kernel I would be guessing here. Not good for any new users of this kernel.

I'm going back to the previous, better kernel. Thanks for the continued work though, but I would like it to improve things instead of degrading.

[ant]

Hello,

I've uploaded the 2.6.36 versions.
Kexecboot has not changed, is the latest version with new gui.
Please test and report (here or on Zaurus PDA developers list <zaurus-devel@lists.linuxtogo.org>)

Regards

Ant

P.S.
About slow nand scan, it takes almost 30 seconds for scanning *two* jffs2 in nand, so it is not that slow...
BUT, if you still have old 2.4 jffs2 images, this could take much longer.
Please be sure to properly erase the nand (flash_erase_all -j /dev/mtd[2:3]) and optionally flash *recent* jffs2 images.

P.P.S.
Boot options (and label) are read from /boot/boot.cfg. Create it if your distro is lacking it
(see ex http://cgit.openembedded.org/cgit.cgi/open...oot-cfg_0.1.bb)

[ant]

Ok, I hope the person who made this kernel is reading this thread. Regarding the new gui - EWW! It displays in a huge splash "Angstrom" while hiding the kernel messages. I thought this was a kexec boot kernel, not an angstrom one. I don't even have Angstrom on my zaurus and as far as I can tell Angstrom has never been stable on the zaurus anyway.

Second issue, it still takes F.O.R.E.V.E.R to scan the internal flash. Please disable it or fix it.

Third issue, this new gui, once it has finally scanned and found the bootable kernels, does not show the name (label) of the selection like the old one did. Before I had a list that showed "Debian Eabi" and "Sharp JP rom". Now it just tells me on which partition it found the kernel. If I didn't already know which partition booted which OS from the previous kernel I would be guessing here. Not good for any new users of this kernel.

I'm going back to the previous, better kernel. Thanks for the continued work though, but I would like it to improve things instead of degrading.

Purposedly, we try to hide everything to the user.
There is a kernel bootlogo and printk loglevel is set to 3.
Which information do you need from kexecboot micro-kernel? ATM it has wrong idea about resized mtdparts, those are re-read by the kexecboot binary in the initramfs.
FWIW we are working to add some logging but just the debug output you would see on serial once compiled with --enable-debug, no kernel output.

About label, check your /boot/boot.cfg.

Finally, about the logo, it all depends on the distro you're compiling but is purely cosmetic thing. Most distros are using standard OpenEmbedded logo (the OE one) but Angstrom has own.
Ideally we would use the original white/red SHARP logo but it seems there could be some copyright issue.

Regards

Ant

[xamindar]

Purposedly, we try to hide everything to the user.
There is a kernel bootlogo and printk loglevel is set to 3.
Which information do you need from kexecboot micro-kernel?

Maybe I'm wrong but I figured most people who would know enough to be able to use this kernel would want to see the kernel output as well. I like to see what it is scanning so I know what it is doing. Occasionally I have had an SD card inserted that caused the kernel to "hang" until it was removed and seeing the kernel messages has helped in those situations. Besides, it's a lot better than having a huge Angstrom image displayed that has nothing to do with the zaurus. It might as well be a big MacDonalds logo.

About label, check your /boot/boot.cfg.

OK, so this must have changed. The old kexec kernel I used read the /boot/image.nfo file and got the label from there. Good to know the change. Thanks. Is it the same? A simple line stating the label?

Finally, about the logo, it all depends on the distro you're compiling but is purely cosmetic thing. Most distros are using standard OpenEmbedded logo (the OE one) but Angstrom has own.

OK, OE logo is fine, where can I get the kernel with that logo instead? I didn't see any alternative kernels listed.

P.S.
About slow nand scan, it takes almost 30 seconds for scanning *two* jffs2 in nand, so it is not that slow...
BUT, if you still have old 2.4 jffs2 images, this could take much longer.
Please be sure to properly erase the nand (flash_erase_all -j /dev/mtd[2:3]) and optionally flash *recent* jffs2 images.

From the moment I turn on the Zaurus, it is 2 minutes and 30 seconds before the menu shows up. To me, that is way too long. And to say I need to erase my NAND and flash new images is unacceptable. With the amount of customization I had to do to get everything working properly there is no way I would be able to get it working the same again without hours of work. Besides, what are these *recent* jffs2 images you talk about? As far as I know, Sharp stopped updating their ROMs. If the kexec kernel doesn't "like" the NAND then why is it scanning it? There are no kernel images on it anyway.

Thanks for the info. I'll give it a try again. One thing you didn't answer, why does it have to scan the NAND? Is it possible to get a kernel that doesn't even do that?

[xamindar]

Also, what size is the icon.xpm supposed to be?

[xamindar]

GAH! Forget it. I copied the image.nfo file over to a boot.cfg file and now it doesn't even show my sharp rom listed anymore. Then I tried booting into the debian eabi install and the kernel hung at "failed to load initial console" or whatever.

You guys have absolutely no documentation so how can you expect anyone else to use this kernel without having to scour through your source code to find out what and how it needs the boot.cfg file set up? I'll take another look at this kernel if someone ever decides to document their work so others can use it. Until then, I'll stick with the Omegamoon kernel which works perfectly (despite scanning the nand very slowly as well) and even has a better looking menu (with this angstrom one you can't tell which is the selection, the darker one or the lighter one).

[koan]

Hi Xamindar,

I think you should take a break and chill out for a bit. You can't expect things to work seamlessly when they are not really aimed at Joe User. As soon as you reflash you are on the road to being a hacker...

Why don't you get on the mailing list and relate your experiences there ? I am sure they would appreciate feedback directly from a tester. (I don't know who user ant is IRL). http://lists.linuxtogo.org/pipermail/zaurus-devel/

Documentation is always the last thing to get written. If you read the mailing list archives it looks like they just want feedback to see what works and what doesn't at this stage. Plenty of things seems to be not working.

I think that what is on your flash is up to you, you don't need Sharp to supply new data. I expect though that your Sharp ROM is configured to be on flash so removing it is not an option. I am guessing that for some reason scanning jffs is slow; my understanding is that kexec is searching for bootable kernels. It would be nice if there was an option in one of the config files to disable scanning of flash.