QUOTE(ant @ Nov 2 2010, 04:20 AM)
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.
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?