-Archive- Macefix86 2006 -Archive-

[Blackice]

I want to also try to change the efi-loader to return back and not halt on int6. But I am not good at assembler and exception programming.

 

well the efi shell is written in C, and is open source (I believe). I should be as easy as finding the string, working backwards to whatever causes it, and encapsulating that in a try/catch block.

 

Yes we were in the process of making a Cd but we stumbled across a large problem which has a higher priority than a cd, apparentely QEMU is freezing as it does not have MMX/SSE support, we are now trying to port the environment over to VmWAre.

 

Actually, I'm not so sure its an MMX/SSE issue. That's based on the fact that, since version 0.7.0, QEMU does have MMX, SSE, and SSE2 support. (see http://fabrice.bellard.free.fr/qemu/changelog.html). I'd like to see how you came up with that conclusion. Anyway, we can test if its a QEMU limitation by getting an intel mac to load the EFI Shell natively and run the same boot.efi that we're using.

[sbeehre]

Actually, I'm not so sure its an MMX/SSE issue. That's based on the fact that, since version 0.7.0, QEMU does have MMX, SSE, and SSE2 support. (see http://fabrice.bellard.free.fr/qemu/changelog.html). I'd like to see how you came up with that conclusion. Anyway, we can test if its a QEMU limitation by getting an intel mac to load the EFI Shell natively and run the same boot.efi that we're using.

 

we came to that conclusion because on the qemu site it mentioned that one of the limitations of qemu is that is doesnt support sse/mmx... but hey im glad it if does

 

Current QEMU limitations:

No SSE/MMX support (yet).
No x86-64 support.
IPC syscalls are missing.
The x86 segment limits and access rights are not tested at every memory access (yet). Hopefully, very few OSes seem to rely on that for normal use.
On non x86 host CPUs, doubles are used instead of the non standard 10 byte long doubles of x86 for floating point emulation to get maximum performances.

[Blackice]

we came to that conclusion because on the qemu site it mentioned that one of the limitations of qemu is that is doesnt support sse/mmx... but hey im glad it if does

 

That page seems to not be updated very often

[Superhai]

well the efi shell is written in C, and is open source (I believe). I should be as easy as finding the string, working backwards to whatever causes it, and encapsulating that in a try/catch block.

 

It is part assembler and part c. The first part, bootblock, switch to protected mode and startup of the c efildr is in assembler. Yes it is open source, so when i got some time i will try to find it out. Actually it would be great to also find the efildr for the real macs.

[Urbz]

Actually it would be great to also find the efildr for the real macs.

 

Any ideas on where this would live?

[Superhai]

Any ideas on where this would live?

 

It should be on the efi chip. somewhere. It is the first the cpu reads when it wakes up.

I haven't a clue yet, but it is loaded in memory so maybe it is possible to get it like you got the other files.

[Urbz]

But it wouldn't be loaded in the environment itself right? When i inspected the handles, the first one was dxemain.efi. That's the first thing in memory that dh cared to tell me about. maybe there's stuff before that?

 

[edit]

 

been playing with the efi in qemu and looking at memory adresses and i can't find the contents of efildr anywhere. superhai, i've you can find efildr in out test env., i might be able to retrieve it from the iMac.

 

Bofors, you gave me an idea. Before i elaborate, how did you find that list of files? What did you do to the fd file?

[enb14]

well the efi shell is written in C, and is open source (I believe). I should be as easy as finding the string, working backwards to whatever causes it, and encapsulating that in a try/catch block.

Actually, I'm not so sure its an MMX/SSE issue. That's based on the fact that, since version 0.7.0, QEMU does have MMX, SSE, and SSE2 support. (see http://fabrice.bellard.free.fr/qemu/changelog.html). I'd like to see how you came up with that conclusion. Anyway, we can test if its a QEMU limitation by getting an intel mac to load the EFI Shell natively and run the same boot.efi that we're using.

 

Just one question guys, why are you using qemu instead of VMWare?

[bofors]

Bofors, you gave me an idea. Before i elaborate, how did you find that list of files? What did you do to the fd file?

 

I was looking to see if there was some simple packing of the .efi modules in the .fd file (I now think they are compressed). I just opened up the .fd file in text edit and search for the .efi module names. There was no overlap, nothing you extracted was there and vice versa.

[Superhai]

Just one question guys, why are you using qemu instead of VMWare?

Maybe because it is free?

 

Are these the files you talk about? I am not sure if they are any use.

dAppleFW.rar

[Urbz]

Just one question guys, why are you using qemu instead of VMWare?

 

Free and distributable. Plus images could be created in mac and used in the environment.

 

I was looking to see if there was some simple packing of the .efi modules in the .fd file (I now think they are compressed). I just opened up the .fd file in text edit and search for the .efi module names. There was no overlap, nothing you extracted was there and vice versa.

 

Well the iMac has a recent firmware. That would mean this page. Find the fd in the application it contains. It is called LOCKED_IM41_0055_03B.fd.

I am looking in textedit now, and you were mistaken. I think ALL the ones i extracted are there. Search for .pdb and see what it gives you.

When you use a hex editor, you can see where a module starts and stops based on the hex string "4D 5A" assuming of course that it stops where the next begins. I will try extracting one and using efidecompress to hopefully give some results.

[Superhai]

But it wouldn't be loaded in the environment itself right? When i inspected the handles, the first one was dxemain.efi. That's the first thing in memory that dh cared to tell me about. maybe there's stuff before that?

 

Maybe that is just the one. I think I understand a bit more. The first file that is loaded is the PeiMain (I assume this because PEI is the Pre EFI Init). DXEMain is after PEI is completed (DXE = Driver Execution Environment).

 

Ok I am think loud now, but maybe this is something.

[Superhai]

Here is something I would wa<nt to get hold on.

A native EFI debugger.

 

http://www.arium.com/products/frameworkefi.html

[Urbz]

Maybe that is just the one. I think I understand a bit more. The first file that is loaded is the PeiMain (I assume this because PEI is the Pre EFI Init). DXEMain is after PEI is completed (DXE = Driver Execution Environment).

 

Ok I am think loud now, but maybe this is something.

 

can't be. It's only 44kb. Efildr is above 400.

I tried the whole efidecompress thing: nothing works. Loading, executing, the file can't even decompress.

 

I'm not sure where to go from here. We need to know more about Efildr.

[bofors]

Well the iMac has a recent firmware. That would mean this page. Find the fd in the application it contains. It is called LOCKED_IM41_0055_03B.fd.

 

That is a more recent .fd image, I was looking at the original.

 

I am looking in textedit now, and you were mistaken. I think ALL the ones i extracted are there. Search for .pdb and see what it gives you.

 

I do not see any of the files you extracted in TextEdit.app. I am searching for ".pdb" and I get the basically same list of files that I posted above, with addition of AppleDebugSupportFireWireInit.

 

When you use a hex editor, you can see where a module starts and stops based on the hex string "4D 5A" assuming of course that it stops where the next begins. I will try extracting one and using efidecompress to hopefully give some results.

 

Sounds good.

[Urbz]

That is a more recent .fd image, I was looking at the original.

I do not see any of the files you extracted in TextEdit.app. I am searching for ".pdb" and I get the basically same list of files that I posted above, with addition of AppleDebugSupportFireWireInit.

 

oops then my mistake. BTW the other thing didn't work.

Remember the whole "load as they're in memory" thing?

Well if superhai is right (and it makes sense) DXE stands for Driver eXecution Environment.

And seeing as that's the first one to load, by name and memory address others would be dependent on it.

And it just stops loading. I already mentioned the iMac can boot straight into OSX with boot.efi.

I think we should shift our focus to getting all the modules to work. Maybe we could mod them as was done with boot.efi, starting with DxeMain.efi?

Superhai, what did u use to test the modules and get back that debug code (for some)? Is there nothing that could be done to some to get an output of some sort? DxeMain.efi is AD80 Bytes long. How much goes into memory?

[Superhai]

can't be. It's only 44kb. Efildr is above 400.

I tried the whole efidecompress thing: nothing works. Loading, executing, the file can't even decompress.

 

I'm not sure where to go from here. We need to know more about Efildr.

 

Yes because it includes drivers and the shell.

 

 

Here is my first change of efildr, only thing removed is the shell from the efildr file. This requires a fat32 disk.

efi.rar

[Urbz]

so i just shove it on a fat32 floppy?

[Superhai]

so i just shove it on a fat32 floppy?

 

No a harddisk, i guess it must be on the first partition. bs32.com is the bootsector (can be put on the disc from the efi environment by using

dumpbs -w fat32 blkX Bs32.com ) (X is the number of the fat32 disk).

[bofors]

Well if superhai is right (and it makes sense) DXE stands for Driver eXecution Environment.

 

Of course, and PEI is Pre-EFI Initialization:

 

Just as the BIOS supports a phased approach to booting the system, so does the Framework. The Framework consists of two major phases: Pre-EFI Initialization (PEI) and Driver Execution Environment (DXE).

 

The PEI phase provides a standardized method of loading and invoking specific initialization routines for the processor, chipset, and motherboard. PEI modules for a particular processor and chipset need to be rewritten when ported to another processor/chipset architecture. This task is far simpler than legacy BIOS modification as 98% of PEI code is written in C.

 

The primary purpose of PEI is to initialize enough of the system to allow instantiation of the DXE phase. The transition to DXE involves creating a series of linked data structures that describe what the PEI modules have discovered about the systems memory, firmware stores, boot devices and so on. PEI is very flexible in how memory is allocated and initialized. It typically defers sophisticated diagnostics and initialization of the majority of memory to the DXE phase. After the transition to DXE all PEI modules are torn down.

 

The DXE phase is where most of the system initialization is performed. DXE drivers are responsible for initializing the processor, chipset, and platform components as well as providing software abstractions for console and boot devices. These components work together to initialize the platform and provide the services required to boot an OS.

 

Keep in mind that DXE drivers are not OS drivers. While an OS driver has to exploit the full capability of the hardware and make it available to applications, DXE drivers are single threaded and simply have to support those features that are needed to boot the OS or set up and manage the platform. As a result, a practical implementation of the Framework on a desktop PC platform fits in only 512 KB of flash memory.

 

http://www.intel.com/cd/ids/developer/asmo...8649.htm?page=3

 

And seeing as that [DXE] the first one to load....

 

Maybe we could mod them as was done with boot.efi, starting with DxeMain.efi?

PEI is the first stage. I am guessing that the PEIMain.efi module is unloaded.

 

I think we should shift our focus to getting all the modules to work.

 

Absolutely. Let's get a solid EFI enivornment set up first and then work on booting.

[Urbz]

superhai, the command to write the bootsector doesn't work.

it says: "dumpbs: Invalid Parameters - When write boot sector, must specify file system format"

[Superhai]

superhai, the command to write the bootsector doesn't work.

it says: "dumpbs: Invalid Parameters - When write boot sector, must specify file system format"

 

sorry

a - missing

 

dumpbs -w -fat32 blkX Bs32.com

[Urbz]

ok i did it, but it still isn't booting up from hd.

[Superhai]

Some of the efi files have hardcoded pci ids. I found that out in the SataController.efi. But I tried to change it, but it won't get my ICH7 SATA to work, so I guess it is only meant for the ICH7M.

 

Radeon.efi have many PCI'IDs.

[Urbz]

hey superhai, both me and kiko tried out ur efildr and it just sits there and hangs for both our machines.

 

Any ideas?