3 ms·

What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwar

by jaclaz 4y ago

What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures (though most probably this could be worked around and have some space available inside a filesystem created after the extents occupied by kernel (+ embedded initrd). AFAIK/AFAICR, in the good ol'times you could directly dd the zimage or bzimage to floppy: https://www.linux.it/~rubini/docs/boot/boot.html https://www.linux.it/~rubini/docs/boot/boot.html The critique was anyway mainly about comparing size of very different programs with very different features, maybe wrongly, I read that statement as "I am tired of the weight of Porsches and Ferraris, here is my soapbox, and it is much lighter".

peter_d_sherman 4y ago
>What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures. There is no requirement for a given OS -- to use the filesystem of other OS'es... If I am using DOS -- then DOS will not see nor use an ext2 filesystem on the same disk. If I am using Linux -- then typically Linux will NOT see nor use a Novell, BeOS or Amiga filesystem(!) -- at least not without loading a specialized driver... Every filesystem that ever is or was or could ever be -- is implemented as a highly specialized data structure, a pattern of data -- on the storage device. This data structure, this pattern of data -- will have different rules (which will be completely different in two different filesystems) for "what data is supposed to go where" -- in that data structure... Some filesystems -- may use the boot sector to store information about the filesystem in the boot sector. This is the case with DOS/MBR -- but may not be the case with other file systems! (There's nothing preventing a given filesystem from storing information about that filesystem on the last block of a storage device, or the middle block -- or any other block or blocks!) The Starman's Realm, an ancient website (apparently) hosted on Geocities from 1998 - 2009 -- does a much better job of explaining all of this than I can: https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm "The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk." Again, that's for old-style DOS/MBR partition tables. When an OS is loaded -- it could look at the data on a storage device in any way it wishes, any way that it is programmed to do so. It may honor the pattern of data that implements a file system on that storage device, or it may not. All file systems are software/algorithm/code-created abstractions -- on top of a simpler block-based (send/receive n bytes at time, where n typically equals one of the following: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 -- bytes at time) storage device. At the absolute lowest level, that interface looks something like this: ReadBlock(BlockID, PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedTo); WriteBlock(PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedFrom, BlockID); BlockID is just an Integer from 0 (first block, typically boot block) to some high integer -- which is the storage space of the storage device in bytes, divided by the block size. ReadBlock() and WriteBlock() exist as things that the hardware can do -- even before any operating system is loaded -- whether that operating system respects any given filesystem (patterning) on the physical hardware device... All filesystems are subsequently "created" -- by software, data structures, rules, algorithms, and abstraction... on top of this lower level... Also, the first couple of pages of the following are good: https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.p... Last -- any data, any data -- can exist "inside" of a filesystem (the filesystem knows that it is there as a file, the OS recognizes it, etc.) -- but that data can also exist "outside" of that filesystem -- that is, as a series of blocks on that storage device. If inside of a filesystem -- then the OS typically knows how to open, read, write and close the data -- as a file. If outside of the filesystem -- then some other mechanism needs to know how to read that data. In the case of a kernel, for example, the Linux kernel, the Linux kernel can exist inside of a filesystem -- everyone is familiar with that; it's just a file with a filename... But it can also exist outside of a filesystem, as a series of (usually contiguous!) blocks on a storage device. If a kernel (or any other data) needed at boot time exists in this manner -- then it is typically the responsibility of the boot block (or the boot sequence, since the boot block may load additional code) -- to know about that sequence of blocks -- and to load them into memory in a manner similar to what an OS would do with a file -- but since there's no OS running, there is no file system, and thus, the boot sector code -- needs to know the block range for kernel such that it can do a direct load of those blocks into memory...
- jaclaz 4y ago
  This particular tiny-floppy-bootloader project is a fork from the "main" tiny-linux-bootloader: https://github.com/owenson/tiny-linux-bootloader https://github.com/owenson/tiny-linux-bootloader BUT intended for a floppy (which has NOT a MBR, nor any partition), the description of the original, makes sense (as it is aimed to a partitioned device and optional filesystems can exist in the partitioned space after the kernel+initrd), in this fork, the Author maintains parts of the original description that make no sense on a floppy (which again is NOT partitioned and has NOT a MBR), hence it is confusing. BTW in a 1.44 or 1.722 floppy - even if partitioned - there won't be much space left after the kernel + initrd anyway.
  - peter_d_sherman 4y ago
    'MBR' -- is just a fancy name for the first 512 bytes (a.k.a. "The Boot Block") on any device, floppy or hard drive or USB drive -- IF, if and only if specific parts of the data in those 512 bytes -- are of the necessary format to "mark" that data (to BIOS, since BIOS is the ultimate arbiter as what it will accept as a MBR/Boot Block) as being a legitimate MBR/Boot Block. https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm >"The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk. The sector ends with the Word-sized signature ID of AA55h (often called the sector's Magic number" Now, that's a "standard" MBR. That MBR -- defines DOS/BIOS compatible partition tables. A partition table is just an information structure -- this information structure in its simplest form gives (at a minimum!) -- the block on the disk where a given partition starts, and a given partition ends. You can think of any partition on any disk as a "range of blocks". So, maybe you have something where blocks 10 - 1000000 are partition 1, and blocks 1000001 - 2000000 are partition 2. Block 1 is the boot sector AND also an MBR if it contains the necessary data to be one, as explained above. Blocks 2-9 can contain additional bootstrap code. In the MBR scheme, the "range of blocks" that constitutes any given partition -- is defined inside of the MBR (>"The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh...") -- but if we're not dealing with MBR's but merely "plain vanilla" boot blocks -- the definition for partitions no longer needs to be there -- it could be somewhere else on the disk (in the case of a GUID Partition Table (GPT)) -- or it could be defined inside of the assembly/binary boot code of the boot block -- in other words, "load blocks from 2-1000" (or whatever) -- into memory. (blocks 2-1000 are the next "partition" in a manner of speaking -- because they contain the next data to be loaded!) Admittedly all of this is confusing! <g> You are correct that on a floppy there wouldn't be much space left after the kernel + initrd anyway. Also, now that I think about it -- I agree with you that using Syslinux or LILO would probably be easier for most people (much easier!), than using custom code, but the thing is, once we go to Syslinux, LILO or Grub -- now we're in a realm of many more lines of code -- which could be more confusing to people that really want to understand what's going on "under the hood" -- but on the flip side, someone using them would get much more convenience and "ease of use"... so you're right(!) -- but there may also be proverbial "dragons" (of complexity!) with Syslinux/LILO/Grub!

by jaclaz 4y ago

peter_d_sherman 4y ago

>What is not clear (to those that do not understand x86 assembler and/or boot sectors) is that the floppy won't have a filesystem, as if the sectors from 1 onwards are directly occupied by the kernel file, there won't be space for the FAT12 tables or the ext2 structures. There is no requirement for a given OS -- to use the filesystem of other OS'es... If I am using DOS -- then DOS will not see nor use an ext2 filesystem on the same disk. If I am using Linux -- then typically Linux will NOT see nor use a Novell, BeOS or Amiga filesystem(!) -- at least not without loading a specialized driver... Every filesystem that ever is or was or could ever be -- is implemented as a highly specialized data structure, a pattern of data -- on the storage device. This data structure, this pattern of data -- will have different rules (which will be completely different in two different filesystems) for "what data is supposed to go where" -- in that data structure... Some filesystems -- may use the boot sector to store information about the filesystem in the boot sector. This is the case with DOS/MBR -- but may not be the case with other file systems! (There's nothing preventing a given filesystem from storing information about that filesystem on the last block of a storage device, or the middle block -- or any other block or blocks!) The Starman's Realm, an ancient website (apparently) hosted on Geocities from 1998 - 2009 -- does a much better job of explaining all of this than I can: https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm "The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk." Again, that's for old-style DOS/MBR partition tables. When an OS is loaded -- it could look at the data on a storage device in any way it wishes, any way that it is programmed to do so. It may honor the pattern of data that implements a file system on that storage device, or it may not. All file systems are software/algorithm/code-created abstractions -- on top of a simpler block-based (send/receive n bytes at time, where n typically equals one of the following: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 -- bytes at time) storage device. At the absolute lowest level, that interface looks something like this: ReadBlock(BlockID, PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedTo); WriteBlock(PointerToMemoryLocationWhereTheBlockDataShouldBeCopiedFrom, BlockID); BlockID is just an Integer from 0 (first block, typically boot block) to some high integer -- which is the storage space of the storage device in bytes, divided by the block size. ReadBlock() and WriteBlock() exist as things that the hardware can do -- even before any operating system is loaded -- whether that operating system respects any given filesystem (patterning) on the physical hardware device... All filesystems are subsequently "created" -- by software, data structures, rules, algorithms, and abstraction... on top of this lower level... Also, the first couple of pages of the following are good: https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/file-implementation.p... Last -- any data, any data -- can exist "inside" of a filesystem (the filesystem knows that it is there as a file, the OS recognizes it, etc.) -- but that data can also exist "outside" of that filesystem -- that is, as a series of blocks on that storage device. If inside of a filesystem -- then the OS typically knows how to open, read, write and close the data -- as a file. If outside of the filesystem -- then some other mechanism needs to know how to read that data. In the case of a kernel, for example, the Linux kernel, the Linux kernel can exist inside of a filesystem -- everyone is familiar with that; it's just a file with a filename... But it can also exist outside of a filesystem, as a series of (usually contiguous!) blocks on a storage device. If a kernel (or any other data) needed at boot time exists in this manner -- then it is typically the responsibility of the boot block (or the boot sequence, since the boot block may load additional code) -- to know about that sequence of blocks -- and to load them into memory in a manner similar to what an OS would do with a file -- but since there's no OS running, there is no file system, and thus, the boot sector code -- needs to know the block range for kernel such that it can do a direct load of those blocks into memory...

jaclaz 4y ago
This particular tiny-floppy-bootloader project is a fork from the "main" tiny-linux-bootloader: https://github.com/owenson/tiny-linux-bootloader https://github.com/owenson/tiny-linux-bootloader BUT intended for a floppy (which has NOT a MBR, nor any partition), the description of the original, makes sense (as it is aimed to a partitioned device and optional filesystems can exist in the partitioned space after the kernel+initrd), in this fork, the Author maintains parts of the original description that make no sense on a floppy (which again is NOT partitioned and has NOT a MBR), hence it is confusing. BTW in a 1.44 or 1.722 floppy - even if partitioned - there won't be much space left after the kernel + initrd anyway.
- peter_d_sherman 4y ago
  'MBR' -- is just a fancy name for the first 512 bytes (a.k.a. "The Boot Block") on any device, floppy or hard drive or USB drive -- IF, if and only if specific parts of the data in those 512 bytes -- are of the necessary format to "mark" that data (to BIOS, since BIOS is the ultimate arbiter as what it will accept as a MBR/Boot Block) as being a legitimate MBR/Boot Block. https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm >"The first 139 bytes (00h through 8Ah) of the 512-byte sector are executable code, and the next 80 bytes (8Bh through DAh) contain error messages. The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh); data in the Table area will depend upon the size, structure and file systems on each hard disk. The sector ends with the Word-sized signature ID of AA55h (often called the sector's Magic number" Now, that's a "standard" MBR. That MBR -- defines DOS/BIOS compatible partition tables. A partition table is just an information structure -- this information structure in its simplest form gives (at a minimum!) -- the block on the disk where a given partition starts, and a given partition ends. You can think of any partition on any disk as a "range of blocks". So, maybe you have something where blocks 10 - 1000000 are partition 1, and blocks 1000001 - 2000000 are partition 2. Block 1 is the boot sector AND also an MBR if it contains the necessary data to be one, as explained above. Blocks 2-9 can contain additional bootstrap code. In the MBR scheme, the "range of blocks" that constitutes any given partition -- is defined inside of the MBR (>"The last 66 bytes of the sector contain the 64-byte Partition Table (1BEh through 1FDh...") -- but if we're not dealing with MBR's but merely "plain vanilla" boot blocks -- the definition for partitions no longer needs to be there -- it could be somewhere else on the disk (in the case of a GUID Partition Table (GPT)) -- or it could be defined inside of the assembly/binary boot code of the boot block -- in other words, "load blocks from 2-1000" (or whatever) -- into memory. (blocks 2-1000 are the next "partition" in a manner of speaking -- because they contain the next data to be loaded!) Admittedly all of this is confusing! <g> You are correct that on a floppy there wouldn't be much space left after the kernel + initrd anyway. Also, now that I think about it -- I agree with you that using Syslinux or LILO would probably be easier for most people (much easier!), than using custom code, but the thing is, once we go to Syslinux, LILO or Grub -- now we're in a realm of many more lines of code -- which could be more confusing to people that really want to understand what's going on "under the hood" -- but on the flip side, someone using them would get much more convenience and "ease of use"... so you're right(!) -- but there may also be proverbial "dragons" (of complexity!) with Syslinux/LILO/Grub!