Friday Night Grub

OK, it's Friday evening and here I sit in front of my computer. I spent the afternoon reading Wrox's Professional Linux® Kernel Architecture weighing in at 1337 pages (was that 'leet' intentional?). So I needed a break from thinking of technical stuff--though during that break I read up on Red Black trees which are binary trees that have some simple rules which when violated are easy to detect and easy to fix and the act of fixing them keeps the Red Black tree relatively balanced.

Anyway, I am still working on my Grub problem. I want Grub to load in a stage 1.5 from my USB key and run properly. Last time, I got it to stop loading in the wrong 1.5, but it still doens't want to load the 1.5 that does what I want it to do. The cursor just sits there and blinks at me. And the only way to debug and troubleshoot is to compile code, load it on the USB drive and reboot. So while everyone is out having fun, I'm here at home. In my defense, I do have some Granville Island Maple Cream Ale in the fridge.

So, I wanted to confirm exactly which drive the USB stick is. So, I added the following code to stage1.S right before the notification string gets written. Note that %dl contains the booting drive:

 /* update notification with drive info */
 movl $ABS(notification_string), %ecx
 movb %dl, %al
 shrb $4, %al
 andb $0x0f, %al
 orb $0x30, %al
 movb %al, 0(%ecx)
 movb %dl, %al
 andb $0x0f, %al
 orb $0x30, %al
 movb %al, 1(%ecx)

What this does is to modify the notification string to create a sort-of hex representation of %dl. It won't be hex for nibbles greater than 9, but I can understand 0123456789:;<=>? instead of 0123456789abcdef.

I ran it and a few other related tests. The screen gets messed up but I had to remove some stuff to fit all this in. But I'm seeing '00'. So %dl is 0. I'm not sure if that's good or bad--but I think bad. The harddisk is supposed to 0x80. The upper bit is a flag that indicates a harddisk. So this essentially is saying the first disk is a floppy. In previous posts, you learned that I tried hardcoding the value to 0x80, 0x81, and 0x82 all to no avail.

But, not all is lost. I installed the nasm package which comes with ndisasm. That means I can disassemble the MBR of my USB boot from the USB Startup Disk Creator and reverse engineer that value--or enough information to get me further along.

OK, I spent some time reverse engineering the thing. Here are a couple of useful links:
http://en.wikipedia.org/wiki/INT_13
http://en.wikipedia.org/wiki/INT_10
http://en.wikipedia.org/wiki/X86
http://wiki.osdev.org/ATA_in_x86_RealMode_(BIOS)

OK, I spent some time disassembling and getting more and more acquainted with the int 0x13 and int 0x10 system calls that allow low level access to the hardware. Very interesting.

But let me make an observation that I just noticed--the Grub bootloader forces CHS mode as opposed to LBA mode when bit 7 isn't set on the drive. So my USB stick will be addressed in CHS mode and this will require the geometry (heads=255, cylinders=31, sectors/track=63). I think I'd prefer LBA mode and I'm pretty sure a USB key would support LBA mode. So I'll try to comment that out an see if it boots in LBA mode... (LBA mode lets you access the blocks on the disk as sequential numbers from 0 to 1-the number of LBAs. CHS mode forces you to address a block with a word whose bits are divided into three fields that don't necessarily go to the top of the range and, for sector, isn't even zero-based.)

So, I removed the part that forces my USB drive to go into CHS mode and it still didn't work. (btw, it is now Saturday afternoon and no longer Friday night). That tack having failed. I am off to write up some stage 1's that do nothing but tell me about my BIOS and my USB. That will be in a future posting.