quick reboot concept

[proxy]

I am toying with the idea of making an extra fast reboot, similar to how kexec works, but not quite the same.

Basically, my theory is that if i copy the first sector of the boot device to 0x7c000, switch to real mode, and ljmp $0x7000,$0xc000 (is that correct, i always messed up segment math) it should restart the boot process.

Clearly there is a little prep work that would be needed first, like syncing disks and such, maybe depending on the circumstances, puting devices back into a boot up like state.

any thoughts? I feel like it shoudl work, but my prelim code isn't quite right yet.

proxy

[Brendan]

Hi,

Basically, my theory is that if i copy the first sector of the boot device to 0x7c000, switch to real mode, and ljmp $0x7000,$0xc000 (is that correct, i always messed up segment math) it should restart the boot process.

Clearly there is a little prep work that would be needed first, like syncing disks and such, maybe depending on the circumstances, puting devices back into a boot up like state.

I've done it before (a long long time ago).

First, when you jump to the boot sector you need to jump to 0x0000:0x7C00 and you should put the BIOS's device number into DL (so the booted code knows which device it's booting from). In some cases this can allow you to boot devices that the BIOS doesn't support - for e.g. I had code that would boot from A:, B:, C: or D: and an OS that would support it (but that was before booting from CD was an option).

Second, you have to make sure that all hardware is in the right state, and matches the BIOS's state (EBDA, BDA) - especially if your booting any OS rather than just your own. This includes making sure the BIOS's time is correct (set ticks since midnight and clear the midnight counter).

To make this easier it may be better to write a real mode "pre-boot" handler which restores the video mode and loads the boot sector (to ensure that the VGA and the values it uses in the BDA and the floppy motor and the "turn the floppy motor off" timer are correct). This would make it easier to support booting from CD - it would be almost impossible otherwise because you'd need to setup the BIOS's device emulation (e.g. configuring everything so that A: is the CD, and B: is the first floppy, or so that C: is the CD and D: is the first hard drive, depending on the type of boot CD).

In the initial stages of developing your OS this should all be relatively easy to implement. As your OS grows it gets harder - the more hardware your OS uses the more work it is to restore everything to the "boot state".


Cheers,

Brendan

[dh]

lol, not a new idea. I've got a couple design concepts about "soft-booting", all of which are derrived from a Palm .

Rather than use the first sector, try to jump back into Stage2. This (imho) would be nicer to code, and you can simply make another entry point or something SPECIFICALLY for soft-booting. This removes requirements to switch modes, reset registers, etc.

Cheers, DH.

[proxy]

ahh, but what if i want to oft reboot to another OS? i figure starting with the MBR would be best then no?

proxy

[Brendan]

Hi,

ahh, but what if i want to oft reboot to another OS? i figure starting with the MBR would be best then no?

Set up a meeting with yourself, your marketting department, your accountancy department and your developers.

Your marketting department will tell you that it's important for your OS to reboot as fast as possible, and they may give hints implying that making other OS's look slow isn't such a bad thing.

Your accountancy department could work out how much it might cost to reboot your OS fast and how much extra it'd cost to make other OSs reboot fast.

Your developers will probably point out something like Dragon_Hillord's suggestion - have a soft-reboot entry point that is later in the boot so that a fast reboot of your OS can skip the BIOS, the MBR and other things (making the fast reboot feature even faster).

Of course your users will want the "fast MBR reboot" for other OSs and the "extra fast soft-reboot entry point" for your OS. It's likely that marketting and accountancy will object to this. Your developers may or may not like the idea, depending on whether there's a deadline for the project and if they get paid overtime rates...


Cheers,

Brendan

[dh]

thats a tough one at first glance, but just look at grub . See my point? The MBR is just to get YOU off the ground and into memory. If I were a bootloader developer, I would think this is VERY important (eg. chainloading).

Cheers, DH.

[JoeKayzA]

Rather than use the first sector, try to jump back into Stage2. This (imho) would be nicer to code, and you can simply make another entry point or something SPECIFICALLY for soft-booting. This removes requirements to switch modes, reset registers, etc.

Sorry for pulling this thread up again, but this brought me to an idea:

Instead of restoring all the state after POST and boot another boot sector, why not implement a multiboot-compliant soft-reboot mechanism? Since multiboot enters the kernel in protected mode already, several tasks that you would normally accomplish through the BIOS (loading files, setting video mode, get the memory map) are already done by the bootloader, and a multiboot kernel is unlikely to rely on the BIOS too much.

Something makes me believe that this could work better than a 'raw' chainload in real mode.

cheers Joe