Jump to content
Kiko

Were Back !

104 posts in this topic

Recommended Posts

We still will need hacked kernels and also hacked drivers.

As far as I understand we could get rid of those ACPI-Kernels.

Using the native power management of those kernels would be a huge step especially for notebooks.

I think the most problems come from those ACPI-hacks. They are not working correct together with the closed-source development past 10.4.4.

I guess with a "near native" kernel we would have the hole features of the new mobile intel processors (dual core, dynamic speed step, e.c.t.).

Hopefully also brightness-control from displays.

 

re-book

Share this post


Link to post
Share on other sites
Advertisement

This gets into gray areas of my knowledge on the subject.

 

If EFI was made to work, then Apple's boot.efi could be made to run, perhaps without patching. Once into that environment, a retail copy of OS X would boot. It is possible that Apple has hardware detection in the kernel that looks beyond EFI, so that would need to be patched, but ACPI and the current hacky-configuration wouldn't be needed. With EFI, hardware support would be much more reliable (eg. nvidia), and more features would be supported properly (eg. speedstep).

 

I don't know much about the current hack, but OSX86 probably uses software from the original intel development kit (a P4 IIRC), and a number of patches from people who became famous in the community long ago. The current state of things is irrelevant to this thread, other than that an EFI-booting OSX86 wouldn't be a sketchy hack and would be reliable to boot OS X versions in the future.

Share this post


Link to post
Share on other sites

boot.efi boots fine, just remove the header (which is basically deleteing a couple of bytes). and the only thing to bypass in the kernel is the efi crc. thats all you need to boot efi on DUET (also a modified efildr16 with vesa init hardcoded)

Share this post


Link to post
Share on other sites

There we are, thanks. So it requires a simple hex edit to boot.efi, and a relatively simple bypassing of a CRC check in the kernel (patch in the new CRC, or remove the check). These are much smaller patches than hacking additional functionality into the kernel as OSX86 has been doing.

 

If DUET is working, the Developer's UEFI Emulation T, then presumably it'll boot boot.efi with the small patch? Then progress must be stalled at removing the kernel's CRC check? Or the "apple EFI environment", something about decrypting files within their firmware? I don't know enough to help, so explaining these things to me is just for education, don't worry too much about it.

 

 

Not sure what "efildr16" is, google doesn't know either.

Share this post


Link to post
Share on other sites

efildr16 = efi loader

progress is stalled with the fact that duet sort of sucks :P, and its much easier to hack a kernel for bios atm than it is to hack it for efi (well, for efi you have to first boot duet, then boot boot.efi, bios is just one load, much simpler imo)

Share this post


Link to post
Share on other sites

what do you think about setting up a wiki and documenting everything in here?i just read trough the archive thread and there really were some interesting findings.look at the iphone dev wiki.they were able to do some heavy lifting because they were able to colaborate in a very effective way using a wiki.maybe we could even attract some of theme working on macefix86.

 

update:

i just had an idea, dont know if it's stupid. probably you guys already tried that, but i'll tell it anyway.maybe it's that simple/stupid, that noone tried it so far :-)what about taking a mainboard which is very close to the original mac pro mainboard,flashing a somewhat broken and half assed hacked apple-efi-version (extracted from a real macpro board)and than trying to use the apple mac pro firmware restoration cd in order to let it do the job and get a working apple efi on the chip?bad idea? probably... :-)

Share this post


Link to post
Share on other sites
update:

i just had an idea, dont know if it's stupid. probably you guys already tried that, but i'll tell it anyway.maybe it's that simple/stupid, that noone tried it so far :-)what about taking a mainboard which is very close to the original mac pro mainboard,flashing a somewhat broken and half assed hacked apple-efi-version (extracted from a real macpro board)and than trying to use the apple mac pro firmware restoration cd in order to let it do the job and get a working apple efi on the chip?bad idea? probably... :-)

 

There's also a drm chip on every Apple board so this is not going to work. Since some parts of code for all kind of drivers are moved to EFI you will also need to flash the rom of your video card for example. For example the driver for a very complicated onboard ide (raid)chip could be moved to EFI. The complicated onboard ide (raid)chip will talk to EFI and EFI will present the chip to the operating systeem like a standard ide chip. That's the way EFI works and that's the reason why we need a lot of drivers for all kind of chipsets (ICH7, ICH8 and so on).

 

The current Intel boards use EFI and emulates a bios, so you pretty close with that kind of motherboard. The only way would be to hack EFI, extract indeed the EFI from a hacked Apple and combine things together. The more a motherboards differs from a Apple motherboard the more drivers we need to program for EFI.

Share this post


Link to post
Share on other sites

there is no drm/tpm on apple motherboards, it is a common myth. EFI can be flashed to a motherboard and it will work, sort of. Some parts will not be mapped properly (i.e: USB wont work, or audio ports will be switched)

Share this post


Link to post
Share on other sites
efildr16 = efi loader

progress is stalled with the fact that duet sort of sucks :thumbsup_anim: , and its much easier to hack a kernel for bios atm than it is to hack it for efi (well, for efi you have to first boot duet, then boot boot.efi, bios is just one load, much simpler imo)

 

why if much easier to hack a kernel for bios than for efi, because the kernel patches doesn't have a full hardware support and many other issues and the efi hack that made netkas has full hardware support?

Share this post


Link to post
Share on other sites

netkas never had full hardware support lol. the kernel doesnt support any hardware, thats all done with kexts. efi will give you many more issues than the way we have it at the moment, now maybe a firmware based solution would be good. But that isnt going to happen as far as i can see.

Share this post


Link to post
Share on other sites

Ive been reading these posts about efi etc, and my bad axe 2 turned up today.

Apparently, It supports Efi.

 

So is it likely that something is going to materialise that will enable those of us with efi support (such as badaxe2) to do some sort of flashing or whatever that will let us masquerade as a "real" apple spackintosh?

 

I think I also read that you can't actually enable efi on these boards so I might be talking complete codswallop.

However, naturally it interests me.

 

so whats the score?

Share this post


Link to post
Share on other sites

The boards are running a CSM (like bootcamp) that is constantly turned on, giving us access only to the BIOS environment, when (if) Intel enables UEFI booting on these boards we will be able to utilise the full efi environment on our boards (i have a badaxe, which "supports" EFI as well). My bets on the time intel will release a firmware update is around vista SP1 or whichever vista supports UEFI

Share this post


Link to post
Share on other sites

"Microsoft is planning to release SP1 alongside Windows Server 2008 in the first quarter of 2008.", with Win2k8 due on Feb.27th (announcement? paper launch? shipping?).

 

I have been disappointed with MacEFIx86. I have an intel motherboard with 4gb of RAM that supports 3.2gb, and no support for newer processors, when I could have gone with a better non-intel board. I didn't spend as much on it as I would have a BadAxe2 or comparable, so I can't complain, but I had hoped for a breakthrough. My hope now is that it does work, yet is being kept secret for the release of 10.5. Long shot hope perhaps ;-)

 

I still believe that if EFI is made to work, then there would be less work after that to ensure driver compatibility -- things Apple supports would be supported without patching them for BIOS. I don't understand the technical details, but it seems I'm wrong?

Share this post


Link to post
Share on other sites

Apple is using efi more and more. the 8xxx series of nVidia cards are initialed entirely by eif so it is impossible to get them to work. Also some of apples essentail kexts are having efi only routines in them, which means more binary patching for us to make them bios compatible. But seeing as i own a couple of macs, and barely/ if ever use hackos any more, macefix86 isnt as big a priority for me as it was. heck, i dont even have mod control over this section anymore.

Share this post


Link to post
Share on other sites
Apple is using efi more and more. the 8xxx series of nVidia cards are initialed entirely by eif so it is impossible to get them to work. Also some of apples essentail kexts are having efi only routines in them, which means more binary patching for us to make them bios compatible. But seeing as i own a couple of macs, and barely/ if ever use hackos any more, macefix86 isnt as big a priority for me as it was. heck, i dont even have mod control over this section anymore.

 

 

Kiko... please don't say like this.. Not many of us can afford to have a real Mac. If you chose to wash your hands of the project, that might be disheartening for many of us :)

Share this post


Link to post
Share on other sites

What about using LinuxBIOS as init of mobo, and rewrite him to use EFI specification rathen than BIOS with ACPI and other legacy stuff.

So we can flash the mobo completely to use EFI rathen than BIOS.

The big trouble that LinuxBIOS at now have small compatiblity with new Intel-based mobos.

http://www.linuxbios.org/index.php/Supported_Motherboards

--and--

http://www.linuxbios.org/index.php/Support...ets_and_Devices

The EFI implementation can be found on https://www.tianocore.org/

 

So what ideas?

 

http://www.uefi.org - Additional info

Share this post


Link to post
Share on other sites
So I have found that LinuxBIOS already can boot to GNUFI, and it have the 16-bit legacy BIOS emulator for booting Windoz and OpenBSD (BootCamp will work????!!!!!).

 

But now LinuxBIOS haven't ported to new ICHs :(:(

 

Nice, i hope that Kiko or someone else read this.

Share this post


Link to post
Share on other sites
Netkas is working on this again. Check his blog:

 

This is the same thing that has been done before. It is using the tianocore efi emulation which in my opinion is not an adequate solution, but might be better as they improve that. The difference is this:

 

legacy bios -> bios booter -> modified kernel

legacy bios -> efi for bios emulation -> efi booter -> original kernel

 

as you see you get one extra boot step and altough the kernel is made for the efi booter it is still buggy and limited in the efi emulation.

 

It would be of more interest if there was proper efi on the motherboards, but only a chosen few has this options.

Share this post


Link to post
Share on other sites

So, since netkas has made all the job, i dont think we do not need this project, anyway it never made a true results.

 

Is there

Share this post


Link to post
Share on other sites

Be nice, gramshi.

 

I'm not sure about the reasons why this method isn't the best, though booting from EFI would be ideal. Microsoft releases Windows Server 2008 in Feb, which supports EFI booting, so Intel may enable it on old boards.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×