Bootloader For 6000

[systemparadox]

Hi.
I'm sure this has probably been asked before, but here goes (I did try searching first)...

The big picture- I am a nutcase and want to mess around with compiling my own stuff for the Z on the Z, and dual booting.

What I really need in order to get anywhere is a bootloader.
I have no idea how the Z boot process works in terms of the BIOS, but i'm assuming it's somewhat similar to that of your average PC.
i.e. The BIOS does whatever it needs to and then runs whatever is in the special location (the MBR) of the primary master hdd (which in this case would actually be the internal rom).
Please correct me and provide additional info on the Z's boot process if you can.

So your PC loads lilo (or grub if you must) from the MBR on /dev/hda, and enables you to ignore /dev/hda completely and boot from /dev/hdb3 or similarly obscure partition on a totally different non-removable device.

I want to make my Z boot whatever loader from the internal rom, which will allow me choose between booting from the internal rom (the sharp rom or whatever else i have loaded), and ignoring it completely and booting from /dev/hda1 or /dev/mmcda1 or something.

Potential problems include:
1. Making the bootloader think that the CF card is a non-removable device (e.g. lilo won't boot from CDROM).
2. Drivers are probably required for the SD/CF cards to allow booting from them.
I've heard something about a project to use the linux kernel as a bootloader- which will allow it to use standard kernel driver modules. I can't find any info about this on google though.
3. Does the bios even boot to a space that I can alter?

I have looked at some of the posts about booting OZ from an SD card, but they seem to boot the kernel on the rom and then use that to boot the sd- so they must both use the same kernel (I'm trying to do this so I can mess with booting self-compiled kernels without killing the sharp rom). Seems strange to me, as I'm sure that OZ uses a different kernel.


Thanks
Simon

[Mickeyl]

The interesting approach is to port a better arm boot loader to the Zaurus family, i.e. uboot, blob, or even LAB. That way you can

*) set CMDLINE on the fly
**) have the kernel as zImage in rootfs
***) boot multiple kernels from rootfs
****) boot from multiple rootfs'es

Unfortunately this approach is not doable as it requires too much knowledge about unpublished things.

Two more practical approaches are:

*) use kexec to boot another linux kernel on-the-fly, i.e. while one kernel is running

**) forget about boot loaders booting different kernels and concentrate on booting different root file systems. You can do that in early userspace, i.e. init S. This means to launch some device drivers to bring peripheral devices up, scan for possible rootfs'es, and give a list of what you found. This approach is the most boring and pretty uncool - compared to the other approaches - but it's the only one that is likely to be done. It's - btw. - what we will do in the Ångström distribution:

[img]http://www.vanille.de/temp/angstrom-bootmanager.png\" border=\"0\" class=\"linked-image\" /]