Jump to content

-Archive- Macefix86 2006 -Archive-

bofors

By bofors,
in Archive

 Share
443 posts in this topic

Recommended Posts

Alpha Sirius
Alpha Sirius
Posted
Posted

Sorry but didn't work, My system got weird under x86_64 emulation on QEMU, looks like the CPU has stoped (FreeBSD) Athlon XP

Link to comment
Share on other sites
Alpha Sirius
Alpha Sirius
Posted
Posted
Umm, why are you running under x86_64? Its supposed to be run under x86_32

 

Just 'Cause I'm planing to use a futer version of it to run Leopard on my AMD64 Machine

 

Are you planing to port it to x86_64?

 

Thanks :)

Link to comment
Share on other sites
Urbz
Urbz
Posted
Posted

Unfortunately, I think the environment needs to mature a bit more before we can even think of porting it to x64. Current tests use 32-bit and ony 32-bit because we are using kexts from an iMac and not a Mac Pro. We're not even sure what the differences are, so i would say just use what we currently have for now.

 

-Urby

Link to comment
Share on other sites
bofors
bofors
Posted
  • Author
Posted
1. Will this work with a BIOS board with an EFI partition, or does it have to be and EFI compatible one?

 

None of this requires an EFI board.

 

2. Does it only work under Qemu, or will it work natively?

 

You can natively boot into the EFI Shell on most but not all (especially laptops) BIOS PCs with an ISO that is included. However, I do not think that part of MacEFIx86 environment is complete yet.

Link to comment
Share on other sites
re-book
re-book
Posted
Posted

Some perhaps silly thoughts.

As far as I know (and please correct me if I am wrong) is the content of a normal modern BIOS copied into the RAM directly after start. This is done because the access of the RAM is faster than accessing the flash-ROM directly. Think I red some long time ago that a OS will never accessing the flash directly, it will read only the shadow in the RAM. I don't know anything about EFI but I would expect that there is the same situation. So why should it not be possible to dump this into a image and load it from normal BIOS ? I would think that is should be possible to change the source of a simple bootloader in the way that he copy this image over the BIOS shadow. The last action it had to do is copy the start address of the EFI-Code into the CPU instruction pointer.

Or is that nonsense ?

 

re-book

Link to comment
Share on other sites
Urbz
Urbz
Posted
Posted

you're certainly correct as far as pulling things from ram is concerned.

The problem is EFI works in two stages: Pei and Dxe.

Read more at our wiki, here.

As you can see, pei is wiped out of memory, making it a little harder to extract!

 

-Urby

Link to comment
Share on other sites
sbeehre
sbeehre
Posted
Posted

This is from the Tianocore dev mailing list

 

One option could be to install the EFI shell as you would install a
normal OS. It depends if you want to run in the native EFI environment of
your card (EFI Framework-based) or if you just want to have access to EFI
on top of your hardware.

To install the EFI shell, you need to create your own installation program
and then install it on a bootable device (such as a CDROM formatted with
ElTorito).
Your installation program would need to do the following:
1. Create an EFI partition on one of your disks
2. Copy the EFI Shell binary on the disk
3. Create an EFI boot option pointing to the EFI shell copied on the disk.

Of course, your installation program can be an EFI program. It will be
invoked automatically when BIOS boots your El Torito CDROM. Perhaps it has
to follow the default naming conventions (sth like beeing called "
\EFI\<architecture>\boot<architecture>.efi, e.g for ia64 systems :
\EFI\ia64\bootia64.efi).

This requires some work, but you have all the necessary documentation in
the EFI 1.10 Spec. It has the advantage of beeing portable on any platform
with an EFI-based BIOS, and giving you access to the real EFI environment
installed on your platform.

Link to comment
Share on other sites
Christoph Pfisterer
Christoph Pfisterer
Posted
Posted
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 should read that article more carefully. It talks about replacing the gray apple logo that appears on boot. The image data of that logo is embedded in boot.efi, and the image data is compressed to save some space (91% in this case, it would be 16384 bytes uncompressed). The boot.efi file itself is a plain EFI executable (PE32+ format), otherwise the firmware wouldn't be able to load it.

Link to comment
Share on other sites
sbeehre
sbeehre
Posted
Posted

here is some more info

 

Perhaps the boot options are not saved correctly to NVRAM when you create
the boot option from the floppy emulation. I don't think the Sample
Implementation provides a real implementation of the NVRAM services. So
probably the boot option was saved to a file on the floppy and not to your
real system's NVRAM (that's why you see your boot option only when using
the boot floppy).

Instead, you should create a program that uses the native EFI to create the
boot option.

What you can do is the following:

1. write a little EFI program that creates the boot option. Simply check
the device path to the EFI shell binary (using the boot floppy), and
hard-code it in your program.
2. copy the resulting binary to a floppy in the following directory :
\efi\boot\bootia32.efi (if your motherboard is ia32 based).
3. reset your system
4. use the "boot from floppy" option of your system.

Doing so, your EFI program will be invoked in the native system's EFI
environment, and the Variable Services will actually create the boot option
in NVRAM. You have sample code of how to create a boot option in the Boot
Manager of the Sample implementation. Basically, what you have to do is:
- read the BootOrder variable
- check for the next available boot option number
- create the Bootxxxx variable.

Another option (maybe easier) is to rename the Shell binary to follow the
convention I just described, that is : Shell.efi -> \boot\efi\bootia32.efi
on your floppy. If the native EFI follows the same convention for boot
files as the Sample Implementation, this should work just fine !

Link to comment
Share on other sites
Urbz
Urbz
Posted
Posted

I was thinking the same.

I've come to the conclusion that right now, on the boards, EFI exists (obviously...lol!) but it is booting with CSM because no current OS requires EFI.

So the code of EFI, everything, really, is all there on that chip.

It is just a matter of exploiting it and using it.

Well, by successfully implementing a shell and booting to it, you will be given full access of the EFI chip and be in the board's EFI environment.

From there, anything can happen!

 

-Urby

Link to comment
Share on other sites
mifki
mifki
Posted
Posted

Ok, im going to try this today at TAFE as we have 945 based boards here. I haev two Shell_Full.efi files one is 1Mb< in size while the othe ris over 2 mg in size, i will try both of them.

Link to comment
Share on other sites
bofors
bofors
Posted
  • Author
Posted
i cant understand why intel doesnt provide a firmware image without the CSM for people who want to use EFI and linux for example

 

I asked Intel about this months ago, it sounds like they are preparing to release regular EFI firmware (not BIOS emulating):

 

Hello again [Bofors],

The issue we run into is the level of quality we have for any given
product that hits the market.  Even if you and the rest of the
development community are willing to accept a pre-production EFI
supported BIOS, the rest of the world may expect it to be production
quality if it's in the market and has the Intel name on it.  Our
customer service lines cost us quite a bit of money, and in the past we
have found that releasing pre-production parts ends up in money lost
through customer support calls, complaints, etc.  It also can result in
a loss of confidence in Intel products, we understand that the Intel
name on a product speaks of quality.  We intend on doing our best to
keep that value close.

To get any product to the level of production quality takes huge 
amounts of testing depending on what your given product is.  A motherboard is
built to interface with hundreds of thousands of devices/software.
Making a simple change to PCI config space is one thing, but moving 
from a legacy interface to an EFI non-legacy O.S. interface is something
totally different.  It requires huge amounts of testing to verify that
all the interfaces are functional to the specification, and even to non
compliant devices.

We have the ability to release a board with the EFI interface that we
have now.  We have had that ability for quite awhile now actually, it's
just getting past the next step of validation and clearing up bugs.
Something of this size will undoubtedly also force new specifications
into the market where there currently are none.

Please note that this message I have sent you is not cleared through 
all the final Intel marketing teams, so it's currently only classified as 
my personal opinion.  I'm still working on tracking down our official
stance to the public about where we are and what we plan to do.  I'll
keep you posted as I find out.

Thanks again,
[~Intel Guy]

 

So, we know that Intel has it already and I would guess that the Intel guys at TianoCore have access to it. Pressuring Intel to release it, along with certain firmware packaging and flashing tools, for development work via TianoCore may be worth while.

 

..... also there must be some way to stop it from loading.

 

From my limited understanding of the AMIBIOS8 with EFI "eModule", it is not exactly EFI firmware with a BIOS CSM, but rather the opposite, BIOS firmware which emulates (or is compability with) EFI. So, it may not be possible to "stop it from loading".

Link to comment
Share on other sites
sbeehre
sbeehre
Posted
Posted
From my limited understanding of the AMIBIOS8 with EFI "eModule", it is not exactly EFI firmware with a BIOS CSM, but rather the opposite, BIOS firmware which emulates (or is compability with) EFI. So, it may not be possible to "stop it from loading".

 

I hope its not like that

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...