OSDev.org

I have one of those questions which im fairly sure i know the answer too, but have been unable to get confirmed, so now i turn to you guys.

Now i know you will be laughing at me, but thats ok.


If you want anything done, the 512 (510) byte bootsector simply is not enough, so we turn to the bios to load some more from hdd, fdd, whatever.
Now the question simply is this, can you leave the bios out of this i any way?


I dont believe that those 510 bytes avalible is enough for anything which can do the job, but i don't know it for sure and would very much like it confirmed (or not)

Yes, I think it is possible for some devices. For example floopy.
The question is: why do you not want to use the bios?

If you mean, can you load from a device without using BIOS and code it to fit in 510 bytes or less, the answer is YES.
But i would say, HDD would be much smaller, as floppy would be a push, but it could be done.

Of cause you need the BIOS to load the first part of the bootloader.

it was just something i needed to know.
Basicly i dont like the bios very much, as its something i havent programmed myself, but as dex said the bios is still responsible for loading the bootsector, so you cant really get around it.

Well the bios... I know how you feel.

You can go around it by crating your own boot rom. But thats hardcore beyond osdev...

There is a Linux Bios Project(linuxbios.org). But it only works for a hand full of mainboards. And it is hard to say how much use it is to you even with a supported mainboard.

I still want to hear more from that "I'm writing a boot loader in C"-guy.

When i arrived at this forum, a long time ago it seems, someone told me something which i enterpeted as: "C can be directly translated to assembly and vise versa". I never really believed it, but if it were true, i supose it would be possible to write a bootloader in C.

Zacariaz wrote:When i arrived at this forum, a long time ago it seems, someone told me something which i enterpeted as: "C can be directly translated to assembly and vise versa". I never really believed it, but if it were true, i supose it would be possible to write a bootloader in C.

And that is possible, the problem you encounter is that GCC generates either 32-bit or 64-bit code but not 16-bit code, which is as your know required in a boot sector. If you would have a C compiler that can generate 16 bit code then you are done. Thought positioning the 0xAA55 bootmark might pose a problem.

Grub's 2nd stage bootloader is written in C.

Hi,

Zacariaz wrote:If you want anything done, the 512 (510) byte bootsector simply is not enough, so we turn to the bios to load some more from hdd, fdd, whatever.
Now the question simply is this, can you leave the bios out of this i any way?

I dont believe that those 510 bytes avalible is enough for anything which can do the job, but i don't know it for sure and would very much like it confirmed (or not)

For floppy disks, the hardware itself can handle different sized sectors (up to 16 KB per sector). The BIOS is *meant* to load the first sector (not the first 512 bytes) and check the "bootable" magic number at offset 510 in the sector. Therefore it might be possible to format the first cylinder of a boot floppy with 16 KB sectors and end up with a 16 KB boot sector - enough to implement a reasonable floppy driver, etc. However, I would be very surprised if many modern BIOSs actually support this correctly.

You could boot from network, where the "boot sector" (actually much more like a "boot program") is downloaded from network and can be up to about 481 KB.

According to the "El'Torito" specification, a bootable CD can use floppy emulation, hard-disk emulation, or no emulation. For no emulation, sectors are 2048 bytes and the BIOS is meant to be able to load up to 0xFFFF sectors at an address that can (optionally) be specified on the CD. This means you could (for e.g.) arrange for 510 KB of code/data to be loaded from 0x00000800 to 0x0007FFFF before your boot code is even started - enough for a IDE/ATA CD-ROM driver (with plenty of space left for some of the many different SCSI and USB CD-ROM drivers).

You could have a 512 byte boot sector with a serial port driver that transfers an "unlimited" amount of data from another computer via. serial (IIRC there is/was someone on the alt.os.development newsgroup doing this).

You could write a payload for LinuxBIOS and spend your life updating it whenever the (fictional) "LinuxBIOS payload specification" changes (and trying to answer all the "how do I configure/install/use" questions from users). For most motherboards this will let you have about 1 MB or more of code/data (firmware flash chip capacity minus LinuxBIOS overhead).

You could also write your own firmware, but that'd be motherboard specific (the worst kind of "non-portable"). For most motherboards this will let you have about 2 MB of code/data (firmware flash chip capacity), but some of that will need to be used by additional code to configure the chipset (RAM controllers, hyper-transport links, etc).

You could develop an "expansion ROM" for ISA or PCI devices (e.g. a ROM chip for a network card). In this case your code/data would be started by the BIOS either before or after the video ROM (and any other ROMs) are started.

You could use EFI - I don't think there's any limit to the size of the boot program in this case (other than the amount RAM available).

You could also use GRUB.

Of course, you can have some sort of abstraction between your OS's boot code and your OSs boot loader/s, so that any of the above options (and many other options, like just using the BIOS functions to load data from disk) can all be used without the OS itself caring what the boot loader was or what the boot loader did...


Cheers,

Brendan

wow... just... wow...
need... more... input...

enough of that.

I have allways been somewhat facinated by the network booting concept, but i have yet to find any argument(s) to look further in to it.

Here some info on network booting :
http://home.dei.polimi.it/fornacia/prog ... index.html

As for fitting a floppy driver into 510 bytes (without using BIOS ), i would give it a go, if we had something like a small compo, any takers

Hi,

Zacariaz wrote:I have allways been somewhat facinated by the network booting concept, but i have yet to find any argument(s) to look further in to it.

How quickly can you test your OS on other computers, and how often do you test your OS on other computers?

When I first started OS development I only had one computer. To test the OS I copied a boot image to floppy, shutdown windows and rebooted the computer, waited for my OS to boot from floppy, etc. Then I'd remove the floppy, reboot the computer, wait for Windows to start, then find the source code I was working on again and try to remember what I was doing. Average time to test the OS on one computer was around 5 minutes.

Now, I build my OS on a Linux server. I just press the F12 key which starts the build script. The build script automatically updates files in the server's TFTP directory, then I turn the other computers on and they boot the new version of the OS from network. Average time to test the OS on many computers is around one minute - no floppies, no rebooting my development server, etc.

For this alone it's worth doing...

However, my dream is to have a cluster of computers (that are mostly headless and/or diskless to reduce costs) with "wake on LAN" and network booting, that all run a distributed OS.

Imagine a small office for 12 employess/users. In the office you'd have four small silent (diskless) computers, with 3 users per computer (3 keyboards, 3 mouses and 3 video cards in each). Then in a back room you'd have a (headless) server for DHCP, TFTP and storage space; plus 4 small (headless and diskless) computers that are automatically started (via wake on LAN) when more CPU power is needed (and automatically turned off when they aren't needed). I'll be the network administrator - I'll stay at home and log-in via. network, and when a new version of the OS/kernel is released I'll update the server, then upload a new boot image into the server's TFTP directory to update all the other computers (even if all the other computers are turned off at the time).


Cheers,

Brendan

I can certainly see benefits, its not that, however i see no benefits too me.
I have allso wanted to build my own cluster for a very long time, and for hat i would most certainly be usefull, but i do not have the money to involve myself in such a project.

Hi,

Zacariaz wrote:I have allso wanted to build my own cluster for a very long time, and for hat i would most certainly be usefull, but i do not have the money to involve myself in such a project.

You may be surprised...

Most of my computers are old (Pentium II or older). Half of them don't have hard drives, some don't have CD-ROM, most don't have sound cards (and only one has speakers), and only 3 of them have OSs installed (Windows XP, Gentoo and Redhat). None of this actually matters.

I went to one of the local computer shops asking if they had any old crud, and ended up buying about 7 (partially working) old computers for $70(aust). Just by doing some mix & match I ended up with about 5 working computers. I bought some RAM (~$30) and an old monitor (~$50) from eBay and sold one of them (a 166 Mhz Pentium) in a garage sale for $150 (hehe - suckers), so I ended up with about 4 working computers, $20 profit and left-over RAM.

2 of my old computers were donated - people that bought new computers and didn't care what happened to their old machine. I also got several older computers from eBay, ranging from $80 to $500 (although the $500 was for a dual 1 Ghz Pentium III server that I use a lot - it's my development/DHCP/TFTP/Samba/NFS/Apache server now).

I also got a box of old ethernet cards from a computer shop - about $20 for 12 of them, and (AFAIK) only one doesn't work. Then there's a pile of other stuff - two KVM switches, some cheap/crappy keyboards (~$12 each new), some cheap/crappy mice(~$8 each new), a few more old monitors, a network switch (~$60 new), network cables, etc.


Cheers,

Brendan