Jump to content

Linux and Windows UEFI boot using Tianocore DUET firmware


  • Please log in to reply
153 replies to this topic

#101
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
I moved the first post to https://gitorious.or...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.or..._duet_installer and the forum link to https://gitorious.or...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.

#102
Laqk

Laqk

    InsanelyMac Protégé

  • Members
  • Pip
  • 18 posts
@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...

#103
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
I have created a wiki at gitorious https://gitorious.or...ilds/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.

#104
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

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.

#105
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

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.

#106
Laqk

Laqk

    InsanelyMac Protégé

  • Members
  • Pip
  • 18 posts
@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.

#107
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI
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.)

#108
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

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

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).

#109
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

  • Members
  • PipPip
  • 56 posts
  • Gender:Male
  • Location:Indiana, USA
  • Interests:Arch Linux
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...6/msg00026.html is the link to the discussion between srs5694 and parted devs.

#110
srs5694

srs5694

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 541 posts
  • Gender:Male
  • Location:Woonsocket, RI

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. ;)

#111
Keshav Amburay

Keshav Amburay

    InsanelyMac Protégé

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

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.or...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.

#112
spotter

spotter

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
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.

#113
Totony

Totony

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
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.

#114
migle

migle

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Location:Alcochete, Portugal
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...)

#115
Totony

Totony

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
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 ?

#116
migle

migle

    InsanelyMac Protégé

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

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!

#117
Totony

Totony

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
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.

#118
migle

migle

    InsanelyMac Protégé

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

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.

#119
Totony

Totony

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
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 :)

#120
migle

migle

    InsanelyMac Protégé

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

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?





0 user(s) are reading this topic

0 members, 0 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