Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About migle

  • Rank
    InsanelyMac Protégé

Profile Information

  • Location
    Alcochete, Portugal
  1. Maybe that's because TianoCore came from Intel. None of us here can get much inside the EFI emulation code, that would be a question for the TianoCore people. You're better off trying one of those friendlier bootloaders, such as Clover. And note that you only need UEFI to boot Windows, do you really want to do that? PS: I no longer use this solution, as I stopped using Windows at home.
  2. No, read the INSTALL file. The *_64.bin files are for 64-bit Logical Block Addressing, that's when the hard disk has more blocks than can be addressed with 32 bits (that's 2^32 blocks or 3TB) and still only when your ESP partition lies beyond the first 3TB. You can, of course, boot using only the hard disk. You have GRUB 2 already correctly installed, you now only need to install BootDuet (and DUET, which is the EFILDR20 file) to your ESP and then chainload the ESP from GRUB. No, that's mainly for using without a smart boot loader, and GRUB is smart and well behaved. That's the preferrable setup. You don't need to copy and windows *.EFI files --- Windows already installed then into the EFI System Partition. You need only: Copy the EFILDR20 file to the EFI System Partition (there should be only one in the disk) Install BootDuet to the same ESP, using the dd command as explained in the INSTALL file (possibly also overwritting the hidden sectors field of the Boot Parameter Block of that partition as well, also as explained in the INSTALL file). Add an entry to GRUB menu to chainload BootDuet which is on the ESP. If you don't understand these steps well, then you should probably use the materials on rodsbooks.com, which relieve you from some of these details, but with which I cannot help you. Greetings,
  3. Well, you should forget those old posts and follow what's on gitorious and github. I never used those install scripts, so I don't know what is wrong. There is very little to do in preparing a bootable USB drive with DUET. You need only: Partition the USB drive in GPT. Pay attention to the initial sector of your ESP partition, take note of it, let's assume it is 1234. Format that partition in FAT32, filling in the "hidden sectors" field of the BPB, with a command such as: mkfs.msdos -F 32 -h 1234 /dev/sdb1 Install the boot sector program, BootDuet, with dd if=bd32.bin of=/dev/sdb1 bs=1 skip=90 seek=90 count=420 (or follow the instructions on the INSTALL file of BootDuet) Copy DUET, that is, the EFILDR20 file to the root directory of the partition you just created. Now it should work, you can additionally copy any *.EFI files you want, such as EFI Shell, etc. If you can follow these instructions yourself, all you need is BootDuet, which is on https://github.com/migle/BootDuet. Otherwise, you have a lot of info on gitorious and github, but I agree, there are so many options that it is confusing. For instance, Rod Smith (the author of gdisk), wrote an install script which does what I said, which you can find here, https://github.com/the-ridikulus-rat/duet-install. I no longer keep bootable USB drives with DUET... I once found it appealing, having the EFI shell and all, providing me some error recovery tools... But it is so limited, compared to a bootable USB drive with a free OS, that I'm no longer willing to waste time setting it up. Greetings,
  4. I guess you edited this last post. My main motivation for replying was that you seemed to have understood that you had to have a hybrid MBR disk for Linux to boot without using EFI, and that is not the case. To be clear: Linux or FreeBSD boot just fine from an GPT-only disk without having EFI firmware. Actually, this is expected, GPT is a very simple partition table layout, easy to read from a boot-loader without any help from EFI firmware, or 32 or 64-bit address space. These OSes don't even have to care, because once the kernel is loaded into memory (e.g. by GRUB), everything is already solved. Only Windows requires the boot disk to be MBR when using the old BIOS, they were probably just lazy to write a couple of pages of assembly code. You can't have Linux booting faster through DUET than without it. DUET alone takes longer to boot than Linux (or almost). Not exactly. There shouldn't be any EFIVAR.BIN file. This file is only created by that module (which is actually called FsVariable, not EfiVar) after something is saved on "NVRAM". Yes. I use GRUB2, which is installed in a 64kB partition with code EF02. I have options for booting Linux and FreeBSD directly without going through DUET (and this is a GPT-only disk). Then, I have one option for chainloading the ESP which boots DUET. I don't think there is any "hardcoded" behaviour. If it boots directly, it is because it only finds one boot option. Access to older versions is easy at gitorious. You'd have to go there to contact Keshav too, I don't think he reads this any more. However, you are a bit mistaken as to what your best option is. Your quote from Keshav is old. It says he is able to boot Linux, it doesn't say it does so directly, without choosing an option... Also, it was only latter that he realised that he had to leave the FsVariable module out, so that Windows worked properly. I think you already understand that you can do everything without going through DUET and use it only for Windows. Try it and you'll see that that's your best option. Why load a several hundred kB firmware emulation, which is totally useless after Linux boots? If the only use for the firmware is to boot the OS... Greetings,
  5. Well, there should be, but there isn't right now. Those boot options and your default choice, in a real UEFI, would be recorded in NVRAM. In Duet, there is a module to emulate an NVRAM, which is EfiVar. Your boot options would be recorded by this EfiVar module in a file called EFIVAR.BIN in the root directory of your ESP. It happens that people (Keshav) have verified that when they compile this module in Duet, Windows does not work so well (or something like that, don't remember exactly). So, the preliminary solution, I think still is to eliminate this module when compiling Duet. Which means you don't get this EFIVAR.BIN file in your ESP. Furthermore, I wrote the boot loader, BootDuet, which is responsible for loading EFILDR and EFIVAR.BIN into memory and jumping into EFILDR, and I never had the chance to see if EFIVAR.BIN was being loaded correctly (and its address passed correctly to EFILDR). So, how have we been getting by? First, you don't need to boot Linux through UEFI, it boots from a GPT disk using a regular BIOS just fine. Actually, it's better not to use UEFI, because Duet takes a lot of time to boot. You actually only need DUET for booting Windows. And if that is your only EFI boot option, DUET will just boot it without asking. So, myself, I have the regular GRUB installed, which boots from a GPT disk just fine. I have several options for booting Linux and FreeBSD, and then I have a single option to boot DUET, which boots Windows. From a practical point of view, this works just fine. If you are looking for the satisfaction of total UEFI emulation, then you know were to start: compile an EFILDR which has the EfiVar module in it, then check if anything gets stored in EFIVAR.BIN, and then we'll see if it gets loaded properly. But really, there are more interesting things in life... Greetings,
  6. I can't. Anyway, I think your diagnostic is correct, that duet does not know your raid controller. Is there no chance of having it behave like an AHCI controller? The EFILDR20 file is a bundle. It has the basic UEFI functionality and then it has many packages. There is nothing in DUET to support areca controllers. You see, DUET would be the toolkit to help areca developers run and debug their firmware. I think understand that some packages that skodabenz has assembled come from VirtualBox, but I don't think there is anything in VirtualBox about areca controllers. You would have to find such code and then compile it and assemble it into the EFILDR image. I don't think you would be lucky enough to find such code. Anyway, the subversion repository for the EFI Developer's Toolkit is http://edk2.svn.sourceforge.net/svnroot/edk2/branches/UDK2010, otherwise search for tianocore. The only viable option I see is try flashing that BIOS onto your areca card (provided you can go back to the BIOS you currently have) and hope that it magically works (maybe it emulates an AHCI controller). If it doesn't work, I think your chances are not very good. If you could find EFI code to support areca, you would then find help for compiling it at http://gitorious.org/tianocore_uefi_duet_builds. That's all I can say.
  7. Well you give such visible credit and everything, thanks... Just tell me if someone changes it (maybe corrects a bug, supports a different case). About that "file not found", if the problem persists, maybe seek help for that on gitorious.
  8. Thanks, it's nice to know about that cloverefiboot project. They're using the BootDuet.S program I wrote and probably also read a lot from this topic here. I thought I had only 5 or 6 users, it would have been a day of work per user, or maybe more. As to booting OSX, I have no space left for that on the disk (as you can see above).
  9. Hi, You must be almost there. There is something you need to fix that (see below, I saw it last). Hmmm. if you read rodsbooks, you should know that there still exists an MBR on GPT-partitioned disks, called the protective MBR. However, GRUB should not be installed to the MBR. As is said on section 3.4 of GRUB's manual, you should create a partition for GRUB, a small one (say, 64KiB) is enough. That partition should have type EF02. When you install grub, it will find this partition and install itself partly on the MBR and what doesn't fit in the MBR will go to that partition. On MBR-only disks, grub used to use the sectors just after the MBR assuming they were free, this was less safe. But this is not the reason why you can't boot DUET. Read on... Yes, it is right. Moreover, you already know for sure that BootDuet was loaded and executed properly and that it did its job right, which is loading and executing EFILDR20. Because you saw "ABCD" and all those funky welcome messages, it must have loaded properly (there is no being half-correct here). So, why does DUET hang? There is not much else to check, but I have a couple of suggestions. I think Keshav says that's the one you use in any case. However, there is a misconception there: your disk is connected via a SATA cable but BIOS may be faking it as an IDE disk. In the BIOS setup, you have that "IDE compatible" or "AHCI" setting. AHCI is better and faster, however, if you installed Windows in "IDE compatible" then you have to stick to it. But that is the setting that determines that from a software point of view (in early OS loading stages) your disk looks like IDE or SATA. This could be one reason for you hanging, yes. You could try each of the settings in turn with each of the versions of EFILDR20. That's four possibilities to try out. However, you should only bother to do so, after: (read on) No, it's fine. You can copy EFI tools that you may like, such as the EFI shell, but that's for latter. Focus on booting Windows through DUET first. I'd have to check that on our 3-million entry Hardware Compatibility List, but that means I'd have to go across the campus to our Q-A department. This was a joke. It must have been done, yes, otherwise you'd never have seen "ABCD". That was all fine. Go back to BootDuet and forget syslinux, syslinux is more trouble than BootDuet. Now, the first thing to try: Even though you read rodsbooks, you still used gnu parted, and not Rod's gdisk. His' is much better. So, first, stop using gnu parted. What you call your BOOT partition, that 500 MiB FAT32, is what is called your EFI System Partition (ESP). Your ESP should be marked with a special code in the GPT, which is EF00. Gnu parted might have used another code. If it did, I don't remember, but maybe DUET does not find your ESP and maybe that's why it hangs. Here is the partition table on my laptop (output of gdisk): 1 2048 134219775 64.0 GiB 0700 vista 2 134219776 136316927 1024.0 MiB 8301 gentoo-root 3 136316928 153094143 8.0 GiB 8301 gentoo-usr 4 153094144 157288447 2.0 GiB 8301 gentoo-var 5 157288448 159385599 1024.0 MiB 8301 gentoo-portage 6 159385600 167774207 4.0 GiB 8301 gentoo-distfiles 7 167774208 192940031 12.0 GiB 8301 linux-opt 8 192940032 201328639 4.0 GiB 8200 linux-swap 9 201328640 218105855 8.0 GiB 8301 linux-tmp 10 218105856 268437503 24.0 GiB 8301 linux-home 11 335546368 343934975 4.0 GiB A502 freebsd-swap 12 343934976 352323583 4.0 GiB A503 ufs-tmp 13 352323584 360712191 4.0 GiB A503 ufs-home 14 360712192 364906495 2.0 GiB A503 freebsd-distfiles 15 364906496 369100799 2.0 GiB A503 freebsd-ports 16 369100800 377489407 4.0 GiB A503 freebsd-local 17 377489408 385878015 4.0 GiB A503 freebsd-usr 18 385878016 387975167 1024.0 MiB A503 freebsd-root 19 387975168 390072319 1024.0 MiB A503 freebsd-var 20 390072320 390334463 128.0 MiB EF00 duet 21 390334464 390596607 128.0 MiB 0C01 msr 22 390721536 390721663 64.0 KiB EF02 grub 23 390721664 390721791 64.0 KiB A501 freebsd-boot The following are relevante: - My "duet" partition is my ESP and has type EF00 (there should only be one on the disk). The files for booting Windows go in there. (the SOMETHNG.EFI stuff) - GRUB is partly on the protective MBR and partly on my "grub" partition with type EF02. - "msr" was created by Windows (he likes it there, even though its useless, I left 128MiB prepared for Windows to be able to create it) - BTW, freebsd's gptboot code goes on the "freebsd-boot" partition with type A501 and "freebsd-root" has the "bootable" flag set (set by FreeBSD's own tool gpart) If its not the EF00 type for your "BOOT" that it's missing, then it must be a matter of "IDE compatible" vs. "AHCI" or try different versions of EFILDR20.
  10. 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
  11. 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?
  12. 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. 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. 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.
  13. 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. 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. 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!
  14. Hi, I couldn't spot what's wrong, but I can tell you what isn't wrong. I also chainload with GRUB2. boot flag isn't needed, you're using grub. 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 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...)
  15. Hmm. Well, Vista installed fine with a FAT16 ESP. Sometimes, people overspecify things with no good reason. In the end, the firmware will have to support all three types even if just for removable media. That is to say, specifying that, will not relieve the firmware from dealing with the complexity of the three types of FAT. Also, an implementation which followed that paragraph strictly would have to have additional complexity for deciding which media is removable and limiting the types of FAT that would be recognized. But, that quote is reason enough for "pushing" FAT32 to people by default. Hmm..... Following that link, what caught my attention was the license for the specifcation... It brings to mind that FAT32 now is a patented proprietary file system that has a specification which is available only to those who accept an agreement. Really. The only reason for that document being there is for people accepting the licence. Who needs that spec? Everyone knows how FAT32 works: it's just like FAT16 (unpatentable common knowledge) except for one or two minor differences. Just read it on Wikipedia. LFN where a more complex change. There's open source software for FAT32 for at least 15 years. I'm really sorry that digital camera manufacturers didn't get together and challenge Microsoft's claims legally. And who approved the UEFI spec fell into forcing the use of a proprietary file system... That's also a good reason for having FAT16 and 12 as an option. Thanks for looking it up in the UEFI spec.