Chain loading and large non-IDE discs

[rdos]

I just looked through my (old) boot-loader, and it seems like the harddisc loader uses direct-access to IDE hardware. IOW, it would fail on USB drives and SATA drives configured for non-IDE. I see in the wiki that there has been added new functions for LBA-addressing, and even 48-bit LBAs to BIOS. However, it seems there are a few issues that are not documented in the wiki:

1. What is the use of 48-bit LBA access when partition tables only contain 32-bit entries?
2. How does a chain-loaded boot-sector know it's disc location? The disc drive should be passed in DL, but what about the start sector of the partition?

[egos]

1. Look at GPT.
2. EDD 4 describes interface between hybrid MBR boot loader and partition boot loader. But I think it's not so good (I use different validation method; look here). Additionally I use DH register to transfer boot partition number to stage1 in both schemes:
1) traditional MBR (PT) partitioning scheme: 0 - default (active) partition or whole device, 1-4 - primary partitions, 5-255 - additional partitions;
2) GPT partitioning scheme: 0 - default partition (boot flag is set) or whole device, 1-128 - partition in GPT, 129-255 - reserved.

Note: there is a suspicion that NTFS' Hidden Sectors field may be expanded to 64 bits.

[JAAman]

actually, you missed something:

its possible to have a 2TB partition starting at 2TB offset -- which means the MBR can access up to 4TB of disk space

the maximum size of a disk without using 48bit LBA is only 128GB


therefore, since 4TB > 128GB...


since drives much larger than 128GB are commonplace nowadays, it is definitely a good idea to support 48bit LBA on all drives



as for chain-loaded boot sectors, according to the original specifications, you should reload the MBR, and search it for the 'active' flag -- as the specification only permits booting from the active partition -- however, most 3rd-party boot managers don't properly alter the 'active' flag for the booting partition, therefore, it has become common practice to simply assume that DS:SI points to the currently booted partition table entry -- since presumably the last thing the MBR code did was use LODS to locate the correct partition within the partition table to boot (just like the specifications do not say that DL should contain the device number, but since the last thing the BIOS did was load the boot sector from the drive, and disk accesses require DL to contain the device number, it usually does, therefore people have taken to assume such to always be the case, which should be true on modern systems, and is likely true on most older systems as well)

[egos]

Modern MBR boot loaders save and restore DL value.

Original MBR boot loader from Windows Vista/Seven:

Code: Select all

        pop     dx ; BOOTMGR stage1 uses DL value!
        xor     dh, dh
        jmp     0:7C00h

My MBR boot loaders:

Code: Select all

  pop dx ; My "primary loaders" use DL value too!
  ...
  pop si
  jmp sp ; 0:7C00h

Quote from EDD 4:

Hybrid MBR boot code handover procedure

Register/Description/Differences from legacy MBR hand over
DL/Disk number/No change
ES:DI/Pointer to $PnP structure/No change - It's nonsence! MBR boot loader usually destroys this pointer.
EAX/54504721h (i.e., "!GPT"). Indicates that the hybrid MBR hand over structure is being passed with DS:SI rather than the legacy MBR Partition Record/New
DS:SI/Pointer to the hybrid MBR hand over structure/New

[JAAman]

2 very important words in your post:

modern == means this is true on modern, current systems, but not true of older systems
MBR == this means the MBR saves this value, and doesn't mean the BIOS passed it correctly in the first place! (which has never been guaranteed, it was pure accident that DL ever contained the boot device on early computers, as the original specification expected the boot sector to have prior knowledge of what device it was, and only 0 and 0x80 were valid boot devices)

actually, the MBR has no need to save/restore DL, since it should be set on the read which loads the boot sector... and thus will be correct anyway (and on any system with a buggy bios that trashes DL, DL is guaranteed to be wrong when its passed to the MBR anyway, since the BIOS never specifically sets DL to be the boot device -- at least it didn't on the older systems that would likely have such bugs)

Original MBR boot loader from Windows Vista/Seven:

... that is a strange statement right there... there should never be any connection of any kind between an MBR and an OS (as there isn't with any of the MS MBRs/OSes

[egos]

modern == means this is true on modern, current systems, but not true of older systems

You can install MBR boot loader (stage0) for your stage1. As for me, a chain loading is most effective and sustainable when my stage0 and stage1 work together.

MBR == this means the MBR saves this value, and doesn't mean the BIOS passed it correctly in the first place! (which has never been guaranteed, it was pure accident that DL ever contained the boot device on early computers, as the original specification expected the boot sector to have prior knowledge of what device it was, and only 0 and 0x80 were valid boot devices)

I think it is not problem now because it is 15 years since BIOS Boot Spec. and "El Torito" Spec. were introduced. In special cases we can use patched boot loaders.

... that is a strange statement right there... there should never be any connection of any kind between an MBR and an OS (as there isn't with any of the MS MBRs/OSes

In general that's right but we know that Windows rewrites MBR boot loader during installation. My setup program does this too when it's used. Only if I use step-by-step installation by hand I can pass some step such as stage0 installation, or stage1 installation.

[JAAman]

i typed a lengthy reply... but i deleted it because i felt guilty, since i think i have kind of pulled this thread off topic...
my only intention was to answer the OP questions:

is 48bit addressing is necessary:
it is, if you want to support disks larger than 128GB, which is the physical size limit for 28bit addressing

how to find the boot partition:
simple answer: DS:SI contains a pointer to the booted partition entry in the memory-resident copy of the MBR

[egos]

The question essence consists in logical addressing limitations and how can get position of the boot partition in stage1. DS:SI pair is extremely unreliable source for this info. I use it only with additional guaranties. My MBR boot loaders provide them giving extended boot signature to stage1. The traditional way for primary partitions with MS file systems is to use Hidden Sectors field but this field is 32-bit and is not correct for additional partitions within extended partition of type 5. I correct (only in RAM) Hidden Sectors field of BS and LBA field of PT record when run stage1 of such additional partitions. I mentioned above that EDD 4 introduces an extended structure pointed by DS:SI. I accept it but don't accept its validation method. EAX="!GPT" (really I use AX="!G" in stage1) now means for me that we have extended structure only if DS:SI pointer is correct.

[rdos]

This really sounds too complex.

What would be the easiest solution if I wanted a PC with a SATA-disc (non-IDE mode) to boot a multiboot-compliant kernel from a FAT32 partition located in the third partition slot? Partition 1 and 2 are NTFS. I also want to chain-load Windows 7 from partition 2. Additionally, the boot-loader must be placed in the MBR of the disc, as booting from a CD/DVD is too time-consuming because it is not possible to permanently set default-boot from CD/DVD.

It seems like legacy-GRUB cannot handle this as it is not possible to place GRUB stages on the first partition (it is not even visible in Windows 7).

[Solar]

...we know that Windows rewrites MBR boot loader during installation. My setup program does this too when it's used.

Any last wishes? Blindfold? Cigarette?

Get the heck off my MBR! That's the single most annoying thing with Windows Setup. Whatever boot manager I use is my decision. An OS setup has no business doing anything outside its assigned installation partition(s). You may subserviently ask me if I already have an MBR boot manager installed, and if you could do me the favor of installing one, but generally speaking an OS is a guest of mine given a specific partition to reside in, and my MBR / boot manager is none of its business. I will chain-load the partition bootloader. How I do that is my business.

What would be the easiest solution...

GRUB (legacy).

It seems like legacy-GRUB cannot handle this as it is not possible to place GRUB stages on the first partition (it is not even visible in Windows 7).

Why the requirement to place GRUB stages on the first partition? GRUB can be set up with its stage2 file on any partition (with supported file system). That might be part of any OS partitions in the system, or a partition of its own. Have I missed something?

[rdos]

Why the requirement to place GRUB stages on the first partition? GRUB can be set up with its stage2 file on any partition (with supported file system). That might be part of any OS partitions in the system, or a partition of its own. Have I missed something?

I think I found the solution after I posted this. It seems like I'm using an old GRUB (legacy) version and this is why it cannot read NTFS, nor can place the boot stages on any partition.

So, the answer probably is GRUB legacy. I also searched for GRUB2 solutions, but I'm unable to find anything that does not require a Linux / UNIX installation (there are no prebuilt floppy-images available).

[Solar]

I think I found the solution after I posted this. It seems like I'm using an old GRUB (legacy) version and this is why it cannot read NTFS, nor can place the boot stages on any partition.

I assume you meant "on any NTFS partition".

That is correct. GRUB uses the stage1_5 files to add file system support to the stage1. (I.e., stage1 goes into the MBR, the appropriate stage1_5 immediately adjacent to the MBR, the stage2 file can reside in any partition for which a corresponding stage1_5 file exists.)

My local GRUB installation (0.97) lists e2fs, fat, ffs, iso9660, jfs, minix, reiserfs, ufs2, vstafs and xfs as available stage1_5 files.

You can circumvent the stage1_5 part by hardcoding the location of stage2, but then you'll have to re-encode that whenever you update stage2. And you still couldn't make it load from an NTFS partition, since stage2 doesn't "speak" NTFS either.

(Did you actually try the GRUB (legacy) manual?)

[rdos]

I assume you meant "on any NTFS partition".

That is correct. GRUB uses the stage1_5 files to add file system support to the stage1. (I.e., stage1 goes into the MBR, the appropriate stage1_5 immediately adjacent to the MBR, the stage2 file can reside in any partition for which a corresponding stage1_5 file exists.)

My local GRUB installation (0.97) lists e2fs, fat, ffs, iso9660, jfs, minix, reiserfs, ufs2, vstafs and xfs as available stage1_5 files.

You can circumvent the stage1_5 part by hardcoding the location of stage2, but then you'll have to re-encode that whenever you update stage2. And you still couldn't make it load from an NTFS partition, since stage2 doesn't "speak" NTFS either.

Apparently, GRUB4DOS does support NTFS, but I don't want to install a DOS-system either.

(Did you actually try the GRUB (legacy) manual?)

This manual is generally uninformatory. It also assumes that it is Linux (or a UNIX-derivate) that is to be dual-booted with something, and that this OS is already installed. I have absolutely no intention of installing Linux on my laptop.

I have Windows 7 and Paragons parition manager installed. Paragon's own boot-manager can be successfully installed, and seems to use the first 41 sectors on the disc. There are 0x800 reserved/unused sectors before the first NTFS (sys) partition.

I have a FAT32 partition on the disc (for RDOS use), and it would be a possible solution to place stage 2 there. What I would need is a floppy image of GRUB 0.97, which the GRUB manual does not provide links to. Why can't they provide tools for Windows to build and install GRUB?

[Solar]

This manual is generally uninformatory. It also assumes that it is Linux (or a UNIX-derivate) that is to be dual-booted with something, and that this OS is already installed. I have absolutely no intention of installing Linux on my laptop.

No, it assumes you have a Linux platform from which to install GRUB. I have successfully installed GRUB on Windows-only systems using Knoppix Live-CDs.

Also, Cygwin supports GRUB 2, if you prefer that road.

I have a FAT32 partition on the disc (for RDOS use), and it would be a possible solution to place stage 2 there. What I would need is a floppy image of GRUB 0.97, which the GRUB manual does not provide links to. Why can't they provide tools for Windows to build and install GRUB?

Why should they? Windows-only systems are hardly the targetted audience. And why should a GNU project do Windows users a courtesy?

You could either compile a Windows version of GRUB yourself, use a Linux LiveCD of some kind to do the installation, or use one of the two ready-made floppy images from the Wiki page Disk Images (warning: these might be a bit old).

[rdos]

No, it assumes you have a Linux platform from which to install GRUB. I have successfully installed GRUB on Windows-only systems using Knoppix Live-CDs.

Also, Cygwin supports GRUB 2, if you prefer that road.

I don't have any Linux platform, and I would not want to install cygwin again.

Why should they? Windows-only systems are hardly the targetted audience. And why should a GNU project do Windows users a courtesy?

By only supporting Unix-like systems, they lose all credibility as a "free software" organization. GNU, in fact, is an acronym for Linux.