Linux and Windows UEFI boot using Tianocore DUET firmware

[Keshav Amburay]

I moved the first post to https://gitorious.org/tianocore_uefi_duet_b...64_BIOS_to_UEFI . It is better to maintain this in a wiki than in a forum.

 

@srs5694 and migle: Please update duet-install and BootDuet UEFI DUET url to https://gitorious.org/tianocore_uefi_duet_b..._duet_installer and the forum link to https://gitorious.org/tianocore_uefi_duet_b...64_BIOS_to_UEFI . From now on this thread shall be used for discussing Windows and Linux UEFI boot using the DUET binaries.

 

GitHub repos have been deleted.

[Laqk]

@srs5694:

 

Since you developped GPT fdisk, maybe you can tell me what's happening here. The problem is this: Everytime I use GPT fdisk to convert a MBR disk to GPT, the resulting disk triggers a BSOD (believe it or not) on my Windows 7 x64 when connected. However, when I mount the same disk, on the same hardware, using an Ubuntu live cd and examine it with disk utility, it seems to be reported as a completely normal and healthy GPT-partitionned disk.

 

The disk in question is a healthy 80 GB western digital disk. I connect it to my laptop using and external enclosure connected through an eSata connection. For the conversion, I use the latest version of GDISK for Windows. I've tried creating the original MBR partition within Windows, and also with gparted on a linux live cd. Both method give me the same result. I've also tried a variety of original MBR configurations (one single partition taking up the entire disk, two or more partitions of varying sizes, formatted in a variety of formats, with or without free space left on the disk, etc), everything I try gives me the same result: The moment I connect the drive, Windows blue screens. If I try to boot Windows with the drive already connected, Windows freezes during bootup.

 

The only thing I haven't tried is using a linux version of GPT fdisk, because the .deb on sourceforge requires libicu 42, and the live cd I use has libicu 44, and I can't for the life of me figure out how to install a previous version of this library.

 

I seem to have a talent for stumbling on the most obscure bugs in applications...

[Keshav Amburay]

I have created a wiki at gitorious https://gitorious.org/tianocore_uefi_duet_builds/pages/Home with random UEFI stuff i posted in this forum, Ubuntu and Archlinux forums. Please read it and link to that wiki from now on. Comments are welcome.

[srs5694]

Since you developped GPT fdisk, maybe you can tell me what's happening here. The problem is this: Everytime I use GPT fdisk to convert a MBR disk to GPT, the resulting disk triggers a BSOD (believe it or not) on my Windows 7 x64 when connected. However, when I mount the same disk, on the same hardware, using an Ubuntu live cd and examine it with disk utility, it seems to be reported as a completely normal and healthy GPT-partitionned disk.

 

That's puzzling. Does your Windows installation boot via BIOS or UEFI? I've never run into this myself, although I do have a vague recollection of hearing about such a problem on a single disk. If you're getting it consistently, though, it's odd.

 

If you could use the gdisk backup feature ("b" on the main menu) to make a backup of a problem disk and e-mail it to me, I'd appreciate it.

 

My only suggestion for a solution is to use the Linux version of gdisk; it's conceivable that the bogus GUIDs generated by the Windows version are causing problems. (The Linux version generates proper GUIDs, but the Windows version just generates random numbers since I haven't figured out how to generate proper GUIDs in Windows.) Check the OBS download links here, use a slightly older version (only 0.7.1 uses the ICU libraries), or boot up PartedMagic or some other Linux emergency disc that includes gdisk.

[srs5694]

Since you developped GPT fdisk, maybe you can tell me what's happening here. The problem is this: Everytime I use GPT fdisk to convert a MBR disk to GPT, the resulting disk triggers a BSOD (believe it or not) on my Windows 7 x64 when connected. However, when I mount the same disk, on the same hardware, using an Ubuntu live cd and examine it with disk utility, it seems to be reported as a completely normal and healthy GPT-partitionned disk.

 

Some more on this: I've reproduced this problem. It occurs only on hard disks (not on USB flash drives), and on Windows 7 64-bit but not Windows Vista 32-bit. It is not, as I initially speculated, a reaction to the not-quite-GUIDs that the Windows version of GPT fdisk generates -- at least, not in and of itself. It appears to be a problem of Windows not properly recognizing the change from an MBR partition table to GPT. (A conversion from nothing to GPT is fine, though.) Unfortunately, Windows seems to "remember" the crash and repeats it the next time you boot or insert that same disk. Changing the disk's primary GUID code fixes the problem, whereafter restoring the disk to the state that caused the crash to begin with has no ill effects, so it's clearly not the state of the data structures created by gdisk alone.

 

I'm looking into real fixes, but for now my suggested workaround is to use a Linux boot to do the MBR-to-GPT conversion. Alternatively, if you've got a Vista 32-bit installation, you could use that to do the conversion.

[Laqk]

@srs5694

 

I had just logged in to post a follow-up when I saw your replies. Thank you for taking the time to investigate my problem.

 

I had already managed to solve it by doing essentialy what you advise. I used an older version of Ubuntu as a live cd (maverick) which has the proper version of the libicu library, and that allowed me to use the linux version of GPT fdisk, which worked flawlessly. So as you suspected, this is definately a problem with the Windows version of GPT fdisk.

 

But I'm sure you'll be able to sort this out very soon. Thank you for your work with GPT fdisk, which, as far as I can tell, is the only tool out there to do MBR -> GPT lossless conversions.

[srs5694]

Laqk,

 

I've tracked down the problem, and it turns out it is related to the not-quite-GUIDs that the Windows version of gdisk generates -- but Windows seems to be "allergic" to these only in very specific circumstances, which threw me at first. Also, Vista is fine with it; only Windows 7 (both 32- and 64-bit versions) is affected.

 

Anyhow, I've managed to get Windows to generate real GUIDs, and that fix will be released with the next version of GPT fdisk (0.7.2). I'm hoping to get it out soon, but for the moment I'm sitting on it because I'm trying to coordinate creation of a new GUID partition type code for Linux filesystems with the parted developers. I've already got the code in GPT fdisk, but I'd like to get the parted people to accept my patches related to this before I put that support in a released version of GPT fdisk, since I don't want some last-minute change in the GUID code to cause problems.

 

To bring this on topic, this is relevant to UEFI DUET because a unique type code for Linux will keep the Linux partitions from showing up in Windows when you install both under UEFI DUET. As it is now, Linux partitions appear under Windows, and if you double-click them, Windows claims they must be formatted -- but doing that would wipe your Linux installation. (IIRC, this behavior is old new for this thread, and there are workarounds, but a proper Linux-only filesystem type code is sorely needed.)

[Keshav Amburay]

Anyhow, I've managed to get Windows to generate real GUIDs, and that fix will be released with the next version of GPT fdisk (0.7.2). I'm hoping to get it out soon, but for the moment I'm sitting on it because I'm trying to coordinate creation of a new GUID partition type code for Linux filesystems with the parted developers. I've already got the code in GPT fdisk, but I'd like to get the parted people to accept my patches related to this before I put that support in a released version of GPT fdisk, since I don't want some last-minute change in the GUID code to cause problems.

 

Can you push the changes to the gptfdisk git repo? I hope that change does not cause compile issues with mingw-w64. I compile gdisk as a win64 binary using http://tdm-gcc.tdragon.net/.

 

I think it is better to let Linux kernel devs know about any new "Linux Basic Data " GUID you might create along with the parted devs. That way we might get linux kernel to recognize the new partition type guid as basic data type similar to how the userspace tools recognize linux lvm guid specific to that partition etc. If this guid is defined in the kernel itself, it will be easier to make distro installer and other tools use this guid instead of the Windows defined one. Except Linux all other OS have their unique Basic data Partition GUID defined seprate from the Windows one. Heck even ChromeOS has a different GUID defined for its rootfs.

 

To bring this on topic, this is relevant to UEFI DUET because a unique type code for Linux will keep the Linux partitions from showing up in Windows when you install both under UEFI DUET. As it is now, Linux partitions appear under Windows, and if you double-click them, Windows claims they must be formatted -- but doing that would wipe your Linux installation. (IIRC, this behavior is old new for this thread, and there are workarounds, but a proper Linux-only filesystem type code is sorely needed.)

 

This ia the reason why I currently use random guids for all my linux partitions (/boot,/var,/,/home etc.). BTW what happenned to gdisk's R option to generate random GUID (within the change type 't' option).

[Keshav Amburay]

Also please mention the bug in libparted that makes parted segfault when it encounters a disk with >128 partitions GPT tabel. I once created a 140 entries GPT table using gdisk in a USB pandrive just for fun. Parted segfaulted even for print/list partition table operation. For others http://lists.gnu.org/archive/html/bug-part...6/msg00026.html is the link to the discussion between srs5694 and parted devs.

[srs5694]

Can you push the changes to the gptfdisk git repo? I hope that change does not cause compile issues with mingw-w64. I compile gdisk as a win64 binary using http://tdm-gcc.tdragon.net/.

 

I've just made a final 0.7.2 release that includes the new type code. In gdisk, it shows up as type 8300, "Linux filesystem".

 

I think it is better to let Linux kernel devs know about any new "Linux Basic Data " GUID you might create along with the parted devs.

 

There's no point in involving the kernel developers, since the kernel doesn't currently use GPT GUID type codes except to detect LVM partitions -- or at least, I couldn't find any references to GPT GUID type codes except for that one purpose. (AFAIK, the kernel doesn't currently use MBR type codes, either.) Thus, a new Linux-only type code doesn't affect the kernel unless you wanted to redesign the kernel to use those type codes. I don't think there'd be much point to doing so, since decisions about creating, mounting, and otherwise using and manipulating partitions are all done in userspace.

 

If this guid is defined in the kernel itself, it will be easier to make distro installer and other tools use this guid instead of the Windows defined one.

 

Except that the kernel has nothing to do with this; it's the installers, which rely on libparted, that look at the disk and decide how to partition it and where to install. That's why I contacted the parted developers. They haven't responded to my last patch, though, which I submitted over a day ago, so I don't know if they're interested.

 

I've tested, BTW, and both Ubuntu 11.04 and Fedora 15 are perfectly happy to install on the new type code (or, presumably, any type code), although I expect they'd change it to a Microsoft Basic Data type. Presumably that would change if libparted were to support the new type code.

 

BTW what happenned to gdisk's R option to generate random GUID (within the change type 't' option).

 

I'd never really intended the 'R' option to be used in the way you've used it; it was there as a side effect of code intended to enable setting the unique GUIDs to random values. In changing the user interface code to simplify entry of specific unsupported GUIDs for the partition type code, the 'R' option got lost in that context -- at least mostly. You can still get a random partition type GUID by typing 'R' followed by 31 or more other characters. It's still there when entering unique GUIDs for partitions or the disk as a whole, too.

 

Because your reason for using a random GUID is simply to hide the Linux partition from Windows, using any partition type code that Windows doesn't recognize and that "belongs" to an OS you don't run would work as well. Of course, now you can use the gdisk 8300 code.

[Keshav Amburay]

There's no point in involving the kernel developers, since the kernel doesn't currently use GPT GUID type codes except to detect LVM partitions -- or at least, I couldn't find any references to GPT GUID type codes except for that one purpose. (AFAIK, the kernel doesn't currently use MBR type codes, either.) Thus, a new Linux-only type code doesn't affect the kernel unless you wanted to redesign the kernel to use those type codes. I don't think there'd be much point to doing so, since decisions about creating, mounting, and otherwise using and manipulating partitions are all done in userspace.

 

Except that the kernel has nothing to do with this; it's the installers, which rely on libparted, that look at the disk and decide how to partition it and where to install. That's why I contacted the parted developers. They haven't responded to my last patch, though, which I submitted over a day ago, so I don't know if they're interested.

 

In fact it does http://git.kernel.org/?p=linux/kernel/git/...s/efi.h;hb=HEAD . Its better to change it there too . Also I don't understand why the kernel devs named the source files fs/partitions/efi.{h,c} instead of fs/partitions/gpt.{h,c} .

 

I think PARTITION_SYSTEM_GUID should be renamed to PARTITION_UEFI_SYSTEM_GUID , PARTITION_BASIC_DATA_GUID to PARTITION_MSFT_BASIC_DATA_GUID , and define the new PARTITION_LINUX_BASIC_DATA_GUID . I could'nt find my way through LKML on how to post this.

[spotter]

Has anyone had problems with duet and AHCI mode for Sata drives?

 

Basically, what I've seen on my abit ip35-pro motherboard, if I boot (via bios) into linux first and then reboot into the tianocore duet firmware, everything works great. However, if I boot directly into tianocore (via cold boot, or reboot from windows), it hangs.

 

However, if I switch my sata drive from AHCI to IDE mode in the bios, the tianocore duet firmware works great.

 

As far as I know, I should be using 2.3 and have AHCI support (and if I didn't, any idea why booting into Linux first would make a difference?). (suprisingly enough, my windows 7 installed with ahci enabled, didn't blue screen when I switched it off, it just switched out the drivers automatically).

 

At least now, I have win7 supporting a 3TB drive as my boot disk without losing any space.

[Totony]

Hey,

 

I've been trying to get UEFI-DUET to work by chainloading it using GRUB2, but it won't work, only showing up EFILDR20 and then doing something with the screen pixels and restarting.

 

Here's what I did :

I :

- Created a 100MiB FAT32 filesystem with the boot flag under gparted.

-> Note that the type in gdisk was EF00

- mkfs.vfat -F32 -h <LBA> /dev/sda10

- dd if=bd32.bin of=/dev/sda10 bs=1 skip=90 seek=90 count=420

(Skipped the 7th step, as I don't need a MBR and as I can't get to compile it without getting errors (variable used, but not defined, something.h file not found) (if you want details about what is not working, ask it)).

- mount /dev/sda10 /mnt

- ./copy_duet_files.sh /mnt UDK_X64

 

Then I rebooted, went into GRUB2 shell and typed :

set root=(hd0,gpt10)

chainloader +1

 

Then it shows "EFILDR20", changes some pixels on the screen and restart.

 

Does someone know why it would just restart without doing anything ? As it already worked when I was using syslinux and memdisk combinaison and the tianocore img available.

 

I don't know if it could be caused by this, but I have 2 UEFI partitions (FAT32 having the boot tag). One for the syslinux+memdisk combinaison, and one to test BootDuet with UEFI.

[migle]

Hi, I couldn't spot what's wrong, but I can tell you what isn't wrong. I also chainload with GRUB2.

 

- Created a 100MiB FAT32 filesystem with the boot flag under gparted.

-> Note that the type in gdisk was EF00

 

boot flag isn't needed, you're using grub.

 

Then it shows "EFILDR20", changes some pixels on the screen and restart.

 

EFILDR20 message tells you that BootDuet loaded and is trying to load EFILDR20.

Pixels tell you that BootDuet didn't hang. Pixels sound like DUET, but you already know its face, since you where using it before.

 

I don't know if it could be caused by this, but I have 2 UEFI partitions (FAT32 having the boot tag). One for the syslinux+memdisk combinaison, and one to test BootDuet with UEFI.

 

I think FAT32 or boot flag is irrelevant. You should have only one EFI System Partition. However, even that seems to be irrelevant, as BootDuet will load the entire DUET file from the partition starting at the sector you indicated with the -h parameter to mkfs. So, even if DUET was troubled by you having two ESPs, it would load and take you to that familiar screen.

 

So, I'm beaten. Did you double check the -h parameter to mkfs, which goes into the HiddenSectors field of the partition boot sector?

 

 

You could try a more manual approach. Copy the files yourself by hand (you only need EfiLdr20 on the root dir to start, then if it works, add the rest).

Check the INSTALL file for BootDuet.

 

Remember, none of the partitions needs to be marked as an EFI System Partition. BootDuet doesn't care and nobody else (DUET) seems to care either.

 

Finally, if there is anything odd about your setup, that's probably important (such as having more than 2^32 sectors on your drive and having your ESP at the end of the disk...)

[Totony]

First of all, thanks for your help.

 

boot flag isn't needed, you're using grub.

Boot flag, in gparted, is used to identify EF00 (EFI Partition) (That's what I understood when searching about the subject).

 

So, I'm beaten. Did you double check the -h parameter to mkfs, which goes into the HiddenSectors field of the partition boot sector?

 

You could try a more manual approach. Copy the files yourself by hand (you only need EfiLdr20 on the root dir to start, then if it works, add the rest).

Check the INSTALL file for BootDuet.

 

Remember, none of the partitions needs to be marked as an EFI System Partition. BootDuet doesn't care and nobody else (DUET) seems to care either.

I'm quite sure of the -h parameter I put, but I'll recheck anyway when I come back home tonight.

I am marking the partitions as EFI System Partitions for Windows to find them easily. (Does it even matter for Windows ? I think I saw something saying I need it).

 

Finally, if there is anything odd about your setup, that's probably important (such as having more than 2^32 sectors on your drive and having your ESP at the end of the disk...)

I don't have that much sectors BUT the partition is in the middle of the disk, the LBA is something around 160 000 000. Could that be the problem ? I have a 2047 sector space beginning at the first sector which I could probably use to test Duet tonight.

 

Just something I'm not completely sure : The LBA is the sector where the partition starts ?

[migle]

Boot flag, in gparted, is used to identify EF00 (EFI Partition) (That's what I understood when searching about the subject).

 

That's strange, but ok. It's strange because GPT partitions may also have attributes, in some cases boot flag is an attribute.

I have been using Rod's gdisk on Linux and FreeBSD's tools all along.

 

I am marking the partitions as EFI System Partitions for Windows to find them easily. (Does it even matter for Windows ? I think I saw something saying I need it).

 

It matters to Windows, and you'll have to have only one.

But you're not there yet, so far, for loading and executing DUET correctly, it's not relevant.

 

Note that loading and executing DUET correctly means that you'll see the Tianocore message and that you'll be able to go to the menu.

 

I don't have that much sectors BUT the partition is in the middle of the disk, the LBA is something around 160 000 000. Could that be the problem ? I have a 2047 sector space beginning at the first sector which I could probably use to test Duet tonight.

 

Just something I'm not completely sure : The LBA is the sector where the partition starts ?

 

160 million is not a problem, mine also starts at ~300 million. You don't need to go to that space, which is also too small (2048 sectors is 1MB and EfiLdr20 may or may not fit in there depending on the format options).

 

Yes, by LBA I meant the first sector of the partition. I can't remember if it starts at 0 or 1 right now, but it's the exact same number where gdisk says the partition starts (also, you can't have an off-by-one error, because in that case BootDuet would hang with some other message, maybe BAD).

 

It's true that that is not what LBA means, it means Logical Block Address mode, meaning you address a sector (a logical block) by an ordinal number instead of Cilinder-Head-Sector.

 

I hope it's not BootDuet's fault!

[Totony]

Ok, I tried using only gdisk, here's what I did :

- gdisk /dev/sda

-> n, 9, ENTER, +100M, 0700

- mkfs.msdos -F32 -h <Startgdisk> /dev/sda9

-> Where <Startgdisk> is the starting sector that gdisk is displaying and is around 400 000 000.

- cd <UEFIDUET_DIR>

- dd if=BootSector/bd32.bin of=/dev/sda9 bs=1 skip=90 seek=90 count=420

- mount /dev/sda9 /mnt

- ./copy_duet_files.sh /mnt UDK_X86

- init 6

- Grub2 : "c", "set root=(hd0,gpt9) chainloader +1 boot"

- EFILDR20 showing up, pixel mixup, restart.

 

So this didn't work, I tried copying EDK_UEFI64's EFILDR20, but it didn't work either. I checked BootDuet.S a bit and re-make'd it using the debug define, and it gave me EFILDR20, then "268 370 177". I don't really know what this is supposed to mean, as I could not find the place where it was called from.

(Note that I modified the BootDuet.S source code to do this, and not the makefile).

 

I hope this helps if it is a problem with BootDuet. I'm not so good with assembly (I know Intel 32-bit protected mode a bit, though), so I can't really helps finding the problem if it comes from there.

 

I'll try some more things, but if anyone knows something I could try, feel free to tell me.

 

P.S. : Maybe the problem doesn't come from BootDuet, maybe it comes from EFILDR20, as I didn't use this before. What I was doing was using the pre-compiled .img available.

 

EDIT : I'll try compiling UEFI myself with the script provided in the linked wiki if I got the time.

EDIT2 : I tried using the Efildr file used to compile the .img, but it doesn't work.

[migle]

I'm not so good with assembly (I know Intel 32-bit protected mode a bit, though), so I can't really helps finding the problem if it comes from there.

 

Good, so there is a lot you can do even without writing your code.

 

Look, I don't know what the problem is.

BootDuet is simple. If there isn't a bug, it just loads the entire EfiLdr20 file into a fixed memory address and jumps into it.

EfiLdr20 is DUET itself. It isn't simple, but it's also not compiled by us, and we have all the reasons to trust it.

And if it is loaded contiguously into the right address, then it should work.

 

I don't think there's a bug in BootDuet (unless it envolves 64-bit LBA addresses, which I didn't test).

However, since EfiLdr should work, I must suspect.

There's something you seem to be able to test, however, it may be pointless, because nothing indicates that BootDuet isn't working.

 

I checked BootDuet.S a bit and re-make'd it using the debug define, and it gave me EFILDR20, then "268 370 177". I don't really know what this is supposed to mean, as I could not find the place where it was called from.

 

Good, you're brave. And since you're brave...

 

- BootDuet wrote EFILDR20 when he was attempting to read the entire file.

 

- When entering the "setup" region (line 523), the program checks if everything went well reading EFILDR20 and maybe EFIVAR.BIN, and if those files weren't found, it will print "Missing EFILDR20" or "Missing EFIVAR.BIN" on top-left corner overwriting whatever is in there. (Other types of errors, other than not finding the file will likely lead to an infinite loop somewhere or the message "BAD" being written).

 

- So, you had time to read the message EFILDR20 because the file took some time to read, which is a clear indication that it read correctly.

 

- The message 268370177 is because, when DEBUG is defined, to save precious bytes, I don't jump into EFILDR (if you're debugging, then you'll want to see something and halt, and there isn't enough bytes to have the code for both things in there). So, the "setup" routine falls through to whatever is next, which is the "printn" routine. printn is a function which writes whatever number is in EAX on screen in decimal and then halts (so you can read the number).

 

- That number, 268370177 is just whatever trash was left on EAX, in this case it's 0FFF0101, where the 01 on AH means EfiLdr was found and the 01 on AL means that EFIVAR.BIN wasn't found.

 

--

 

One way to see if the file was fully loaded is to print something which is at some memory address and check if that's what there is in the file.

For instance, my EFILDR file contains this funny sequence at file address 6cea8 (hex), "1dbN".

 

Because the file is loaded into physical memory address 20000 (hex), then, I should be able to find that pattern "1dbN" at 8cea8. And you can check by printing, using the following code, to insert at line 540 (DEBUG defined).

 

pushw $0x8000

popw %ds

movw $0xcea8,%si # DS:SI - pointer to what to write

movb $8,%cl # CL - number of chars

call print # call print

infiniteloop: jmp infiniteloop # Halt by infinite loop

 

If 1dbN appears on the screen and because a chose something near the end of the file, it's unlike that not all of the file has been loaded correctly.

 

In case you don't know 8086 real mode, a physical memory address is the segment address times 16 plus the offset address, so 8cea8 can be 8cea:0008 or 8000:cea8 or many other possibilities.

 

 

EDIT : I'll try compiling UEFI myself with the script provided in the linked wiki if I got the time.

 

That's too much trouble for my own taste.

 

 

What you could try:

- Have more care with the EfiLdr file, it should be the one from UDK_X64 (I think).

- Use the EFILDR file I'm using (I haven't updated recently, because the commits on Keshav's git repository only have a date in the message, which tells me little, and because the one I have its working):

 

I'm using the file on Keshav's tianocore_uefi_duet_installer repository on gitorious, the one which is on commit 55c55d (easy one) and on path EfiLdr/UDK_X64/EfiLdr20.

[Totony]

Ok, I tried what you told me, it gives the 1dbN + some random characters after if I reboot with the modifications and the 55c55d's commit Efildr, but it just restarts when I use the normal bd32.bin.

 

I think I'll stick up with the syslinux+img thing for now, if you want me to try some more things, feel free to ask

[migle]

Ok, I tried what you told me, it gives the 1dbN + some random characters after if I reboot with the modifications and the 55c55d's commit Efildr, but it just restarts when I use the normal bd32.bin.

 

I think I'll stick up with the syslinux+img thing for now, if you want me to try some more things, feel free to ask

 

The random chars were just because I put 8 in CL instead of only 4 (so it printed 8 characters from the file).

 

Ok, you determined that the entire file loads correctly. I think we must have rulled out the possibility that there's a problem with BootDuet with this step.

So, the pixels are EfiLdr's (DUET) output...

 

In any case, the question is: why would the same EfiLdr have some problem when loaded by BootDuet, but not when loaded from the syslinux image...

And why on your system...

 

I think you already tried all of these:

 

- using the same EfiLdr that is on your syslinux image,

- setting SATA mode in BIOS to AHCI, then to "IDE Compatibility",

- then maybe use a simpler partition layout (maybe with a spare disk),

- having only one EFI System Partition (you can just change the type of the other ESP to something else temporarily),

 

... I can't think of anything else...

 

What CPU do you have?

[Totony]

I think you already tried all of these:

 

- using the same EfiLdr that is on your syslinux image,

- setting SATA mode in BIOS to AHCI, then to "IDE Compatibility",

- then maybe use a simpler partition layout (maybe with a spare disk),

- having only one EFI System Partition (you can just change the type of the other ESP to something else temporarily),

 

... I can't think of anything else...

 

What CPU do you have?

 

- Yes

- When I tried that, there wasn't even a pixel mixup.

- I will probably try using a USB stick with BootDuet.

- That's what I did in my "I tried using only gdisk" post.

 

I have a Dell Inspiron 1545 with a Intel® Pentium® Dual CPU T3400 @ 2.16Ghz cpu.

 

Weirdly enough, I just re-tried everything, and it didn't work at first (no pixel mixup), but I got it to "work" playing around with it...

 

EDIT : Ohhh, I just found out that the memdisk EFILDR does not seem to even boot, as BootDuet's bd32.bin doesn't seem to be geared to boot it.

EDIT2 : I just tried using a FAT12 filesystem and it just printed random unicode characters. Same thing for FAT16.

[n01d3a]

I have read this entire thread and have found it very educational, and I admit, I don't understand most of the in depth details explained. A huge thanks to everyone that has made this as simple as it is.

 

Now, to get to the main reason why I am posting.

I am using BIOS_to_UEFI by following one of the guides provided by srs5694. I can get into the menu when using Efildr20 from the EDK_UEFI64 folder. I can also get to the menu if I rename Efildr20_FSVariable (from the UDK_X64) to Efildr20 . However, the original Efildr20 that is provided in UDK_X64 freezes at "Welcome to UEFI World."

 

I prefer to use SATA, so I would like to use the Efildr20 from UDK_X64. What is the difference between the FSVVariable and the normal Efildr20? I noticed it was mentioned earlier in the thread but did not understand the the difference between the two.

 

I have everything installed on my HDD. I used PartedMagic to create the partition tables and reformat the drive. I am using GPT on my HD, which was originally MBR. It has one 300MB Fat32 partition to put Efildr20 and EFI folder into. The rest of the space is not partition. I did not convert the drive or anything, everything should have been wiped clean and started the tutorial completely blank.

 

My computer specs.

Asus laptop G50V-X1.

 

Processor: Intel Centrino2 P8400 Dual Core 2.26 GHz

RAM: 4GB DDR 800Mhz

HDD: 300GB SATA

BIOS Version: 213

 

BIOS Settings (That seem relevant):

Intel Virtualization: Enabled

Intel VT-d: Disbaled

IDE Config (SATA/PATA): Enhanced(AKA AHCI)

[n01d3a]

Ok, so to follow up on my post and maybe provide some information for the people who are like me and don't understand the in depth details of this project.

 

I have successfully installed windows 7 in two configurations. Both were completely fresh installs. I followed the guide posted by srs5694, and after that was done I had to replace one file. Explained below. After that, everything seems to work.

 

First:

Using the Efildr20 from EDK_UEFI64. Your HDD must be IDE or in IDE mode for this to work. I put the windows install files on a 16GB flash drive because for some reason the CD/DVD drive is not recognized at all. Windows does take a little longer than normal to boot, I almost thought it froze at first. I read somewhere, I think from the wiki that is posted on the GIT website that this is known and is expected to be fixed in the future. Performance once inside windows was alright. I will be honest, it felt slower than it should have. Every now and then menus and windows would hang for a split second. Not sure if this is because my drives are in IDE mode, if this is because of using boot duet, or if it is part my imagination.

 

Edit: When I say for this to work, I mean for the UEFI environment to see your HDD and boot into windows. Assuming you have a working Efildr file, the Uefi environment will work in either AHCI or IDE mode.

 

Second (with SATA)

Unfortunately when using files from the newest version, the Efildr20 file that is in UDK_X64 hangs for me at "Welcome to UEFI," but as mentioned in a previous post the older version works. Use the version from the commit that starts with 55c55d.... Just replace the Efildr20 that is in your ESP/EFI/200MB (or whatever you named it) partition with the older one. After that I re-enabled AHCI. I had to re-install windows after this because I was getting BSOD. Still used the flash drive to install. Windows boots quite a bit faster this way and the performance in windows is better however still seems slow every now and then.

 

I could not get Efildr20_FSVariable to work with windows. I don't know the difference between the two so I am not really worried about it...

 

@srs5694 Your guide was very helpful in getting me setup. However the folder names are a little outdated now. It would be nice if you could update the site again. Or at very least maybe edit in there saying that there may be an issue with Efildr20 and what to do to get that working.

 

I do realize that it has been a short while since anybody has posted in thread,so maybe it is dead, but hopefully this basic knowledge I put here will assist others as they glance over when looking for solutions.

 

Once again I appreciate all the help and information provided in this forum. I posted all this because I felt like the information was scattered between this thread and the Git website. Everything that I mentioned here was relevant to me in order to get the UEFI environment and windows running.

[Alessandro17]

EDIT: The page has been moved.

 

I have just seen your post and I don't like it at all. Basically you are using InsanelyMac to advertise somebody else's site.

 

Link removed

[migle]

I have just seen your post and I don't like it at all. Basically you are using InsanelyMac to advertise somebody else's site.

 

Link removed

 

Alessandro17, are you serious? Do you really see that as a form of advertisement?

 

Did you read the topic?

Don't you see that on-par with the discussion on this forum, scripts and code was developped to address the issues?

Isn't gitorious more adequate for collaborating on code and scripts?

 

To me it seems that the discussion on this forum had items suited to be discussed on a forum and others which were not as much.

 

Advertisement?

Do you think Keshav, me, Rod and everybody else have any interest in this whatsoever?

Don't you think the contributions given on this topic, in particular by Keshav, deserve acknowledgement and maybe even gratitude for the amount shared for the pure benefit of others?

 

Is that really an advertisement of gitorious on your site?

 

Honestly!

 

Miguel