On Wed, Dec 16, 2015 at 8:34 PM, Read, James C <[email protected]> wrote: > >>https://mameli.docenti.di.unimi.it/solab/browser/trunk?order=name > >>A good read also: >>http://viralpatel.net/taj/tutorial/hello_world_bootloader.php > > Nice > > @We will use a floppy for booting (I know you dont want to crash your > harddrive for this). @ > > Actually, he couldn't be more wrong. Do you know what it would take to get > this code converted to a binary and written to the right place on my hard > disk? > > Daer Samej > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page
Exactly what they use for the floppy (nasm & dd). Just point at the drive you want, rather than /dev/fd0. Traditional bios booting (and all of this starts with the assumption of a typical PC/IBM/Intel 'clone' style boot process) doesn't care any tremendous amount about *what* the drive it's booting from really is, as long as it can talk to it, ask it for the first sector, and start running from there. It's the code on the disk itself that handles things from then on. Actually knowing how to talk to a particular drive (notably the process of translating between addressing modes, from 'simple', CHS, with/without RLL, to the various ranges of LBA based) is where bios systems have had issues with compatibility between old boards and newer drives. Add in the process of finding off-board drive controllers, sata, scsi (in its many forms), USB, etc. and you have all the "I can't find anything to boot from." errors you could ever ask for. Once you get past that point, and have started booting from the drive itself, you have a single 512 byte sector for booting. The last two bytes are a defined value (0x55 and 0xAA) that the bios checks before it starts executing the rest (to reduce the risk of accidentally executing random garbage to ~1/64k). The partition table's also typically in that same sector, and in a traditional DOS MBR, it consists of a list of four 16byte records, meaning you have 446 bytes to start from, which have to either do everything you need the system to do, or they have to understand how to find and execute something more capable, that can continue the process from there. A traditional DOS MBR simply checks the partition table for an 'active' record, then starts executing from the start of that partition. NTFS, at least (I've not deconstructed others recently enough to recall), has a jump instruction to its 'real' bootstrap code, which then sifts through its file table, finds ntldr (or bootmgr), and starts executing that file, which goes and finds more files, uses them for configuration (/boot.ini or /boot/BCD, respectively), and finally starts launching the actual OS (/Windows/system32/winload.exe, for example). Grub does things its own way from the MBR on, loading in its own layers until it has its config/menu file to work from, and then does whatever the user asked for from there. Each layer is a small bit of progress towards then end goal, introducing more and more complexity, so the layer(s) least in the end user's control is/are the most consistent (flashing a bios to support a new, fancy, OS isn't a friendly prospect). The process survived in a fairly consistent form for ~30 years. If you can get the bios on your recent desktop to *see* the old IDE drive you have under 3 inches of dust on the shelf, chances are, it can still boot it (which is very different from presuming that, once handed control, the bootloader and OS on the drive can figure out anything sensible to do with the hardware they find themselves in). Oh, and if you want to use UEFI, everything changes. And... I'll stop rambling for now. :) -- Joshua M. Murphy -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
