Personal TODO List:

I'm the official maintainer of GRUB, and the author of GRUB 2... Some people mistake me from the original author, but the original is Erich but not me...

I'm currently trying to port GRUB 2 to Intel Mac (EFI-based PC). Don't expect much at the moment, since I'm just started. :)

2006-04-18

OK, I now have something booting. I've written an "ELF to PE32" converter, and GRUB can print out stupid messages on the screen with the help of Intel's Sample Implementation. Since I don't want to depend on the Intel Sample Implementation, I will drop it out in near future, but I will use it until GRUB itself supports the graphics console. The next step is to write a text console terminal based on the EFI's simple text output protocol, and manage the memory space. Once these are done, I will implement a graphics console terminal based on chaac's gfxterm, and module loading.

2006-04-19

I've implemented the text console and the memory management. Now the rescue mode is working. :)

I also investigated some other things. I've tried GRUB without the Shell.efi from Intel Sample Implementation, and it works fine. So strictly speaking I have no reason to use Intel Sample Implementation. The Apple's firmware seems to contain a lot of stuff from the Intel Sample Implementation already.

Another thing was netbooting. I tried to make it easier to develop GRUB, but no luck. The DHCP client repeats sending DHCPINFORM packets, and finally gives up. It's like the client wants some special parameter. As far as I see, there is no detailed public information on how BSDP works, so the only way to address this issue might be reverse-engineering. As this is very time-consuming, I'm not planning to do this in near future. For now, I'm using a CF with a USB adapter to boot up GRUB.

During the development at this time, I notified a bug in the EFI spec again... I think this was the second time I found bugs in the spec. The memory descriptor structure must have 32-bit padding after the memory type field, but the spec does not include such a thing at all. I realized this after spending 1-2 hours when looking at the header file in Intel Sample Implementation. Damn it.

Since the text console is working fine, I will skip a graphics console at the moment. Next, I will add module loading and a disk driver. I guess I will have to debug the HFS+ driver...

2006-04-20

Module loading has been finished. I now look at how to implement a disk driver. I must deal with the device path nodes. This looks heavy. EFI seems to support a low level block I/O and a high level disk I/O. Since GRUB itself has its own cache management, using the disk I/O would make things inefficient, but I'm afraid of leading to cache inconsitency if I use the block I/O...

2006-04-21

It's a bit slowed down today. I have implemented device path handling code, but it took me a lot of time to find out a stupid typo...

I'm investigating how to enumerate devices by stearing at a real example on my mac mini. I have read the EFI spec again and again, and surprisingly there is no generic way to figure out the type of a given device! The only way is to look at a partition device path which must be recognized by the firmware. According to the spec, the firmware may provide a partition zero, which represents the whole disk, but the firmware on mac mini obviously does not have such a device. This is really annoying for GRUB, since GRUB generally supports much more than any firmware, so limiting the knowledge to that given by the firmware means that GRUB may not utilize its own power. :(

So what should be done? I can still access the entire device. But how can GRUB name devices when the types are unknown? Well, if a device is a USB one, I can query the device class to the controller... but how about ATAPI? Looking at the block size and hardcode that a device is a hard disk when it is 512 bytes? This sounds horrible. In a sense, this is even worse than BIOS.

I guess I must use a heuristic way here. Ughh, again a nightmare. I really hoped that I could forget such an ugly thing with EFI, but things are not that different. Probably the following way would be necessary:

Anyway, the use of a device name is highly unreliable with any existing technology. One might think that it would be precise to specify a device path, but this not. For example, a PCI configuration is not persistent, due to the PnP feature. Also, this has an unfortunate side effect that GRUB does not work magically when you connect a disk to another place, since the device path changes.

In GRUB 2, the right way to specify a device is to use the command "search" - this is extremely dynamic but realiable as long as you specify something really unique. Probably the best way would be to use UUID, but I haven't implemented UUID support yet. As long as GRUB recognizes a device correctly, its name does not really matter except for human. Whether a device is a CDROM drive or a hard drive has no sense for GRUB itself.

2006-04-23

I've got disk access! Bravo! :)

The difficulty was to figure out the right offsets of the members of the EFI_BLOCK_IO_MEDIA structure. In VC++, padding seems to be generated correctly, but GCC behaves differently. So I had to look at memory dumps, and guess the padding. After that, with the combination of my "device type detector", everything went fine.

Next, I must think how to map a GRUB device to an EFI device. Once this is finished, it would not be difficult to set the varibable prefix and write a chainloader.

2006-04-25

I've implemented the mapping. During this development, I also enhanced other things as well. Since I had a serious memory problem, I decided to incorporate my hack of printing a lot of information into the official repository in a clean way. Now, only by setting a variable, I can trace all memory-related function calls. This significantly makes it easier to figure out where GRUB gets broken.

Also, I had to delay the initialization of prefix and root, because I map EFI devices by iterating GRUB partitions, but GRUB needs to load the gpt module before this. I hope this change won't have any side effect.

OK, in theory, the normal mode should work fine at this stage, although I haven't tried it yet. Next, I will work on a chainloader, so that I can call it a boot loader. ;)

2006-04-27

I was testing the normal mode, and found some serious problems about the keyboard handling. I must push TAB three times to enter one TAB. And, I cannot use the control key at all, since EFI does not return any scan code for Control, and the code does not change at all, whether I push Control at the same time or not. This is very annoying, as I cannot do completions quickly, and I cannot use several features (such as Ctrl-k, Ctrl-u and Ctrl-o). I really hope that Apple will give me some (positive) answer.

At the moment, I'm thinking of assigning the same features to multiple keys, such as function keys...

2006-04-30

I've implemented a preliminary chainloader, and I could boot up MacOSX. From this experience, I've realized that the MacOSX loader is buggy. It does not have the flexibility defined by the EFI spec at all. Anyway, this is the first milestone to make GRUB useful on EFI. Next, I will work on a Linux loader.

2006-05-07

These days, I'm working on more generic issues.

2006-05-28

Finally, Linux is bootable on EFI! This development was quite hard, because Linux cannot display anything at the bootstrap stage. My approach was to put int3 into Linux to reboot the machine forcibly. Since Linux hanged up with no modification, rebooting was a good measure to know where Linux hanged up. Well, this was not very funny, but I found out that the HFS+ code in GRUB was wrong again. :(

So I debugged HFS+, and Linux was booted successfully...

GrubWiki: YoshinoriOkuji (last edited 2006-06-05 17:51:12 by YoshinoriOkuji)