Int13h AH=48. Looking for ATA channel to match PCI scan

[MarkD]

Hi,

The basic problem I'm trying to solve is to match the boot drive number provided by the BIOS to the results of a PCI and ATA scan. The output of int 13h AH=48h includes the PCI bus, device and function for drives on a PCI bus. It also includes for an ATA device whether the drive is the master or slave. But I can't find which channel of the ATA controller it's on - primary or secondary.

The best I can find is that the Device Parameter Table Extension includes the base IO port address. If the PCI function interface shows that the channel is in compatibility mode then I know that its base port is 1F0 (or 170) and I can match it to the DPTE. But this seems a roundabout way. What happens if the PCI config uses native mode and worse, the BAR is in memory space layout? Is it guaranteed that the BIOS will always set the ATA controller to be in compatibility mode?

Am I missing something?

Thanks.

[Octocontrabass]

Right after the PCI bus, device, and function should be the channel number. You must be looking at a really old draft of the EDD specification if it's not there. Try a newer version.

The latest version costs money, but drafts of earlier versions are floating around. Typing "T13/1572D Revision 3" into your favorite search engine and downloading the resulting PDF may or may not be copyright infringement, so be careful.

[rdos]

Why would your OS rely on legacy BIOS calls? I don't see why the OS would need to know where it booted from, and it should use PCI to detect ATA devices + possibly checking the primary & secondary addresses too if you are concerned with really old hardware.

[Octocontrabass]

I don't see why the OS would need to know where it booted from,

Why wouldn't the OS need to know where it booted from? How else is the OS supposed to know which disk contains its data?

[rdos]

I don't see why the OS would need to know where it booted from,

Why wouldn't the OS need to know where it booted from? How else is the OS supposed to know which disk contains its data?

I load the OS image file as a module through legacy BIOS or EFI. The OS image file contains the OS kernel, device drivers, and microkernel services (FS and SSL). It can also contain settings, ordinary files, and autostarts. That's all the OS needs to boot, so there's no need to know where it booted from. Discs and filesystems should be mounted the same way regardless of where the OS booted from, and then applications residing in the FS can be autostarted if needed.

I suppose most people would link a huge kernel image using the executable format supported by the loader (PE for EFI), but I never liked that idea. It wouldn't work either since then I would not be able to boot my 32-bit OS through the 64-bit EFI loader. It's better to bundle all the components needed for the current configuration in an OS image, which then can be loaded as a module using any loader.

[Octocontrabass]

and then applications residing in the FS can be autostarted if needed.

How do you do that if you don't know which filesystem is on the boot disk?

[MarkD]

Right after the PCI bus, device, and function should be the channel number. You must be looking at a really old draft of the EDD specification if it's not there. Try a newer version.

The latest version costs money, but drafts of earlier versions are floating around. Typing "T13/1572D Revision 3" into your favorite search engine and downloading the resulting PDF may or may not be copyright infringement, so be careful.

Perfect!! I was using an older version of the spec from 1998.
As soon as I adjusted to the T13 structure (including changing the size to 74 which I didn't notice until I had a quick look at the SeaBIOS source ) it all works in QEMU. Oddly enough Bochs shows the drive on an ISA bus, not a PCI bus. Another rabbit hole!

Thanks

@rdos You do you! For me, I want to know which disk holds my root filesystem as selected by the user during BIOS boot selection.

Thanks all.

[rdos]

and then applications residing in the FS can be autostarted if needed.

How do you do that if you don't know which filesystem is on the boot disk?

By using a pathname. Pathnames are not dependent on boot disks, and they can point anywhere.

[Octocontrabass]

By using a pathname. Pathnames are not dependent on boot disks, and they can point anywhere.

How do you make a pathname that points to the boot disk if you don't know which disk is the boot disk?

[nullplan]

Can we just try to deal with this the "normal" way? E.g. the way Linux does it: The boot drive completely does not matter. The boot drive is the drive the bootloader loads Linux and the InitRamFS from. The root drive is set via boot argument. So the bootloader tells the OS in a way that the OS chooses what the boot drive is (and the normal way for that to happen is that it is actually the user supplying the argument in the bootloader config). For stationary setups, this can be an unchanging device handle. For mobile setups, this is normally a UUID or partition label.

The kernel can discover all file systems in the computer on start up and search for the one it was given. If it can't find it, that is a panic. But it is a panic anyway, since that means the OS is incompatible with the storage solution for the boot drive the BIOS picked. So there's no loss here.

And it is of course completely possible to have a root device independent of the boot device. In fact, that is how encrypted root works with Linux. It is also possible to have a network root, which is completely impossible to tell the BIOS about.

So that's why such a solution is typically superior to the one you're trying to build.

[Octocontrabass]

E.g. the way Linux does it:

Linux allows userspace programs inside initramfs to choose the root filesystem, so Linux could use EDD to find the root filesystem if you wanted it to. Nobody wants that because UUIDs are better.

Linux really uses EDD to help installers guess where to put the bootloader.

For stationary setups, this can be an unchanging device handle. For mobile setups, this is normally a UUID or partition label.

It should be UUIDs everywhere. Anything else makes it really annoying to recover when something breaks. (Although for mobile setups, EDD might be helpful if there's a risk of duplicate UUIDs, such as a bootable disk image written to multiple disks.)

[rdos]

By using a pathname. Pathnames are not dependent on boot disks, and they can point anywhere.

How do you make a pathname that points to the boot disk if you don't know which disk is the boot disk?

Why would I want to use a pathname to the boot disk? I setup the partitions on the drive to fit the applications I want, and then I add autostarts through normal pathnames.

If you really want to identify where to find the "boot disk", you can use a setting that identifies it's root pathname. The setting can be embedded into the boot binary and can be diffierent in different boot binaries. Actually, I always create two boot binaries: a normal binary and a safe binary. Then if one of them becomes corrupt, I can typically boot the other.

[Octocontrabass]

Why would I want to use a pathname to the boot disk?

There can be many disks attached to a single PC. How do you know you're loading your applications from the correct disk?

[rdos]

Why would I want to use a pathname to the boot disk?

There can be many disks attached to a single PC. How do you know you're loading your applications from the correct disk?

I follow the "standard" DOS/Windows way of assigning drive letters to disk partitions, and a pathname always must contain the drive letter when starting applications. In Unix/Linux, I suppose the answers would be similar, but they use another technique to describe partitions.

I start out with a minimal configuration where the command shell, FTP server and sometimes TCP/IP debug server are bundled with the OS image, and therefore can be autostarted from the ramdrive (z:). This configuration can run without any disc drivers. Then I format the discs and install the applications on given drives, and then can autostart them using the pathname from the command shell.

So, the OS guarantees that fixed discs always get the same disc numbers and that drive leeters always are consistent. Fixed discs are allocated starting with drive c: and increasing. Removable discs are allocated starting with drive y: and decreasing. If you have multiple removable discs, the OS cannot guarantee that they will get consistent disc numbers or drive letters.

[eekee]

*Can* you know the boot drive? Plan 9 predates Linux and its bootloaders, and historically, it needed to know its boot drive to find plan9.ini. I remember a time some people had trouble because Microsoft changed their MBR code to no longer pass the boot drive in a register, making it impossible for the PBR to know the boot drive. 9front changed their loader to look for the active partition if I remember right. (It might instead have been the Plan 9 partition.) When they made it multiboot-compatible, they made it so you pass the plan9.ini file using multiboot's initrd mechanism. This is a much better solution in my opinion, and is how I'll be doing it.

I've lived through so many boot drive issues, mostly with Linux. LiLo was troublesome for some because, when running under Linux to create the bootloader, it couldn't know if the BIOS would assign drives in the same order. There were no UUIDs in those days. GRUB is a better design.

My Zaurus had only 2 CF-card slots for storage, fixed and removable, and the fixed one was the *secondary* drive. Whether the internal drive was /dev/hda or /dev/hdb depended on whether a removable card was inserted when Linux booted. This, and my habit of frequently changing drives around on PCs, got me into using UUIDs. Assigning drive letters or dev nodes in a fixed order would be nice, but would require special-case driver code for that particular Zaurus and would be hopeless with my hardware habits. Then there's the matter of booting laptops from external drives. I'm sure rdos is fine in its professional installations, but it wouldn't work out so well for me.