-Archive- Macefix86 2006 -Archive-

[bofors]

OK, I have compiled it for OSx86.

 

Note that it is called "sample", that you have to specify the full path when executing it in terminal and that OS X has another command line program called "sample".

 

Usage: sample <options>

options:
 -c : Encode input file to output file.
 -d : Decode input file to output file.
 -i <filename> : Name of input file.
 -o <filename> : Name of output file.
 -h | ?  : Print out command line options.

Default: sample -c

rle_0.zip

[mifki]

Rogabean, i did try to boot off a fully instaled HAck, P4 1.7 Ghz etc etc MSi mobo tho and 9600XT

[sbeehre]

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.

 

why /system/library/coreservices ?

[mifki]

because its a "blessed" folder

[Guest BuildSmart]

First, what needs to occur is that everyone who is working on this project get's onto the same page.

 

This means working with the same files using the same utilities working towards the same goal.

 

If you want my help then lets put some kind of working environment together and tackle it collectively.

[mifki]

Umm, thanks but we already ahve a working environemt made, actaully 2 of them. It works on Qemu and vmware, so that is doen, atm we are (well me, Urby, Sbheere, Blackice and abcslayer) are trying to decrypt the efi capsule.

[Guest BuildSmart]

OK, how can I obtain the complete working environment (non-vmware)

[rogabean]

See the first sticky post in this section of the forums.

 

That environment can be run on Windows, but the files can be used to run under OS X or Linux as well.

 

I currently do all of my testing and work under OS X and a physical machine while the other devs are working from Windows I believe.

 

By the way Kiko... I ran some initial tests using the physical machine... see other thread.

[mifki]

I am currentely doing this in VMWare. For some reason i cant see many disk if any when im doing it physically so im going to be focusing on virtually for now

[bofors]

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.

 

Great, I will try to help.

 

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?

 

I do not think Apple has encrypted any firmware modules (yet). However, most of them appear to be compressed in the .fd firmware file. Rogabean has said that he knows how to create these .fd files, so I assume there some way to decode and parse them into .efi modules as well.

 

However, it looks like we should be able to extract the "missing" PEI modules with some simple "cut and paste".

 

EDIT: SuperHai has already done this: http://forum.insanelymac.com/index.php?act...ost&id=4059

 

We want to get the PEI modules and execute them in the EFI shell to set-up a proper DXE.

 

I have started a new thread for this work here: http://forum.insanelymac.com/index.php?showtopic=24580

 

Can we move the discussion of topics not related to the extraction of Apple's EFI firmware to other threads?

[Superhai]

Ok, I looked around in tianocore source to find the spec for firmware filesystem (fd files), so here it is what i have found. (Numbers in bytes)

 

FileSystem header

 

16 Zero Vector

16 File System GUID

8 Firmware size

4 Signature (_FVH)

4 Attributes

2 Header length

2 Checksum

3 Reserved

1 Revision

4 Number of blocks

4 Block Length

 

File Header

 

16 File GUID

4 Integrity check

1 File type

1 File attributes

3 File size

1 File state

[rogabean]

Kiko.. this has gotten off topic from this thread, but you and I need to sync up between the VMWare and the Physical Test.

[Urbz]

great!

so what does this mean? :D

 

There's a filesystem guid. Could we "mount" one of these files in any way, or can they be read by some means?

[bofors]

EDIT: Apparently the exact function of Radeon.efi is still an open question, see below!

 

I have been under the misconception that Radeon.efi was bone fide ATI x1600 firmware and that it is possible to load EFI firmware for graphics cards in the EFI shell.

 

Both of these ideas are apparently false.

 

Radeon.efi apparently is nothing more than a UGA graphics driver designed to operate in the time between boot and the loading of OS X's x1600 graphics driver.

 

Likewise, apparently it is not possible to load firmware for graphic cards directly in the EFI environment. Rather graphics cards must initialize themselves by reading their own ROMs.

 

Starting a new thread just to nail this issue might seem stupid, but this project has been suffering more from a lack of communication than from overflow of trivial threads.

[cyclonefr]

ive said that already man...if it works fine just modifying the plist, that meant efi was just a protection.

[gwprod12]

I've said the same thing. Radeon.efi is the video driver used instead of the old-style NDRV device drivers in the video rom. Just as in BIOS, the VESA driver is used for boot graphics, Radeon.efi is used in EFI for boot graphics (one of the touted advantages of EFI is that hardware manufacturers need not implement hardware option roms, as in BIOS). Since on a hackintosh, we use BIOS, Radeon.efi serves no purpose. However. In an EFI environment, EFI itself wont implement VESA. Which means some sort of EFI video implementation will be required. Depending on how close Radeon.efi is tied to Apple's implementation of the x1600, it may be usable in a custom EFI environment. We may need to wait until EFI actually becomes an industry standard, in which case ATI will create EFI driver support for their cards.

[bofors]

ive said that already man...if it works fine just modifying the plist, that meant efi was just a protection.

I've said the same thing.

 

It was not until np_ said something recently in another thread that I began to realize my misunderstanding.

 

I know this is old news for a lot of people.

[rogabean]

I started to come to this conclusion when tracing some of the issues with the booting of an OS under EFI... but still was a little unclear.

 

All cleared up now.

[gwprod12]

Obviously this is somewhat off topic, but...

 

I've perused the sources of the kernel and I've observed two things so far. There is very little implementation (or maybe none) of Open Firmware or EFI in the kernel itself. Unlike BootX and darwin boot which both have heavy interactions with OF and BIOS respectively.

 

Just an observation.

[bofors]

From an analysis of Maxxuss' patchs, there is (was) apparently a routine known as: _machine_init. This routine contained a section of code described as "Initialiing EFI runtime services" which Maxxuss bypassed.

 

If the OpenFirmware and BIOS bootloader have significant interactions with their respective firmwares, wouldn't it be odd for boot.efi not to have the save relationship with EFI?

 

Perhaps the source code is incomplete in this respect.

[gwprod12]

I think that the bootloader has significant interaction with the firmware. I just dont think the kernel has as much. I guess the point I'm trying to make is that the bootloader (in many respects) is where the limitations of the hackintosh lie. For completely compatible systems (945GM, x1600 etc), we are limited by the information needed by the kernel for matching which is passed the kernel by the bootloader.

 

I dont know if this is 100% true, but it seems likely-ish to me. The darwin loader (that we're using) was never designed to specify hardware as deeply as the OS X bootloader BootX, or possibly even boot.efi.

 

BootX for Open Firmware constructs the initial video context for the kernel. Darwin boot doesnt. I think it's safe to assume that boot.efi does the same as BootX in that regard. As far as video is concerned, this could be a major stumbling block.

 

(Also, BootX and darwin boot both close the OF/bios context upon loading the kernel).

 

Obviously this is a problem for an EFI implementation. But, I see there being a significant option towards creating a fully-working hackintosh system by rewriting BootX for X86/Bios implementation.

 

EDIT: I should say that BootX's procedures are portable, but it's underlying functions would have to be rewritten for X86/Bios.

[bofors]

I guess the point I'm trying to make is that the bootloader (in many respects) is where the limitations of the hackintosh lie.

 

I think you really mean where the graphical limitiations lie:

 

BootX for Open Firmware constructs the initial video context for the kernel. Darwin boot doesnt. I think it's safe to assume that boot.efi does the same as BootX in that regard. As far as video is concerned, this could be a major stumbling block.

 

I still think that the lack of EFI is broadly the source of many hackintosh related problems. However, it now appears to me that graphics card firmware differences may be the real problem with hackintosh graphics and that the use of EFI offers no means to address these problems.

 

Now that Apple has released x86 graphics cards, this question should be resolved shortly. It is only matter of time (perhaps days) before someone experiments with an Apple 7300GT in a hackintosh with the Mac Pro drivers. I think it has a good chance of working perfectly and if it does then we should know where the real problem in fact lies.

 

Obviously this is a problem for an EFI implementation. But, I see there being a significant option towards creating a fully-working hackintosh system by rewriting BootX for X86/Bios implementation.

 

EDIT: I should say that BootX's procedures are portable, but it's underlying functions would have to be rewritten for X86/Bios.

 

Well, my decompliation of boot.efi failed to yield almost anything. But I still do not understand why the BootX approach you are advocating is way the to go here. First of all, if the BootX could be rewritten for BIOS, it also could be rewritten for EFI. Second, just on general prinicple, we should consider the "big picture", decide that EFI is the future and deal with it (which is what the MacEFIx86 is all about). BIOS is history, Leopard will undoubtly require an EFI bootloader. We will be ready by the time it is publically released.

[gwprod12]

The limitations of the hackintosh on completely compatible hardware are mostly graphical and power management. Power Management has a lot to do with the kernel. I leave that to others to figure out ;-p

 

If you were to reverse-engineer BootX to run on the intel platform, you could easily make it both EFI and BIOS compatible. The primary reason why EFI compatibility is a problem is that no boards have EFI yet.

 

I just think it's a waste of time to try to decompile boot.efi to engineer it to work on a custom EFI implementation that doesnt work correctly when you could just write the loader from scratch and completely disregard the problem. Not even scratch, since aside from the open-firmware and CPU specific pieces of BootX, most of the code is portable.

 

And seriously, how much of the operating system actually deals with EFI OR BIOS after boot? Not much.

 

Do you see where I'm going?

[bofors]

The primary reason why EFI compatibility is a problem is that no boards have EFI yet.

 

That's not true. Intel boards are fully EFI compliant and apparantly so is the BIOS they using (AMIBIOS8 with an EFI "eModule"). Moreover, almost all of the work here is designed to run EFI on normal BIOS boards.

 

Do you see where I'm going?

 

Yes, I do and I think you are being myoptic. If the BootX source is available some place (is it?), you may have a very good point about using it as a model. But we already have a working BIOS bootloader and my list of hackintosh problems certainly includes bootable RAID, a usable Startup Disk panel and Target Disk mode. These are all within the realm of EFI.

 

Furthermore, your assertion that the bootloader is responsible for problems in graphics has yet to be proven and seems to be contraindicated by the fact some x1600 cards and GMA 950 boards run almost perfectly with OS X. Finally, you are presuming that boot.efi itself needs to be hacked or replaced. I do not think this is true either. Really, we should use boot.efi "as is" and hack the kernel instead (or rather un-hack it, as Maxxuss modified it to so that it works with the BIOS bootloader instead of boot.efi).

[niteice]

http://darwinsource.opendarwin.org/10.4.6.ppc/BootX-74.1/

 

I don't think it would be a good model though. OpenFirmware is too different from EFI. The only parts that are really usable would be the initialization of the drivers and kernel, even then, it's a lot of ASM required to set the state appropriately.

 

There's also the old BIOS boot loader, but I'm not sure how relevant that would be either.