Superhai Posted August 7, 2006 Share Posted August 7, 2006 hey superhai, both me and kiko tried out ur efildr and it just sits there and hangs for both our machines. Any ideas? Hmm, you have set your hd active? Is it just a black display or is something displayed? Anyway, here is the efildr file to replace on the efi floppy. This should work. floppy_efildr.rar Link to comment Share on other sites More sharing options...
Blackice Posted August 7, 2006 Share Posted August 7, 2006 what did you actually change on that EfiLdr? Is it just the same as we have, but with the shell removed? Link to comment Share on other sites More sharing options...
Superhai Posted August 7, 2006 Share Posted August 7, 2006 what did you actually change on that EfiLdr? Is it just the same as we have, but with the shell removed? Yes, and I am working on the exception handling to not to halt but skip and continue loading to see if it helps. Link to comment Share on other sites More sharing options...
Blackice Posted August 7, 2006 Share Posted August 7, 2006 ok, Superhai: that last EfiLdr you posted is good. No shell Screenshot So that was just a recompile without the shell, yes? In any case, try and come on IRC. Link to comment Share on other sites More sharing options...
mifki Posted August 8, 2006 Share Posted August 8, 2006 hey blackice, apparentely the kernel sources ahve been released, this is good news, very good news. Link to comment Share on other sites More sharing options...
sbeehre Posted August 8, 2006 Share Posted August 8, 2006 This is also quite interesting its a FAQ about the Platform Innovation Framework for EFI http://www.intel.com/technology/framework/qanda.htm#q1 Link to comment Share on other sites More sharing options...
Dr. Hurt Posted August 8, 2006 Share Posted August 8, 2006 I know that this might not be the best place for this post, but I heard that VMWare for mac will have a virtual EFI environment that can load OS X. I think that if that is true, then vmware has done our job for us. We can extract the virtual EFI included with the VMware and use it natively on our computer somehow. I know that extracting the virtual EFI from vmware might be impossible but this is just a thought I had. Please correct me if I am wrong. Link to comment Share on other sites More sharing options...
Urbz Posted August 8, 2006 Share Posted August 8, 2006 I know that this might not be the best place for this post, but I heard that VMWare for mac will have a virtual EFI environment that can load OS X. I think that if that is true, then vmware has done our job for us. We can extract the virtual EFI included with the VMware and use it natively on our computer somehow.I know that extracting the virtual EFI from vmware might be impossible but this is just a thought I had. Please correct me if I am wrong. You're right, and we'll take a look at it as soon as some kind of beta is available. Until then, we are currently working on booting tianocore because it is closer to the apple modules than anything else we have. Link to comment Share on other sites More sharing options...
james2mart Posted August 8, 2006 Share Posted August 8, 2006 With the 10.4.7 kernel release yesterday, apple also released some sources for EFI tools. You may want to take a look at those. Link to comment Share on other sites More sharing options...
Urbz Posted August 8, 2006 Share Posted August 8, 2006 With the 10.4.7 kernel release yesterday, apple also released some sources for EFI tools. You may want to take a look at those. thank you, i will look at that now. Link to comment Share on other sites More sharing options...
rogabean Posted August 10, 2006 Share Posted August 10, 2006 I've had a chance to review this release. I'm impressed with what you guys have done in my absence. I would like to state that from what I can tell though you are bumping into the same issue we ran into when trying to load Linux on either the sample implementation or TianoCore. If I had to take a guess (I haven't hooked on a debugger yet) I would most likely assume it's another case of ConSplitter / GraphicsConsole bugging out. We know from experience that the sample implementation of ConSplitter is incomplete. This doesn't mean it won't work however. The "Penguin Experiments", as I like to call them, resulted in the kernel loading but locking up instantly afterwards. It was believed this was a limitation of ConSplitter and not the EFI loader itself. Another theory was that the loader was trying to switch the processor into real mode and loading the kernel required the processor to remain in protected mode. At the time we were using the ELILO loader and adding "legacy-free" to the conf was a theory on how to overcome this, but it was never tested out real world. I am going to attempt to load up this environment on the physical machine as I did the initial release to see what differences there are between the QEMU test environment and the real machine, as well as run some test under parallels. Other tests to come include taking another go at ELILO to load the newly release Darwin source. Link to comment Share on other sites More sharing options...
munky Posted August 10, 2006 Share Posted August 10, 2006 best of luck rogabean, we're all rootin' for ya Link to comment Share on other sites More sharing options...
mifki Posted August 11, 2006 Share Posted August 11, 2006 Hey Urby , im sorry im not on irc atm (or wont be for most of the week) but can you get console.efi for us Thanks Kiko Link to comment Share on other sites More sharing options...
Urbz Posted August 11, 2006 Share Posted August 11, 2006 Hey everyone, I'd like to dedicate this thread to Boot.efi. I stumbled across some info while i was searching the wed for other purposes. this is the .efi responsible for booting the system and is a "blessed" file, which means this is where the efi environment looks to boot an os from. Boot.efi then goes on to boot Mac OS X. We are not sure if it is prohibiting us from booting mac (probably not: my iMac boots from it just fine. It is probably the modues which have to be loaded, where we have had little progress so far.). However, in heavily modifying boot.efi, or inspecting it very closely, we may be able to find dependencies: <i>why</i> it isn't working on our systems. For this reason, Boot.efi is essential. It can tell us a lot about which modules we need, and which we don't. What's controlled by the OS and what isn't. The original boot.efi (attached under that name in archive) did not work. It isw worth trying again in VMWare to see if it behaves similarly to the modded one. The modded Boot.efi (attached as Boot_mod.efi in archive) works better and apparently gets farther along than the other. In VMWare, after many minutes, there is a screen displaying various codes, most importantly one specifying that there is a disk error going on. More info is required, and more people have to test this for us to truly formulate conclusions. Today, i found this site which found that Boot.efi is RLE encoded. If someone is capable of decompressing it, we may be able to debug more, or perhaps attach a debugger to the file itself. You can see how the modded Boot.efi was created here. This post will be updated to include any progress regarding this file. Ask questions here, post results here, and discuss possibilities here! -Urby Boot.zip Link to comment Share on other sites More sharing options...
Rammjet Posted August 11, 2006 Share Posted August 11, 2006 Maybe this is known, but each of our installs has a boot.efi in this location: /usr/standalone/i386/boot.efi Link to comment Share on other sites More sharing options...
bofors Posted August 11, 2006 Author Share Posted August 11, 2006 If someone is capable of decompressing it... OK, I found a RLE decoder in C here: http://michael.dipperstein.com/rle/index.html http://michael.dipperstein.com/rle/rle-0.1.zip I should be able to compile it and decode boot.efi. Link to comment Share on other sites More sharing options...
bofors Posted August 11, 2006 Author Share Posted August 11, 2006 Ok, here the decompressed (de-RLE) versions of boot.efi and mod_boot.efi. I think they right, but I do not know without testing. dec_boot.zip Link to comment Share on other sites More sharing options...
rogabean Posted August 12, 2006 Share Posted August 12, 2006 speaking of boot.efi and the other files... could someone zip up the files located on the hard drive image and send them to me? I do not have access right now to my system to extract from the image and need to run some tests later with them on the physical machine. edit strike that request. I've moved my setup to os x version of qemu and have been able to extract. will report later how the boot.efi test goes on a physical machine. Link to comment Share on other sites More sharing options...
abcslayer Posted August 12, 2006 Share Posted August 12, 2006 Hi, everyone. From what I have seen from extracted EFI module (from RAM), there are still alot of other that did not appear in RAM at the moment we extract them. So I think some of us (include me) should come from the other side. That is take the module from the FW it self. I have take a look at the FW file. A few month ago I guest that is encrypt in what Intel call EFI Firmware Capsule, but now as I seen that the execute header in the firmware, I think that at least some portion is not encrypted/compressed. But I could not figure out how to determine where the EFI execute file end from the header (since there are not special mark to denote the end of EFI file). Any one can help? And another quick note: from my study about Intel mainboard firmware all 945 and later got EFI, and also the following: 865PCK, 915PDT, 945PLNM. The Intel FW have the same structure as Apple FW so if we can decode one of them, we could take the other. It should help us much. Link to comment Share on other sites More sharing options...
Urbz Posted August 12, 2006 Share Posted August 12, 2006 i'm pretty sure kiko tried on a physical machine and it gave the same results as vmware... try with the uncompressed. Link to comment Share on other sites More sharing options...
mifki Posted August 12, 2006 Share Posted August 12, 2006 Yep same results in native mode. Havnet ried uncompressed tho Link to comment Share on other sites More sharing options...
sbeehre Posted August 12, 2006 Share Posted August 12, 2006 i tried to run the uncompressed file in q and it work Link to comment Share on other sites More sharing options...
rogabean Posted August 12, 2006 Share Posted August 12, 2006 The uncompressed versions do not load as efi executables. kiko, when you went native... what was the test machine and did you attempt loading from a fully installed OS X on a HFS+ partition? using qemu under the alternate video driver (bochs vbe as opposed to cirrus) utilizing a HFS+ disk image with a full install of OS X... boot.efi placed in the /system/library/coreservices folder. the kernel loads.... gets a disk guid loads mkext (extensions) screen goes black as is tries to load. qemu did not lockup... it just sat there doing nothing at 90% cpu indefinately. Link to comment Share on other sites More sharing options...
bofors Posted August 12, 2006 Author Share Posted August 12, 2006 The uncompressed versions do not load as efi executables. The RLE tool I compiled will re-compress as well, should I post it? Link to comment Share on other sites More sharing options...
rogabean Posted August 12, 2006 Share Posted August 12, 2006 I'd like to see what happens when you do. Link to comment Share on other sites More sharing options...
Recommended Posts