content/node/4325.md

@@ -35,11 +35,20 @@ The main purpose of first stage boot loader is to load <strong>haiku_loader</str
 
 Pretty attractive case of loading stage 2 bootloader is to provide BFS access (searching by BFS nodes for <strong>haiku_loader</strong>) directly from ROM (stage 0 bootloader). This is already done for ext2 filesystems in U-Boot or ISO9660 in OpenFirmware. It is possible for hardware manufacturers provide modified version of ROM.
 
-<div class="alert alert-info"><div style="margin-left:40px;position:absolute;"><strong>Notes on x86 implementation</strong>
+<div class="alert alert-info">
+<strong>Notes on x86 implementation</strong>
 
-BFS Boot Code detects drive id, check if we have disk extension provided by the BIOS, load the rest of the stage 1 bootloader, validate the BFS superblock, search the stage 2 bootloader on disk, load the stage 2 bootloader into memory and run the stage 2 bootloader.
+BFS Boot Code detects drive id, check if we have disk extension provided by the BIOS, load the rest
+of the stage 1 bootloader, validate the BFS superblock, search the stage 2 bootloader on disk, load
+the stage 2 bootloader into memory and run the stage 2 bootloader.
 
-Stage 1 boot code can be found in <strong>/src/system/boot/platform/bios_ia32</strong>. The offset of the partition in 512 byte blocks must be written at position PARTITION_OFFSET_OFFSET or otherwise the code can't find the partition. The partition must be a BFS formatted. The stage 2 boot loader &mdash; <strong>/system/haiku_loader</strong> loaded into memory at 0x1000:0x0000 and entered at 0x:1000:0x0200 with EAX (partition offset in 512 byte blocks) and DL (BIOS ID of the boot drive).</div></div>
+Stage 1 boot code can be found in <strong>/src/system/boot/platform/bios_ia32</strong>. The offset
+of the partition in 512 byte blocks must be written at position PARTITION_OFFSET_OFFSET or otherwise
+the code can't find the partition. The partition must be a BFS formatted.
+The stage 2 boot loader &mdash; <strong>/system/haiku_loader</strong> loaded into memory at
+0x1000:0x0000 and entered at 0x:1000:0x0200 with EAX (partition offset in 512 byte blocks) and DL
+(BIOS ID of the boot drive).
+</div>
 
 <strong>makebootable</strong> binary utility makes the specified BFS partitions/devices bootable by writing BFS boot code into the first two sectors. It doesn't mark the partitions active. This utility can be compiled to run under BSD, Linux, Mac OS X, BeOS and Haiku hosts. In the case of a missing makebootable we never get to that stage 2 bootloader. You can read more about makebootable in <a href="/blog/mmlr/2009-02-08/makebootable_what_and_why_and_how_do_it_manually">Haiku Article about makebootable</a>.
 
@@ -77,4 +86,4 @@ This hardware abstraction layer functions are resides in Haiku repository in <st
 
 Platform independent Haiku Loader code lives in <strong>/src/system/boot/platform/generic</strong> and <strong>/src/system/boot/loader</strong> directories. The platform dependent bootstrap code fires up <strong>main</strong> function in platform independent part of loader directly.<br><br>
 
-The main function of second stage loaders inits heap, video. Then its retrieve boot filesystem to boot up, if no found it shows user menu. Then it loads modules and kernel with <strong>elf_load_image</strong> and starts kernel by calling <strong>platform_start_kernel</strong> from HAL API.<br><br>
+The main function of second stage loaders inits heap, video. Then its retrieve boot filesystem to boot up, if no found it shows user menu. Then it loads modules and kernel with <strong>elf_load_image</strong> and starts kernel by calling <strong>platform_start_kernel</strong> from HAL API.<br><br>