OSDev.org

My question is that if you have a very small kernel (about 40-50 kbytes),
is there a writable free place into the BIOS area to save it ?

If the BIOS area that loads the boot sector is writable, maybe can changed to jumps to another memory, so executed directly the kernel (with an option of course to make a normal HD/CD/Floppy boot.

given that the bios only occupies 64k or 128k in the real mode area, I doubt you could consider 50k "small", let alone, have it fit in.

Hi,

@Combuster: The flash memory in most machines is about 2 MB (e.g. from 0xFFE00000 to 0xFFFFFFFF). Usually about 64 KB or 128 KB of this is "run-time" code that's copied to RAM just below 1 MB. Some of it may be SMM code that's copied to RAM at 0x000A0000. A lot of it is initialization code (RAM controllers, hyper-transport, PCI buses, etc), code to construct MPS and ACPI tables, the BIOS setup utility, etc that isn't needed after boot. Some of the space is used for storing microcode updates, and for some chipsets some space may be used for the onboard ethernet and/or onboard video ROM. Lastly, to cram everything into the flash memory parts of it may be compressed.

Jef wrote:My question is that if you have a very small kernel (about 40-50 kbytes),
is there a writable free place into the BIOS area to save it ?

For normal BIOSs ("PC BIOS", EFI, etc) there isn't any space left for you, and if there is, there isn't any standard way to modify it and no way to tell where it is.

It is possible to completely replace the firmware with your own code. In this case you need to do lots of chipset specific initialization yourself. I've done this for Bochs, so my OS can boot from ROM on Bochs, but the emulated hardware on Bochs is much easier to initialize than real hardware.

An alternative is to rely on coreboot/LinuxBIOS, which is an open source firmware replacement project that does the low level chipset initialization and starts a "payload"; where the payload can be your OS, or some sort of utility (e.g. memtest) or generic boot code (GRUB2, GNUEFI, OpenFirmware, ADLO/PC BIOS, etc).

The problem here is that the generic boot code loads the OS from somewhere else (e.g. disk, network, etc) and not from flash. This means (for coreboot/LinuxBIOS) to get your OS into ROM you need to make it into a payload.

The problem with building your own payload for coreboot/LinuxBIOS is that there is (currently) no specifications and no backward compatability - you couldn't write your boot code/payload once and let the user install any version of your OS with any version of coreboot/LinuxBIOS without major compatability problems. Potentially, you'd need different payload code for each different version of coreboot/LinuxBIOS and you'd need to constantly monitor the coreboot/LinuxBIOS project to keep your payload/s up-to-date (which creates a "dependancy mess" for end-users).

The last option would be to write your own option ROM. For example, most ethernet cards will take a boot ROM which the PC BIOS will run during boot. It'd be possible to replace the ROM in the ethernet card with your OS, so that your OS is booted from this ROM after the normal PC BIOS does most of the motherboard/chipset initialization.


Cheers,

Brendan

Trashing the BIOS is a job I normally leave for a particularly malignant virus. It never occurred to me that I should try and do it for myself.

Sounds good to me to place the kernel into the rom of ethernet card.
Is the size of the rom standard ?
Is the memory mapped to an address to physical ram?

Hi,

@mathematician: For some/most motherboards you can buy a "BIOS savior". The idea is you have a pair of flash memory chips and select which one is connected, so that you can have a "good" flash chip and an "experimental" flash chip (and switch to the good chip when you've trashed the other).

Jef wrote:Sounds good to me to place the kernel into the rom of ethernet card.
Is the size of the rom standard ?

I'd assume it's a "power of two" (e.g. 16 KB, 32 KB, 64 KB).

Jef wrote:Is the memory mapped to an address to physical ram?

It'd be like any other PCI option ROM - the BIOS would set the BAR in PCI configuration space to map it somewhere, then copy the ROM into RAM (somewhere between 0xC0000 and 0xEFFFF), then disable the BAR in PCI configuration space, then call the copy of the ROM's initialization routine.


Cheers,

Brendan

I know in some of the newer intel cards they have ROMs of 128k.

As far as placing an OS in the BIOS area, I think that could be some very interesting hacking experiments, but I don't really see it being all that useful.

also, 50k, is not all that small when relating to just a basic kernel.

Hi,

01000101 wrote:As far as placing an OS in the BIOS area, I think that could be some very interesting hacking experiments, but I don't really see it being all that useful.

For a normal computer (e.g. desktop, workstation or server) having the OS in ROM wouldn't really help that much.

Some embedded systems need storage space for user data (e.g. digital cameras, PDAs, mobile phones, etc). For these systems the advantage of "OS in ROM" isn't that great because you could put the kernel/OS on the storage device that's needed for user data.

However, some embedded systems don't need storage space for user data (broadband/ADSL modems, routers, firewalls, DVD players, etc). For these systems the configuration data is small and could be stored in CMOS and/or in the ROM. In this case "OS in ROM" is a huge advantage - it means no need for extra storage device, which means lower price per unit, and more sales and/or more profit for the manufacturer.

Also, in all these cases "OS in ROM" can have other advantages, depending on how good the ROM/OS is (e.g. faster boot times, better fault tolerance, etc).

01000101 wrote:also, 50k, is not all that small when relating to just a basic kernel.

Forget about the kernel!

The BIOS flash memory is typically about 2 MB, and (for the reasons above) a sane OS developer would want to get the chipset initialization, kernel, device drivers and application/s in that 2 MB.

If the chipset initialization, kernel and device drivers drivers fit in 1 MB, then that leaves 1 MB for application/s. That seems entirely "doable" to me (especially when you realise you can add some decompression code to that and then store the kernel, device drivers, applications, etc as compressed data)...

Of course once you get that far (e.g. implement it and know it works) then it makes sense to use a similar setup for embedded system that do need storage space for user data (and possibly even normal systems) - not because there's huge advantages in doing this, but because you've already done all the hard work and there's no disadvantages. For e.g. shift applications to the extra storage device, but leave the chipset initialization, kernel and device drivers drivers in ROM...


Cheers,

Brendan

Does that mean that the kernel would be executed immediately (if it replaced the BIOS)?

Wouldn't that make boot-up faster?

-JL

I think its more portable to change the firmware of the LAN card.
Its also leaves the option to select from the BIOS if you will boot from HD/CD or from LAN.

If the LAN card is not onboard, then you can use this on another PC.

If there is about 128k,its a lot of space to put the kernel and the necessary drivers (keyboard, mouse, floppy, ATA, LAN).

If your OS cannot be run from CD as "Live" (without HD installation), just forget it.