Funny Dell BIOS and how to determine number of HD connected

To determine how many hard disks are connected and put the booting USB as last one, I currently use something like:

title First part of Windows 2003 SP1 setup from partition 0

map --unmap=0:0xff

map --unhook

map --mem (hd0,0)/WINSETUP/23SP1.ISO (0xff)

savedefault 2

checkrange 0x00,0x01 read 0x8280 && configfile /BOOTWS/fd.lst

geometry (hd9) && configfile /BOOTWS/10.lst

geometry (hd8) && configfile /BOOTWS/9.lst

geometry (hd7) && configfile /BOOTWS/8.lst

geometry (hd6) && configfile /BOOTWS/7.lst

geometry (hd5) && configfile /BOOTWS/6.lst

geometry (hd4) && configfile /BOOTWS/5.lst

geometry (hd3) && configfile /BOOTWS/4.lst

geometry (hd2) && configfile /BOOTWS/3.lst

geometry (hd1) && configfile /BOOTWS/2.lst

geometry (hd0) && configfile /BOOTWS/1.lst

boot

map --unmap=0:0xff

map --unhook

Dell Latitude E6400 is the troublemaker. In BIOS for SATA mode there are four options: disabled, IDE, AHCI and IRRT (Intel Rapid Restore Technology).

When in IRRT mode the above doesn't work correctly, "geometry (hd9)" returns no error and goes to "configfile /BOOTWS/10.lst" whereas it should go through to "geometry (hd1) && configfile /BOOTWS/2.lst", the screenshots explain better why:

Grub4dos booted from USB stick and only one internal SATA disk in IRRT mode:




It seems the only one internal hard disk is mapped to every possible HD number.
Tried with with grub4dos versions- 0.4.5a 2010-02-09, 0.4.5b 2010-08-12, 0.4.4 2009-03-30 and 0.4.4 2009-10-31.
BIOS versions A24 and A25.

Any ideas how to achieve same goal? I guess other recent Dell laptops and not only Dells might behave the same way.

Well, if you don't also post one of the /BOOTWS/n.lst files, how do you think that people can understand what you are doing?

Here it is :

map (hd0) (hd9)

map (hd1) (hd0)

map (hd2) (hd1)

map (hd3) (hd2)

map (hd4) (hd3)

map (hd5) (hd4)

map (hd6) (hd5)

map (hd7) (hd6)

map (hd8) (hd7)

map (hd9) (hd8)

map --hook

ls (0xff)/ && root (0xff)

ls (0xff)/I386/ && cat --locate=rdisk(1) --replace=rdisk(9) (0xff)/I386/TXTSETUP.SIF

ls (0xff)/AMD64/ && cat --locate=rdisk(1) --replace=rdisk(9) (0xff)/AMD64/TXTSETUP.SIF

ls (0xff)/ && chainloader /I386/SETUPLDR.BIN

ls (0xff)/ || rootnoverify (hd0)

ls (0xff)/ || chainloader (hd0)+1

boot

These reconnects to the oldish idea of having something like a "shift" command, but if the detection on those pesky BIOSes doesn't work "manually" I don't think it would work.

What you are trying to create is a "rotating stack" with n elements of which you try to find the n but it is the geometry (hdn) method you are using that is failing.

Maybe a more "aggressive" method, like attempting to read first sector of each disk may be more accurate.

What happens with something like:

cat --hex (hdn)+1

Wonko

Thanks for clarifying

cat --hex (hdn)+1

map (hd0) (hd9)
map (hd1) (hd0)
map (hd2) (hd1)
map (hd3) (hd2)
map (hd4) (hd3)
map (hd5) (hd4)
map (hd6) (hd5)
map (hd7) (hd6)
map (hd8) (hd7)
map (hd9) (hd8)

Too many mappings. Grub4dos only defined 8 slots, each for a mapping.

how to determine number of HD connected

How about this method?

read 0x475

The lowest byte is number of hard drives that the BIOS has established. google for "bios data area" for details about hard drive count recognized by BIOS.

Too many mappings. Grub4dos only defined 8 slots, each for a mapping.

Will keep this in mind, thanks.

How about this method?

read 0x475

The lowest byte is number of hard drives that the BIOS has established. google for "bios data area" for details about hard drive count recognized by BIOS.

Dell machine returns 0x14000802 in IRRT mode, QEMU returns 0x1400c002, both with 2 HD attached.
Now how do we take only and use only the lowest byte while in grub4dos?

Does USB card readers with empty slots count too? Would someone with a USB card reader check that and post the result?

you read more bytes
02 is offset 475 in BDA so you have 2 disk detected by BIOS.
Here appears only presented disks.

you read more bytes...

How do you read less bytes, that's the point...

Those are result of "read 0x475", how do you read and use only the lowest byte?

I'll try to re-phrase:

What happens with something like:

cat --hex (hdn)+1

I do know that you will see the contents of the MBR of the disk n, this is actually what the command is expected to do!

I meant what happens when n represents a NON-existing drive?

Like:

cat --hex (hd7)+1 && configfile /BOOTWS/8.lst
cat --hex (hd6)+1 && configfile /BOOTWS/7.lst
cat --hex (hd5)+1 && configfile /BOOTWS/6.lst
....

Wonko

I'll try to re-phrase:...

Did you look at the screenshot closely? It's hd9999's MBR

Did you look at the screenshot closely? It's hd9999's MBR

Nice idea.

I had thought that hard disks were (hd0) to (hd31) and CD's (hd32) to (hd255) or (0xFF), never thought that could be anything above 255.


Wonko

"geometry (hd9)" returns no error and goes to "configfile /BOOTWS/10.lst" whereas it should go through to "geometry (hd1) && configfile /BOOTWS/2.lst"......

It seems the only one internal hard disk is mapped to every possible HD number.

You should not blindly access an HD drive before you are sure it exist. If BIOS told you it has (only) 2 HDs (hd0 and hd1), then you should not access (hd2), (hd3), etc.
To access such a drive could cause hangup on some (bad) machines.

Now how do we take only and use only the lowest byte while in grub4dos?

You may use the calc command built in with the latest development releases:

calc *0x475 & 0xFF

Note that the "first" hard drive is (hd0), and the "last" drive is (hd-1). In your above case, (hd-1) is actually (hd1).

I had thought that hard disks were (hd0) to (hd31) and CD's (hd32) to (hd255) or (0xFF), never thought that could be anything above 255.

Even (hd255) is too big. The BIOS-specific maximum drive number is (hd127) which is equivalent to (0xFF) or (255).

(hd255) is (0x17F) or (383).

But grub4dos uses long integer (4 bytes) for a drive number. The (md) device uses (0xFFFF). And (0xFFFFFFFF) stands for "Invalid drive". And some numbers are used for bifurcate drives (See README_GRUB4DOS.txt). Most of other integers greater than 255 are not used at present. Do not try to access those drives, since when grub4dos finally access them using BIOS, it will only use the lowest byte of the 4-byte drive number, and it could (happen to)be 00 for floppy, or anything else unexpected.

You should not blindly access an HD drive before you are sure it exist. If BIOS told you it has (only) 2 HDs (hd0 and hd1), then you should not access (hd2), (hd3), etc.
To access such a drive could cause hangup on some (bad) machines.

Yep , nice and rightful theory , but the question or problem is/was a practical one:

How can I programmatically within a grub4dos menu.lst determine the number of hard disks connected (getting this info from the BIOS) AND use the result in a conditional statement using the operators || or &&?

Or if you prefer:

Since when a USB device is set as boot device, it will always get (hd0), effectively shifting all the internal hard disks numbnering up by one, how is it possible to "shift down" the hd numbers and add the USB device as (hdn) where n is the total number of hard disks AND have n explicted AND usable within a menu.lst entry?

Wonko

You may use the calc command built in with the latest development releases:

calc *0x475 & 0xFF

With 2 HD connected:

checkrange 2 calc *0x475 & 0xFF && read 0x00
2 (HEX:0x2)

Address 0x0: Value 0xf000ff53

checkrange 1 calc *0x475 & 0xFF && read 0x00
2 (HEX:0x2)

How can I programmatically within a grub4dos menu.lst determine the number of hard disks connected (getting this info from the BIOS) AND use the result in a conditional statement using the operators || or &&?

just as shown by ilko, use something like

checkrange 1:4 calc *0x475 & 0xFF && do_something

Since when a USB device is set as boot device, it will always get (hd0), effectively shifting all the internal hard disks numbnering up by one, how is it possible to "shift down" the hd numbers and add the USB device as (hdn) where n is the total number of hard disks AND have n explicted AND usable within a menu.lst entry?

The shift down/up mapping is not implemented. so you have to do it one by one manually.

"total number of hard disks" can be obtained by "calc *0x475 & 0xFF" as mentioned above.

You may consider this way(though a half way, not a complete solution):

Step 1. "map hd0 to be the last drive": map (hd0) (hd)

it will map (hd0) at the end of the hard drives, that means, for example, if the BIOS has 3 hard drives of hd0, hd1 and hd2, then "map (hd0) (hd)" will be equivalent to "map (hd0) (hd3)", and similarly
"map (hd0) (hd-1)" will be equivalent to "map (hd0) (hd2)"
"map (hd0) (hd-2)" will be equivalent to "map (hd0) (hd1)"
"map (hd0) (hd-3)" will be equivalent to "map (hd0) (hd0)"(and as you know it is an unmap of hd0, which means canceling the map of hd0).

Step 2. "map hd1 to be hd0": map (hd1) (hd0)

Usually all other drives need not map. If you do need to map some of them, just do it as an extra step, e.g., map (hd2) (hd1)

Step 3. map --hook

OK.

I see that little by little I can get some actual answers.

If I may express an opinion, Ilko made a "wrong" approach not because he is lazy and not because he didn't try understanding how grub4dos works, BUT only because still a LOT of documentation - and expecially the "advanced" parts of it - are simply a-missing.

In three sentences you opened a whole world of possibilities till now AFAIK unknown in the Western world....

Now, I'll risk a couple more "direct" questions:
if this is "wrong":

title First part of Windows 2003 SP1 setup from partition 0

map --unmap=0:0xff

map --unhook

map --mem (hd0,0)/WINSETUP/23SP1.ISO (0xff)

savedefault 2

checkrange 0x00,0x01 read 0x8280 && configfile /BOOTWS/fd.lst

geometry (hd7) && configfile /BOOTWS/8.lst

geometry (hd6) && configfile /BOOTWS/7.lst

geometry (hd5) && configfile /BOOTWS/6.lst

....

Is this "right"?:

title First part of Windows 2003 SP1 setup from partition 0

map --unmap=0:0xff

map --unhook

map --mem (hd0,0)/WINSETUP/23SP1.ISO (0xff)

savedefault 2

checkrange 0x00,0x01 read 0x8280 && configfile /BOOTWS/fd.lst

checkrange 8 calc *0x475 & 0xFF && configfile /BOOTWS/8.lst

checkrange 7 calc *0x475 & 0xFF && configfile /BOOTWS/7.lst

checkrange 6 calc *0x475 & 0xFF && configfile /BOOTWS/6.lst

....

And if this is wrong (8.lst):

map (hd0) (hd7)

map (hd1) (hd0)

map (hd2) (hd1)

map (hd3) (hd2)

....

is this "right"?

map (hd0) (hd)

map (hd1) (hd-7)

map (hd2) (hd-6)

map (hd3) (hd-5)

....

Or there are "better" ways?


Wonko

I can't tell which is right and which is wrong. Perhaps there are "better" ways, but I still have no idea.

map (hd1) (hd-7)

it can be used only when there are 7 hard drives or more.

And documentation lacks. This might be because the developers have no time to write it.

I can't tell which is right and which is wrong. Perhaps there are "better" ways, but I still have no idea.

Thanks anyway.

You anyway added a BIG piece to the puzzle.

Let's see what Ilko comes out with....


Wonko

I guess it would be just:

...

checkrange 8 calc *0x475 & 0xFF && configfile /BOOTWS/8.lst

checkrange 7 calc *0x475 & 0xFF && configfile /BOOTWS/7.lst

checkrange 6 calc *0x475 & 0xFF && configfile /BOOTWS/6.lst

...

Thanks again tinybit, a lot of new stuff was learnt