-Archive- Macefix86 2006 -Archive-

[McSkywalker]

Thank you Munky, that's the same size as the flash rom chip on my mobo has

If it ever gets to work with EFI...

[mifki]

mifki, well nothing to do with the kernel or boot.efi yet, mainly its GrpahicsConsole.efi and a couple of other modules which dont seem to be complete

[Vitaliy]

can you give more details please?

you booting into (emulated) efi and what you're trying to do next and where it fails?

[bofors]

Well after no news for almost a month i guess its time to explain why this project has been very un-eventful.

 

The maiin reasons we can not advance with EFI are

(1) we dont have a complete environement

(2) We are unable to get a complete environment (unless we get some more talented people to help us make the Intel EFI boards boot to efi shell before it loads the CSM)

So basically we can not move on to loading apple's efi modules properly until we can first get a proper EFi environment to work with and this has nothing to do with apple. It is up to Intel and when it will decide to relase a firmware update which allows us to use the EFI on our boards not justy default us to the CSM

 

We were able to load boot.efi and watch it begin to load the extensions and kernel, but it crashes due to us having a incomplete environment to work on

 

Thanks for the report Kiko. I would like to try to flush out some of the details by asking a few questions:

 

(1) Has anyone been able to make the TianoCore tip that Simon found for accessing the native EFI environment?

 

(2) Was anyone able to determine which modules are responsible for loading the CSM from loading by dissecting the Intel firmware?

 

(3) Has any progress been made in learning how to flash custom EFI firmware?

[mifki]

1) No that is were we are stuck , i dont know much ASm enough to help with the possible solution im learning but my cisco is also taking up a lot of time so i dont have much time to learn ASm more, that is why we need people to help we have had one or two people starting but then they have disappeared

 

2) I think i saw A Legacy BIOS.efi in the list of modules, but the extraction app doesnt extract them all or they are not all included in the intel firmware updates.

 

3) I think BuildSmart has done this but i have been unable to contact him

[sn8k]

I wonder about a little thing ...

 

There's a bios replacement made with linux ... can't remember the website of that stuff but ... isn't it possible to make something that could work like this :

 

POST > Boot To Linux-Bios > Emulating EFi > Boot to OS ???

 

I think it'll be easier to do instead of remaking the whole part of the EFi ... and it should be more compatible too ...

 

Well ... i'm not a dev , so, maybe someone can tell if that's possible !

 

edit : http://linuxbios.org/index.php/Main_Page

[joe75]

The Linux emulator is PPC

[mifki]

and we have already done that in march lol,

[adriandkicks]

Would it be possible to re-program this to dum the EFI firmware data to a file???

[mifki]

Well only if we had the source but we might as well do that with the iflash utility supplied by intel, also if you read the other threads w ealreadyhave been able to extract the firmware form intels bios updates.

[Gio]

I'm using qemu and I am getting the same thing it goes to load the drives then a black screen with a white box in left corner but if I click on the screen it turns to a gray color like it is about to boot but it is just a plain grey screen and it never changes.

 

EDIT: When booting with verbose and safe mode flags (-v and -x respectively) I get an error that says "error loading drivers." See attached picture for the screenshot.

 

EDIT2: When booting with just verbose (-v) It gets past drivers and goes to an all grey screen instead of one with a white box in the corner. See second screenshot.

 

Whoops meant to put this in the environment release sorry.

[numberonekiwi]

I have tried to D/L from rapid share but everytime I enter the 3 character code it comes back wrong code entered is it possible for someone to upload it some where else maybe

[mifki]

Yeah for drivers get a extensions.mkext file and place it in the same dir as the boot.efi

[sbeehre]

so guys.... since the kernel is now out i think its time we looked at efi again!

[bofors]

Yes, I think we should be gearing up for another major EFI push after the new kernel "dust" settles.

 

Some new people are showing up in the IRC and expressing interest in joining the team, including TheMaxx32000 who has some ASM and C programming skills.

 

1) No that is were we are stuck , i dont know much ASm enough to help with the possible solution im learning but my cisco is also taking up a lot of time so i dont have much time to learn ASm more, that is why we need people to help we have had one or two people starting but then they have disappeared

 

So, does it seem like this should be the primary goal? That is, accessing the native EFI environment on the Intel boards.

 

Regarding the TianoCore EFI implementation, is it reasonable to expect that TianoCore will complete it? Is it reasonable to contemplate completing it ourselves?

[errandwolfe]

So, does it seem like this should be the primary goal? That is, accessing the native EFI environment on the Intel boards.

IMHO, yes the primary goal should be getting EFI working on actual EFI capable hardware. Once you have it working on "standard" efi hardware, then attention should focus on creating a shell for standard BIOS users.

[mifki]

yah buildsmart got a 915 board flashed and it sortta worked it could load boot.efi but other things didnt map porperly so it didn create a very "functional" system, but it shows it can be done

[bofors]

IMHO, yes the primary goal should be getting EFI working on actual EFI capable hardware. Once you have it working on "standard" efi hardware, then attention should focus on creating a shell for standard BIOS users.

 

Right, but even focusing on Intel boards, we still have choices to make. It seems clear that the way to go is accessing the native EFI environment (as opposed to emulating EFI with the TianoCore impementation). Either way, the use of Intel EFI boards is better because their firmware is in fact composed of EFI modules (which happen to emulate BIOS).

 

Let's continue the discussion on the technical details related to accomplishing the goal of accessing the native EFI environment on Intel boards in the appropriate thread:

 

http://forum.insanelymac.com/index.php?showtopic=26126

[bofors]

The other thing I wondering about it the status of the MacEFI toolkit. What is the story version 3?

[bofors]

I think this can't be work. Before CSM is invoking, it would called a boot services ExitBootService().

Everything is over when this routine was called

 

It seems that we have to get to the bottom of this question.

 

Either we can use the "EFI Pointer" (EFI_SYSTEM_TABLE_POINTER) to execute EFI programs (images) on the native EFI implemenation or not.

 

I am looking for the specific reference , but I believe that EFI will not execute PEI and DXE after ExitBootService() has been called.

 

EDIT: This is basically what I was looking for:

An operating system loader also uses boot services to determine and access the boot device, allocate memory, and create a functional environment for t e operating system to start loading. At this point, an OS loader could call th ExitBootServices() function, after which boot services will not be available. http://www.kernelthread.com/publications/firmware/

 

Here is more from the EFI Spec v1.10 link below, page 5-85:

 

The ExitBootServices() function is called by the currently executing EFI OS loader image 
to terminate all boot services. On success, the loader becomes responsible for the continued 
operation of the system. 
An EFI OS loader must ensure that it has the system’s current memory map at the time it calls 
ExitBootServices(). This is done by passing in the current memory map’s MapKey value 
as returned by GetMemoryMap(). Care must be taken to ensure that the memory map does not 
change between these two calls. It is suggested that GetMemoryMap()be called immediately 
before calling ExitBootServices(). 
On success, the EFI OS loader owns all available memory in the system. In addition, the loader can 
treat all memory in the map marked as EfiBootServicesCode and 
EfiBootServicesData as available free memory. No further calls to boot service functions or 
EFI device-handle-based protocols may be used, and the boot services watchdog timer is disabled. 
On success, several fields of the EFI System Table should be set to NULL. These include 
ConsoleInHandle, ConIn, ConsoleOutHandle, ConOut, StandardErrorHandle, 
StdErr, and BootServicesTable. In addition, since fields of the EFI System Table are 
being modified, the 32-bit CRC for the EFI System Table must be recomputed.

 

However, it seems like it must be possible to reset EFI into a pre-boot state somehow. While I doubt there is some way to offical way to reset EFI to the pre-boot state, we should check thoroughly.

 

EDIT: According to the EFI Spec v1.10 (linked below), page 4-2, we should be able to call ResetSystem() to deal with the ExitBootService() problem:

 

If the EFI image is an EFI OS Loader, then the EFI OS Loader executes and either returns, calls the 
EFI Boot Service Exit(), or calls the EFI Boot Service ExitBootServices().  If the EFI 
OS Loader returns or calls Exit(), then the load of the OS has failed, and the EFI OS Loader is 
unloaded from memory and control is returned to the component that attempted to boot the EFI OS 
Loader.  If ExitBootServices() is called, then the OS Loader has taken control of the 
platform, and EFI will not regain control of the system until the platform is reset.  One method of 
resetting the platform is through the EFI Runtime Service ResetSystem().

 

 

Otherwise, I think we should be able to manual reset EFI by perhaps editing memory. I mean, EFI has to know what state it is in by referencing memory, so if we can determine which addresses are used we can bypass the ExitBootService() problem.

[bofors]

\

The problem is that the EFI shell, as every EFI application, expects to be passed a pointer to the EFI System Table and an EFI_HANDLE to its LoadedImage protocol. But using legacy boot through INT19 you won't be able to get those arguments. However, I think there's a way to get things working, but it's complicated. It involves writing a trampoline boot sector that "speaks" INT19 (see the Sample implementation for a sample boot floppy boot sector). This sector will point to a trampoline program. This trampoline program needs to do the following:

1. Switch to 32-bit mode.
2. Locate the EFI Shell on the floppy (or the USB key, but I don't know how
to write a boot sector for a USB key).
3. Locate the EFI_SYSTEM_TABLE_POINTER structure in memory (see section
16.4.2 of the EFI spec).
4. Using the EFI_SYSTEM_TABLE_POINTER structure, find a pointer to the EFI
System Table.
5. Use this pointer to invoke the LoadImage() and StartImage() boot
services manually.

Doing this way you will invoke the shell correctly using a legacy boot. You just have to configure your BIOS so it boots from the floppy first.

 

Here is the EFI Spec. referenced: http://rapidshare.com/files/1340152/EFI_1-10.pdf.html

 

Chapter described the EFI "entry point" in detail.

 

This is an update to the EFI Spec.: http://rapidshare.com/files/1341222/EFI_1-10_Update.pdf.html

[bofors]

EFI Spec v1.10 link below, page 6-21:

 

ResetSystem() 
Summary 
Resets the entire platform. 
Prototype 

VOID 
ResetSystem ( 
IN EFI_RESET_TYPE ResetType, 
IN EFI_STATUS  ResetStatus, 
IN UINTN   DataSize, 
IN CHAR16   *ResetData OPTIONAL 
); 
Parameters 
ResetType The type of reset to perform.  Type EFI_RESET_TYPE is defined in 
“Related Definitions” below.   
ResetStatus The status code for the reset.  If the system reset is part of a normal 
operation, the status code would be EFI_SUCCESS.  If the system reset 
is due to some type of failure the most appropriate EFI Status code 
would be used. 
DataSize The size, in bytes, of ResetData. 
ResetData A data buffer that includes a Null-terminated Unicode string, optionally 
followed by additional binary data.  The string is a description that the 
caller may use to further indicate the reason for the system reset. 
ResetData is only valid if ResetStatus is something other then 
EFI_SUCCESS.  This pointer must be a physical address. 
Related Definitions 

//******************************************************* 
// EFI_RESET_TYPE 
//******************************************************* 
typedef enum { 
EfiResetCold, 
EfiResetWarm, 
EfiResetShutdown 
} EFI_RESET_TYPE;

 

So, there are three types of resets: cold, warm and shutdown. I think the question now is, do any of these resets NOT load the firmware.

 

EFI Spec v1.10 link below, page 6-22:

 

Description 
The ResetSystem()function resets the entire platform, including all processors and devices, and 
reboots the system.  
Calling this interface with ResetType of EfiResetCold causes a system-wide reset.  This sets 
all circuitry within the system to its initial state.  This type of reset is asynchronous to system 
operation and operates without regard to cycle boundaries.  EfiResetCold is tantamount to a 
system power cycle. 
Calling this interface with ResetType of EfiResetWarm causes a system-wide initialization.  
The processors are set to their initial state, and pending cycles are not corrupted.  If the system does 
not support this reset type, then an EfiResetCold must be performed.  
Calling this interface with ResetType of EfiResetShutdown causes the system to enter a 
power state equivalent to the ACPI G2/S5 or G3 states. If the system does not support this reset 
type, then when the system is rebooted, it should exhibit the EfiResetCold attributes. If the 
ACPI S5 state is supported on the system, then this reset type should not be used.  
The platform may optionally log the parameters from any non-normal reset that occurs. 
The ResetSystem() function does not return.

 

So, EfiResetWarm looks the closest, but "causes a system-wide initialization". Hmm... that sounds like it would reload the firmware (which is not what we want.

 

Trying to manually reseting EFI after ExitBootServices() is called sounds more difficult than editing the firmware not to call it in the first place. Perhaps that should be our approach instead.

[bofors]

So, to get access to the native EFI environment, it looks like we basically have to do three things:

 

(1) Find the location of ExitBootServices() calls in the Intel EFI firmware image, perhaps using a dissembler like IDA Pro.

 

(2) Edit the firmware at those locations so that ExitBootServices() is not called, flash the modified firmware to board (perhaps after dealing with whatever Intel iFlash security barriers need to be overcome, like re-calculating a checksum for the BIOS image).

 

(3) Locate the EFI Systsem Table as per above. This involves searching memory for the EFI System Table Signature as described in the EFI Spec., page 16-24:

 

16.4.2 EFI System Table Location 
The EFI system table can be located by an off-target hardware debugger by searching for the 
EFI_SYSTEM_TABLE_POINTER structure.  The EFI_SYSTEM_TABLE_POINTER structure is 
located on a 4M boundary as close to the top of physical memory as feasible.  It may be found 
searching for the EFI_SYSTEM_TABLE_SIGNATURE on each 4M boundary starting at the top 
of memory and scanning down.  When the signature is found, the entire structure must verified 
using the Crc32 field.  The 32-bit CRC of the entire structure is calculated assuming the Crc32 
field is zero.  This value is then written to the Crc32 field. 

typedef struct _EFI_SYSTEM_TABLE_POINTER { 
 UINT64				Signature; 
 EFI_PHYSICAL_ADDRESS  EfiSystemTableBase; 
 UINT32				Crc32; 
} EFI_SYSTEM_TABLE_POINTER; 

Signature A constant UINT64 that has the value 
EFI_SYSTEM_TABLE_SIGNATURE (see the EFI 1.0 
specification). 
EfiSystemTableBase The physical address of the EFI system table. 
Crc32  A 32-bit CRC value that is used to verify the

 

The EFI System Table Signature is defined in the EFI Spec., sec. 4.3, page 4-4:

 

#define EFI_SYSTEM_TABLE_SIGNATURE	  0x5453595320494249

[joe75]

I don't want to seem like a retard, but do you think it would be possible to look at Vistas EFI boot file and be able to see what its doing to load

[bofors]

Joe, the issue here is accessing (or creating) an EFI environment that can be used to execute Apple's EFI drivers in the DXE EFI phase (like Radoen.efi) and then call Apple's EFI bootloader (boot.efi) to load OS X properly (which will require an EFI kernel).

 

This has almost nothing to do with the Microsoft Vista EFI bootloader.