Jump to content

Linux and Windows UEFI boot using Tianocore DUET firmware


  • Please log in to reply
153 replies to this topic

#41
heliox

heliox

    InsanelyMac Protégé

  • Members
  • PipPip
  • 70 posts
  • Gender:Male
  • Location:Nice,FRANCE
Thanks a lot Keshav. You're the man. For various reasons I've given up GPT partitions but still monitoring this DUET stuff. I've downloaded your files already for future use.
Keep it up.

#42
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
@heliox: I have uploaded a new Efildr firmware with AHCI support implemented by VirtualBox. It is a mix of EDK2 and VBoxPkg from VirtualBox OSE. Can you try it and send in your comments? I also want to know how much of your RAM is consumed when using memdisk. ;)

#43
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal
Hello, Keshav, and first of all thank you for making a compiled version of DUET available.

My story is the following, I uninstalled Windows for some time, started using GPT, now I have 20 partitions and don't want to go back. Only then I found out about Windows not booting from GPT. The hybrid MBR technique doesn't help me get Windows to boot (if the protective partition is the first, Windows sees the disk as GPT and doesn't boot, if it's not, I can't use GRUB).

I was pretty much put away by the strange requirements for compiling DUET. The Windows DDK? What for? mingw on Linux? This thing doesn't use Win32! Something is wrong with whoever did that build system. Your pre-compiled version helped a lot.

However, your memdisk technique sounded a bit too complicated for me. I read the code for bootsect.asm and start.asm, so I saw their limitations. So, last weekend I wrote a replacement program for the boot sector of a FAT partition which is able to fully load both EFILDR and EFIVAR.BIN and execute EFILDR successfully (skipping the first part of it).

So far, I can only boot EFILDR, run the shell, and little more. I still can't reinstall windows because it doesn't seem to be able to read the DVD. Of the two versions you compiled, only one of them allows me to read the hard disk (AHCI) and load the shell. That version sees the DVD, but doesn't read it well.

I wonder if those are limitations of those versions of EFILDR or if they are some defect of my boot program?

I would be very happy if you tried my boot program and told me if it works well for you. It uses 32-bit LBA addressing and installs into the boot sector of a FAT12/16/32 partition. You'll see it was very difficult to squeeze the FAT chain loading code which works fully according to spec into those 448 bytes.
The code is very easily compilable (GNU make and GCC) and installable on Linux.

It's on github, https://github.com/migle/BootDuet.

After that, I would like to know more about how you managed to find your way around DUET and compile it. I'm pretty lost still.

#44
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

Hello, Keshav, and first of all thank you for making a compiled version of DUET available.

My story is the following, I uninstalled Windows for some time, started using GPT, now I have 20 partitions and don't want to go back. Only then I found out about Windows not booting from GPT. The hybrid MBR technique doesn't help me get Windows to boot (if the protective partition is the first, Windows sees the disk as GPT and doesn't boot, if it's not, I can't use GRUB).

I was pretty much put away by the strange requirements for compiling DUET. The Windows DDK? What for? mingw on Linux? This thing doesn't use Win32! Something is wrong with whoever did that build system. Your pre-compiled version helped a lot.


Glad to help. The build system of edk2 is a great improvement over edk1. I use this script https://github.com/s...ompile_setup.sh to compile duet and i patched the DuetPkg.dsc and fdf files slightly to make sure duet compiles successfully (like remove EBC to reduce size of image etc.).

Right now edk2 duet is able to compile in normal gcc 4.6 (Archlinux x86_64) and no need for mingw (it was required previously for msabi, which was added later in gcc 4.4 onwards).

I no longer compile edk1 duet. It is way too old and does not support AHCI. Did you try edk_uefi64 or edk2_x64?

However, your memdisk technique sounded a bit too complicated for me. I read the code for bootsect.asm and start.asm, so I saw their limitations. So, last weekend I wrote a replacement program for the boot sector of a FAT partition which is able to fully load both EFILDR and EFIVAR.BIN and execute EFILDR successfully (skipping the first part of it).


Its actually easy, just setup syslinux bootloader in your system and add the memdisk to syslinux config file.
Can the fat partition be a gpt one? Unfortunately i do not know programming to understand your code. Maybe you should discuss about this at http://sourceforge.n...name=edk2-devel ML.

Right now duet does not boot from a gpt partition. I will try this one but i cannot give a timeframe since my exams are starting and it may take me 2 weeks or more to respond. Memdisk is just a workaround. I would prefer actual booting duet from a actual fat32 gpt partition anyday.

So far, I can only boot EFILDR, run the shell, and little more. I still can't reinstall windows because it doesn't seem to be able to read the DVD. Of the two versions you compiled, only one of them allows me to read the hard disk (AHCI) and load the shell. That version sees the DVD, but doesn't read it well.


Can you try (in the AHCI efildr one) this in efi shell

fs0:
cd efi\boot
bootx64.efi

I wonder if those are limitations of those versions of EFILDR or if they are some defect of my boot program?

I would be very happy if you tried my boot program and told me if it works well for you. It uses 32-bit LBA addressing and installs into the boot sector of a FAT12/16/32 partition. You'll see it was very difficult to squeeze the FAT chain loading code which works fully according to spec into those 448 bytes.
The code is very easily compilable (GNU make and GCC) and installable on Linux.

It's on github, https://github.com/migle/BootDuet.

After that, I would like to know more about how you managed to find your way around DUET and compile it. I'm pretty lost still.


Check this out -
http://sourceforge.n...name=edk2-devel

#45
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal

Right now edk2 duet is able to compile in normal gcc 4.6 (Archlinux x86_64) and no need for mingw (it was required previously for msabi, which was added later in gcc 4.4 onwards).

Oh? I must try it then.

I no longer compile edk1 duet. It is way too old and does not support AHCI. Did you try edk_uefi64 or edk2_x64?

I keep forgetting which one I just installed... I have two FAT partitions (FAT16 and FAT32). I put edk_uefi64 on one and edk2_x64 on the other.
edk_uefi64 seems to work only when I set BIOS to "Compatibility mode".
edk2_x64 seems to work in that case and when BIOS is set to AHCI.

Only one of them seems to be getting EFIVAR.BIN right. I see that when I change some setting such as boot timeout and then reset.

So, which one should I focus on? edk2_x64?

Can the fat partition be a gpt one? Unfortunately i do not know programming to understand your code.

Sure. It can also be an mbr one, but there isn't much point in that.
The program knows nothing about partitions, it needs that the Hidden Sectors field of the partition boot sector is filled in with the LBA at which the partition starts, so it can find it.

Right now duet does not boot from a gpt partition. I will try this one but i cannot give a timeframe since my exams are starting and it may take me 2 weeks or more to respond. Memdisk is just a workaround. I would prefer actual booting duet from a actual fat32 gpt partition anyday.

Well it works with my boot program.

Can you try (in the AHCI efildr one) this in efi shell

fs0:
cd efi\boot
bootx64.efi

Well, neither the "Boot from file" option nor the shell ever see anything in my Vista DVD.
Also, my Vista DVD doesn't have a bootx64.efi file, only cdboot.efi and cdboot_noprompt.efi.
(BTW, I'm not following your guide, installing Windows to an MBR partition and then converting to GPT also because my DVD doesn't seem to have the Repair option).

Right now, I copied those files from the DVD to one of my FAT partitions. Then, on the shell, I can type similar commands to load cdboot.efi.
Then, cdboot.efi loads but then complains about BCD.

So, after I changed my BIOS to "Compatibility mode" I had the impression that EFILDR actually sees and reads my DVD drive. But because it never sees the files in there, I assumed it could not understand the ISO file system in the DVD.

I discovered the "drivers" command of the shell. I see there is a driver for FAT but not for ISO.
So, my interpretation was it had no driver for ISO file system, and I will have to get one...

But are you saying you can read the ISO file system on a DVD with this thing?

Check this out -
http://sourceforge.n...name=edk2-devel

Yes, they are talking about the error which occurs on bs32.asm. That would be the first error and if that one was corrected more limitations would step in. That one is related to bs32 using a BIOS function which is limited to 1023 cylinders.
My boot program safely replaces those and uses LBA. It also avoids having to compile all those tools that do automated cut&pasting of boot sector bits and which also have limitations of their own.


So, I got DUET to boot from a GPT FAT partition, but I have nothing to boot. Right now, I'm trying Linux and ELILO, still with no success. I wonder if I could replace GRUB with this thing, eliminating another step of the boot process.

#46
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

I keep forgetting which one I just installed... I have two FAT partitions (FAT16 and FAT32). I put edk_uefi64 on one and edk2_x64 on the other.
edk_uefi64 seems to work only when I set BIOS to "Compatibility mode".
edk2_x64 seems to work in that case and when BIOS is set to AHCI.

Only one of them seems to be getting EFIVAR.BIN right. I see that when I change some setting such as boot timeout and then reset.

So, which one should I focus on? edk2_x64?


efivar.bin == edk_uefi64 == no ahci and very old , not recommended
edk2_x64 == in memdisk but does not create efivar.bin (intentional) since that option creates blue screen in windows x64 and linux kernel panic (without 'noefi' kernel option)

In EDK2_X64 , I replaced DuetPkg/FSVariable/FSVariable.inf with MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf , otherwise it leads to Windows 7 x64 Blue Screen and Archlinux x86_64 Kernel Panic if FSVariable is used.

FSVariable produces efivar.bin which acts as storage for efi runtime services variables. EmuVariableRuntimeDxe creates a virtual store in memory everytime duet is run and gets erased when system is shutdown. There seems to be some problem in SetNextVariable of FSVariable in edk2 duet which causes the kernel panic http://sourceforge.n...msg_id=26027879 , http://sourceforge.n...msg_id=24967648 .

Well, neither the "Boot from file" option nor the shell ever see anything in my Vista DVD.
Also, my Vista DVD doesn't have a bootx64.efi file, only cdboot.efi and cdboot_noprompt.efi.
(BTW, I'm not following your guide, installing Windows to an MBR partition and then converting to GPT also because my DVD doesn't seem to have the Repair option).

Right now, I copied those files from the DVD to one of my FAT partitions. Then, on the shell, I can type similar commands to load cdboot.efi.
Then, cdboot.efi loads but then complains about BCD.

So, after I changed my BIOS to "Compatibility mode" I had the impression that EFILDR actually sees and reads my DVD drive. But because it never sees the files in there, I assumed it could not understand the ISO file system in the DVD.

I discovered the "drivers" command of the shell. I see there is a driver for FAT but not for ISO.
So, my interpretation was it had no driver for ISO file system, and I will have to get one...


Duet does not have iso9660 fs driver. It has only fat12/16/32 driver. For bootx64.efi, extract /efi/microsoft/boot/efisys_noprompt.bin , and copy the /EFI/BOOT/BOOTX64.efi from that dir. Best method would be to simply extract the iso to a FAT32 usb pendrive and extract this file and set it up inside that pendrive. You can boot this pendrive instead of using iso, (which is slower)

My boot program safely replaces those and uses LBA. It also avoids having to compile all those tools that do automated cut&pasting of boot sector bits and which also have limitations of their own.


Does this mean we can say good bye to GenBootSector and BootSectImage tools?

So, I got DUET to boot from a GPT FAT partition, but I have nothing to boot. Right now, I'm trying Linux and ELILO, still with no success. I wonder if I could replace GRUB with this thing, eliminating another step of the boot process.


I am able to boot linux x86_64 using grub2 (1.99~rc2)in edk2_x64.

#47
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
@migle: Your bootsector works perfectly (chainloaded from syslinux chain.c32 module) . I followed the instructions in the INSTALL file. I have not yet tried with Gpt.S though. I don't plan to replace a proper bios bootloader with duet alone. In case duet linux boot fails, i should have a proper bios bootloader to boot any OS. I plan to add these bootsectors in my EFI_DUET git repo if you have no objections (compiled binaries alone). I will try compiling duet with fsvariable to check whether it works with efivar.bin in the partition and whether the kernel panic still occurs.

#48
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal

@migle: Your bootsector works perfectly (chainloaded from syslinux chain.c32 module) . I followed the instructions in the INSTALL file. I have not yet tried with Gpt.S though.

Glad to hear!
Gpt.S will work too, as all my BootDuet.S requires is that Gps.S passes it the BIOS drive number of the boot drive in DL, as is standard, and Gpt.S does that.
I didn't try it though, as I also didn't try 64-bit LBA (I don't have a >2TB disk), but it's a safe assumption that it will work.

I don't plan to replace a proper bios bootloader with duet alone. In case duet linux boot fails, i should have a proper bios bootloader to boot any OS.

Oh, but I think it would be a good idea. I can't boot anything yet and already think that this thing is a million times better than GRUB. It's extensible, has a powerful shell, there's the disk partitioning and formating tools from Microsoft. This is the ideal pre-boot and recovery environment. It will make people throw their old MS-DOS pen drives away (which are no longer useful for recovering anything).

This could be useful for many years, particularly as EFI becomes widespread and people may need it to keep older hardware working. Credits to Intel that made this available.

Someone must add an ISO 9660 and UDF driver to this thing...
If this becomes more generally available, there will be an explosion of new tools for rescue situations.

I plan to add these bootsectors in my EFI_DUET git repo if you have no objections (compiled binaries alone).

It's too late for objections, you already got it under GPL!
Seriously, it's better if people can get everything they need from a single repository, so please do.
You may consider including the source as well. Even though you can't change it, someone else might need to.
Otherwise, include a note somewhere indicating where people can get the source from.

I will try compiling duet with fsvariable to check whether it works with efivar.bin in the partition and whether the kernel panic still occurs.

I don't think the boot sector program has any part in that, so I wouldn't expect that to work.

But maybe we have to arrange that to work as well, that is a very needed feature, otherwise there's no way to have persistent boot options.

#49
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux

Someone must add an ISO 9660 and UDF driver to this thing...


You have got it here http://www.virtualbo...oxPkg/VBoxFsDxe (don't know about UDF). But it doesn't compile with gcc, maybe Visual Studio might work. You should be familiar with how edk2 buildsystem works to compile this. See https://github.com/s...ompile_setup.sh on how it works.

I added FSVariable containing Efildr files in EFI_DUET repo https://github.com/s...Efildr/EDK2_X64 in case you want to test it. I also updated the normal Efildr20 and memdisk images. Linux kernel gives a panic message but continues booting with FSVariable (there are no files in /sys/firmware/efi/vars though).

But maybe we have to arrange that to work as well, that is a very needed feature, otherwise there's no way to have persistent boot options.


Yes, there is no way to make boot settings persistant because of this FSVariable bug. Tianocore devs seems to be in no hurry to check this, they concentrate more on OVMF than DUET.

#50
nnobody

nnobody

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Russia
migle:

I installed BootDuet/bd32.bin in EFI partition's FAT32 bootsector, in MBR - Gpt.com from Tianocore/Duet.
Gpt executes BootDuet, but BootDuet halts after int13 in first call of read function (called from fread, which is called from readroot). Return code from int13 is 0x01 (in AH).
Arguments to read function - ecx: 0x02, eax: 0x2800 (points to LFN entry of Efildr20), edi: 0x8000.
On MBR partitioned drive with Mbr.com from Duet and FAT32 primary partition BootDuet starts efildr20 as expected.
i.e. the same behaviour as bs32.bin from Duet (which prints BError! on GPT drive and halts).
I tried all of it on WMware virtual machine.
May be the problem with Gpt.com, and not with bootsector code?
I can produce more specific debug output if needed.



#51
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal

migle:

I installed BootDuet/bd32.bin in EFI partition's FAT32 bootsector, in MBR - Gpt.com from Tianocore/Duet.
Gpt executes BootDuet, but BootDuet halts after int13 in first call of read function (called from fread, which is called from readroot). Return code from int13 is 0x01 (in AH).
Arguments to read function - ecx: 0x02, eax: 0x2800 (points to LFN entry of Efildr20), edi: 0x8000.
On MBR partitioned drive with Mbr.com from Duet and FAT32 primary partition BootDuet starts efildr20 as expected.
i.e. the same behaviour as bs32.bin from Duet (which prints BError! on GPT drive and halts).
I tried all of it on WMware virtual machine.
May be the problem with Gpt.com, and not with bootsector code?
I can produce more specific debug output if needed.


I'm amazed by the amount of debug info you already got, however, I'm still in the dark. The arguments of the read function are not supposed to be what you said. They're supposed to be: EDX:EAX LBA address of the sector to read (which will be the first sector of the root directory), ECX number of sectors to read (2 sounds fine, your FAT32 file system has 1024 byte clusters, right?), ES:EDI = 0000:8000, right. Assuming EAX is right, and EDX is zero, can you confirm that the LBA of the first sector of your root directory is 0x2800 (absolute, from the beginning of the disk)?

But if CX is 2, then that can't be the first call of the read function. It would have to be the second. In the first call of the read function, a single FAT sector would be read and CX would be 1. So, I assumed that if CX is 2, that's after reading FAT and it's the read of the first sector of root.

That's all supposed to be right, I'll try to make more intelligent questions:
- Do you happen to know what that AH=01 return code means? (My old books are not at hand)
- Are you reading from a hard disk?
- Can you determine if the BIOS drive number is in DL at the beginning of BootDuet (supposedly passed by Gpt)?
- Is that BIOS drive number over 0x80 ? (0x00 is the first floppy, A:, 0x01 is B:, 0x80 is the first hard drive, C:, etc) I wonder if VMWare's BIOS doesn't support LBA on a floppy, quite possible.

Maybe I can try the same thing here, but I must use VirtualBox.

A more obvious question, just to rule that out, is the hidden sectors field of your FAT32 boot sector correct?

Also, you can use the email address on the source file for this subject. This thread is already long enough and is not about my tiny boot program.

EDIT: Ok, I know what the problem is. Gpt.com doesn't leave the drive number on DL as I thought it did. So, when I try to read from the unknown value it passes on DL (maybe 0), BIOS says invalid command.
The reason Gpt.com doesn't leave the drive number in DL is that its ReadBlocks function begins and ends with push all/ pop all (I saw it putting the drive number on DL, but the pop all that follows destroys that).

What would be a good solution for this? Well, we could change Gpt.com to leave the drive number in DL (it has room for many more bytes of code). Gpt.com knows the drive number from a value it has hardcoded (the partition to boot from is also hard coded). For now, I think the best solution is to use a compilation option on BootDuet for using the drive number hard coded on the BPB. I will add that in a minute.

A better solution would be to change Gpt.com entirely so that the boot drive and partition don't have to be hard coded and then also make it leave the drive number in DL.

I will commit the minimal change to BootDuet to github in an hour or so.

#52
nnobody

nnobody

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Russia
1. I can't find calculation of root directory sector, but at 0x2800 is directory entry,
first 32 byte is LFN entry and after it 32 byte FAT entry of EFILDR20 (the only file on filesystem,
there is no dirs except of root)

2. Does BootDuet read first FAT sector? It seems that first sector read by MBR record
that places it to 0x7c00, from this addres BootDuet gets FAT parametrs, isn't it?

3. answers for inteligent questions:
a. According to _ttp://www.delorie.com/djgpp/doc/rbinter/id/14/7.html, 0x01 in AH means invalid function or its parameters

b. Yes, it's SCSI hard drive (tried to change type to IDE with no luck).
In VirtualBox(on windows host) it's all the same, no matter of controller type

c,d. I tried to movb bDrive,%al and call printn, just before int13, output is 0.
movb %dl,%al in main, after movb %dl,main_bDrive(%bp), output is 0.
seems Gpt.com do not not pass disk index, as it done by Mbr.com
I hardcoded $0x80(passed by Mbr.com on same machine) in main instead of %dl and int13 work ok, but I get Missing EFILDR20. I need further investigation...

#53
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal

1. I can't find calculation of root directory sector, but at 0x2800 is directory entry,
first 32 byte is LFN entry and after it 32 byte FAT entry of EFILDR20 (the only file on filesystem,
there is no dirs except of root)


On FAT32, the root directory is read like any other file, through the fread function. The first cluster of the root directory is in the EBPB.

2. Does BootDuet read first FAT sector? It seems that first sector read by MBR record
that places it to 0x7c00, from this addres BootDuet gets FAT parametrs, isn't it?


I'll correct myself: BootDuet will only need to read the first sector of FAT to find out if there is a "next cluster" in the root directory.
The first cluster number of the root directory is in the BPB and is usually 2, the first cluster in the file system. The relative sector number is a direct function of the cluster number, such as:

LBA = hidden-sectors + reserved-sectors + n-FATs*sectors-per-FAT + (cluster - 2) * (sectors-per-cluster)

The first FAT sector will be read afterwards, to determine if there is a "next cluster" to cluster 2.
I don't expect to have a bug in that logic in any of the FAT versions, otherwise it would be unlikely that I could ever read the entire EFILDR file.

3. answers for inteligent questions:
a. According to _ttp://www.delorie.com/djgpp/doc/rbinter/id/14/7.html, 0x01 in AH means invalid function or its parameters

b. Yes, it's SCSI hard drive (tried to change type to IDE with no luck).
In VirtualBox(on windows host) it's all the same, no matter of controller type

c,d. I tried to movb bDrive,%al and call printn, just before int13, output is 0.
movb %dl,%al in main, after movb %dl,main_bDrive(%bp), output is 0.
seems Gpt.com do not not pass disk index, as it done by Mbr.com
I hardcoded $0x80(passed by Mbr.com on same machine) in main instead of %dl and int13 work ok, but I get Missing EFILDR20. I need further investigation...


Ok. You can use my new version that uses the drive number hard coded on the BPB (it just skips that line).
Now, missing EFILDR20... I also don't expect the logic of the scanning of the root directory to have any bug.
Use more printns, step by step. Check how your root directory starts. You can use the print function to print the content of the root directory buffer, which is at 0000:8000.

What format tool did you use? Do you want me to look at the data you have on the BPB? (tomorrow...)

EDIT: back to:

LBA = hidden-sectors + reserved-sectors + n-FATs*sectors-per-FAT + (cluster - 2) * (sectors-per-cluster)

This is computed by steps, sFat (first LBA of first FAT) = hidden-sectors + reserved-sectors, you can confirm with printn; sData (first LBA of data area) = sFat + n-Fats*sectors-per-FAT, again printn; the root directory is typically cluster 2 and starts at sData (one cluster). If you look at your FAT, you'll see that typically, at position 0x08 you'll see the end-of-file marker, meaning that the root directory only takes one cluster.
If, at the beginning of scanroot, you print the first 64 bytes of 0000:8000, you should see what you have at your sector sData. The LFN entry will be ignored by scanroot.

If you got at "Missing EFILDR20", I can't think of anything that could be wrong (other than a bug, or the file really not being there, or the short file name not being what I would expect, note that I expect the short file name entry to be upper case even if the long file name entry is not).

#54
nnobody

nnobody

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Russia
I think I can solve missing EFILDR by myself, just stuck on int13, but it's behind now. I'll report back later
seems that problem in LFN or something like that
I use diskpart from WinPE3.0 for partitioning and formatting

#55
nnobody

nnobody

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Russia
setup.1 is in #if !defined(DEBUG) - #endif clause, so DEBUG version of BootDuet don't jmp to Efildr
Just recompiled BootDuet without -DDEBUG and it works great now (with hardcoded drive number)
Also works with VMware SCSI and VirtualBox AHCI hard drives

#56
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal

setup.1 is in #if !defined(DEBUG) - #endif clause, so DEBUG version of BootDuet don't jmp to Efildr
Just recompiled BootDuet without -DDEBUG and it works great now (with hardcoded drive number)
Also works with VMware SCSI and VirtualBox AHCI hard drives


Good to hear. No other changes needed on what's now on github.
Sorry about the -DDEBUG inconvenience, you see, the printn function takes up a few bytes, the far jump section is removed to save space for that (when debugging, I want to print something and see it, not jump into EFILDR).

Anyway, booting works, but Duet itself still needs changes to be a Users' UEFI emulation instead of a Developer's UEFI emulation.... and I've still not gone past compiling Duet...

#57
nnobody

nnobody

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Russia
1. I found what is wrong with Gpt - it saves dl to 7C00:01B6 after relocation to 0600:0000 occurs and later loads bootsector to 7C00:0000, and not even try to pass dl to bootsector. If I save dl to 0600:01B6 and restore it before jump to bootsector code all works without hardcoded bDrive.
2. I can't produce working gpt.com with gcc(compiles without erros, but binary totaly corrupted), only ntddk(with ml/link16) build works, so I can only make patch for .asm and share binary.

BTW, I've checked Mbr code and algorithm there is the same, can't figure why it works from stock

Attached Files

  • Attached File  gpt.zip   1.44KB   7 downloads


#58
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal

1. I found what is wrong with Gpt - it saves dl to 7C00:01B6 after relocation to 0600:0000 occurs and later loads bootsector to 7C00:0000, and not even try to pass dl to bootsector. If I save dl to 0600:01B6 and restore it before jump to bootsector code all works without hardcoded bDrive.


I don't think that's due to error. They save DL to 0x7db6, but they always keep the frame pointer BP at 7c00. Accessing that variable through the frame pointer allows them to save one byte on each instruction that references that address.
They work at Intel. They don't pass the drive number in DL because their spec doesn't say they should. I was the one who mistakenly assumed they did, and didn't see the POPA instruction at the end of ReadBlocks that eliminates that from DL.

2. I can't produce working gpt.com with gcc(compiles without erros, but binary totaly corrupted), only ntddk(with ml/link16) build works, so I can only make patch for .asm and share binary.

BTW, I've checked Mbr code and algorithm there is the same, can't figure why it works from stock


I think it's a matter of specification. It became standard practice for MBR programs to pass DL, see http://www.dewassoc....boot_record.htm. However, the MBR program for a GPT partition table, what specification specifies its behaviour? It's neither something from the old BIOS world nor something from the UEFI world.
They wrote the program they needed and they didn't foresee what we are trying to do with it.

We could re-write Gpt.com from scratch. It's easier to write than this one, I had a very hard time getting the FAT code to fit so few bytes. I am also bothered about the boot partition number being hard-coded. Maybe it would be better that it always booted from the ESP partition?
It could also do a fake MBR partition entry in memory as some other boot managers do, so as to pass SI pointing to that fake entry, thus allowing the VBR program to know where its partition is located.

#59
balta2ar

balta2ar

    InsanelyMac Protégé

  • Members
  • Pip
  • 1 posts
Hello, everyone!

I'm owner of EFI-based ASUS P8P67 Deluxe. I was experiencing some difficulties during OS installation, so let me share my experience with you. I wanted to install Windows 7 64-bit and ArchLinux x64 on my new PC. Of course, in EFI mode. That's where the problems began.

My PC configuration is:

ASUS P8P67 Deluxe
	   OCZ Vertex 3 120 Gb
	   Intel Core i5-2500K
	   NVIDIA GTX 580 Gainward
	   16Gb RAM

I didn't have a CD/DVD drive so I had to prepare a bootable copy of Windows on a USB pen. I tried different programs but finally I ended up with UltraISO. However, when I tried to boot widows from USB, installer refused to accept my partitions. Many encountered this message when windows says that disk is GPT-formatted. That means that installer was run not in EFI mode.

After that I tried to run windows installer in EFI by all means I could think about. Firmware of my motherboard does not seem to contain any built-in EFI shell, nor does it allow to "Boot from file". After some googling I found out that copying a shell_full.efi from EDK-1.06 (later I also tried EDK2 and it also worked) in /efi/boot/bootx64.efi helps: usb stick obtained UEFI prefix in boot menu in BIOS interface and looked like "UEFI: Kingston II". When I tried to boot from it, I got into shell.

In parallel, I also tried to install ArchLinux from another USB stick. I burned latest archboot-2011.05 and followed the standart installation procedure. At the end I choose grub2-efi-x64. However, I didn't see a way to boot it automatically. The only way I could boot grub2 is from EFI shell. That was the first glimmer of hope. Unfortunately, I was dependent on USB srick and couldn't boot anything without it. More googling again and I resolved the problem by puttin the shell to <EFI_SYSTEM_PARTITION>/shellx64.efi. After that "Launch EFI shell" option in BIOS dropped me into shell. USB was not necessary anymore. I could boot ArchLinux from harddisk with lots of hand actions.

I tried to launch all the efi files I could found on the windows 7 usb. Launching bootmgr.efi, memtest.efi always resulted in error sayng that the specified binary is not a recognized command or batch or a file. cdboot.efi and cdboot_noprompt.efi seemed to have started loading, but few seconds later it crashed and I was dropped back to the shell. So I couldn't install windows in EFI mode, not even run the installation. An interesting note here is that cdboot.efi and cdboot_noprompt.efi do not autocomplete in EFI shell. All other efi files do.

Yesterday I borrowed an external USB DVD ROM drive in hope to install windows from it. However, the drive didn't contain UEFI prefix in the BIOS boot menu and result was the same: windows installer complained about GPT. I also noticed one thing: when I connected my Cowon J3 audio player to USB in order to charge it, it also appeared in BIOS and it contained UEFI prefix. That was weird, because I didn't copy any of efi files to the player. I didn't try to boot from it, though.

Finally, I managed to install Windows 7 in EFI mode by accident. Unintentionaly, I left USB DVD drive plugged in and booted into the EFI shell. My USB stick with Windows 7 was also plugged in. I was fooling around on the available drives and tried to launch EFI files I collected from different sources. During that process I run cdboot.efi from USB Windows 7 again and... surprise, surprise, installation started! It didn't drop back to the shell as previously. I also heard DVD disk spinning in the USB DVD driver! Few seconds later Windows accepted my GPT disk and I continued with installation. I went away from the PC for about ten-fifteen minutes but when I got back, Windows was already installed! How amazingly fast! It didn't recognize some of my hardware including network card, though. I rebooted and discovered "Windows boot manager" in BIOS boot menu. From now on I could boot Windows without a problem.

Let me summarize my experience in form of current problems and questions:

1. [Why can't I/How do I] boot Windows DVD in UEFI mode without all this magic with same USB stick? I saw on youtube people running the same Windows 7 in UEFI from DVD without a problem. They got UEFI: DVD in Boot menu. I don't. Why?

2. What does Windows installer do so special that "Windows boot manager" appears in the boot menu? How do I do the same for grub2? How do I add it to the BIOS Boot menu? I tried to reproduce folder structure for grub on ESP: I copied contents of grub folder to /efi/grub/boot on the analogy to /efi/microsoft/boot/ folder. It didn't work - grub didn't appear in BIOS Boot menu.

3. Is there any document describing ASUS P8P67 specific EFI behaviour? What conditions should be met in order to boot device in UEFI mode? FAT32 Partition type, certain files availble, partition flags?

4. Note: I tried to run rEFIt EFI files in the shell but failed: 'refit.efi' is not recognized as an internal or external command, operable program, or batch file.

5. Note: I get kernel panic when I reboot ArchLinux: http://img.flashtux....60x584317ed.jpg. Shutdown is fine, though. That's very unpleasant because I cannot reboot my PC remotely - I need to push Reset button in order to reboot the machine.

6. Note: My primary harddisk OCZ Vertex 3 SSD does not have UEFI prefix in Boot menu. Only USB sticks obtain such prefix provided they contain FAT32 partition.

7. Note: I didn't manage to run cdboot.efi from Windows DVD. When I booted into EFI shell, DVD wasn't mapped to some drive name like fs1: or something. I had to manually do "map fs1 blkA" - blkA was printed in the output of map command in the EFI shell. This mapping, however, didn't help: I changed drive to fs1 but 'ls' gave me an error. I coudn't browse the Windows DVD filesystem.

8. Note: SATA mode is set to AHCI in BIOS.

I really want to make this post useful to someone. I'm ready to provide all the necessary logs and infos to help with investigation of mentioned problems. Bellow I post all the information I collected and which I belive might be of any interest and use.

Info:
lshw output:
http://paste.pocoo.org/show/394135/

gdisk output:
Command (? for help): p
	   Disk /dev/sdc: 234441648 sectors, 111.8 GiB
	   Logical sector size: 512 bytes
	   Disk identifier (GUID): D3A460D9-0C5C-4121-8838-E63ED027269E
	   Partition table holds up to 128 entries
	   First usable sector is 34, last usable sector is 234441614
	   Partitions will be aligned on 2048-sector boundaries
	   Total free space is 2925 sectors (1.4 MiB)
	   
	   Number  Start (sector)	End (sector)  Size	   Code  Name
		  1			2048		  411647   200.0 MiB   EF00
		  2		  411648		  432127   10.0 MiB	EF02
		  3		  821248		62261247   29.3 GiB	0700
		  4		62261248	   129845247   32.2 GiB	0700
		  5	   129845248	   148277247   8.8 GiB	 0700
		  6	   150325248	   150734847   200.0 MiB   0700
		  7	   148277248	   150325247   1000.0 MiB  8200
		  8	   150734848	   234440703   39.9 GiB	0700
		  9		  432128		  821247   190.0 MiB   0700
	   
	   Command (? for help): i
	   Partition number (1-9): 1
	   Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
	   Partition unique GUID: 58471815-D914-4133-894A-7E80927727F6
	   First sector: 2048 (at 1024.0 KiB)
	   Last sector: 411647 (at 201.0 MiB)
	   Partition size: 409600 sectors (200.0 MiB)
	   Attribute flags: 0000000000000000
	   Partition name: ''

EFI shell commands output:
dh.txt - http://paste.pocoo.org/show/394158/
dmpstore.txt - http://paste.pocoo.org/show/394159/
guid.txt - http://paste.pocoo.org/show/394160/
help.txt - http://paste.pocoo.org/show/394161/
map.txt - http://paste.pocoo.org/show/394162/
pci.txt - http://paste.pocoo.org/show/394163/
run.txt - http://paste.pocoo.org/show/394164/
ver.txt - http://paste.pocoo.org/show/394165/
vol.txt - http://paste.pocoo.org/show/394166/


EDIT: I duplicated post here: https://bbs.archlinu...=938691#p938691
EDIT: fixed typos and added 7.
EDIT: I've just found this: https://help.ubuntu....i... as default. This seems to be a solution for the problem #2. I will check it by evening at home.

#60
nnobody

nnobody

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Russia
migle:

Anyway thanks for your work, now I can boot Windows from GPT drive without USB flash drive.







1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy