-Archive- Macefix86 2006 -Archive-

[gwprod12]

First of all, I think you mean "Myopic", as in "Short-sighted". Yes, we currently have a BIOS bootloader (The darwin bootloader) that wasnt designed to actually run OS X. As I've said earlier, it leaves out quite a bit of functionality in establishing the kernel's environment, including the video context.

 

I may be wrong, but I've yet to hear of a scenario where the x1600 line of cards had video contexts created for all of it's displays (Darwin Bootloader only creates a limited context for primary, BootX creates a context for all available), and had the correct IORegistry entries for matching.

 

It's true that Target Disk Mode would have to be established in the firmware, since it is a functionality that exists under the operating system.

 

If we're able to alter the hardware and/or firmware to our specification to run this operating system natively, then great. But alternately, we have sources for the PPC boot loader, and while the low-level coding is different, the methods for solving the problem should ultimately be the same.

[bofors]

... I've yet to hear of a scenario where the x1600 line of cards had video contexts created for all of it's displays ...

What about GMA 950 boards with ADD2 cards? They run dual displays with no problem.

[gwprod12]

Couldn't tell you. I dont use my GMA950. The ADD2 card allows mirroring?

 

EDIT: My bad, I meant non-mirroring dual displays.

Anyways, it was just a suggestion.

 

I'm tinkering around with the darwin bootloader, altering it here and there to add functionality that i see in BootX. So far, nothing groundbreaking, but it does still boot the OS.

 

I dont really appreciate the discouragement though.

[bofors]

Couldn't tell you. I dont use my GMA950. The ADD2 card allows mirroring?

 

EDIT: My bad, I meant non-mirroring dual displays.

Extended desktop mode works too.

 

I dont really appreciate the discouragement though.

I am sorry if you feal discouraged, but you have helped me gain a better understanding of important EFI issues.

[gwprod12]

The functionality of Apple's drivers clearly rely apon different levels of firmware interaction, depending on the circumstance. I would surmise that the matching service has an easier time of working with GMA950 than it does working with x1600. Why that is? I dont know. What I do know is that a huge number of IORegistry entries for the x1600 exist on the iMac but not on the hackintosh. That could be because of Radeon.efi. Without the radeon kext source code, it would be impossible to know how much interaction it has with EFI, but the kernel's interaction is very limited. Back to the bootx example, BootX finds the device contexts (one of the missing symbols in the IORegistry on the hackintosh) and stores it in openfirmware for access at a later time. Clearly that information is important, because it's used to establish the display device, identify it, and match it with drivers. Again, darwin bootloader doesnt do this (BIOS doesnt really have this ability AFAIK). I havent looked at anyone's hackintosh with gma950 ioreg, so I cant comment on whether or not the pertinent information was found for gma950, but I would lay odds that it hasnt been.

 

Anyways, I'm going to keep on trucking and see if I can find out anything new.

[bofors]

A related issue is coming up. PC graphics cards do not work at all with OS X in the Mac Pro (yet), but they do work with Windows under BootCamp: http://forums.macrumors.com/showthread.php?t=223663

 

It appears that EFI fails to initialize PC graphics cards, while BootCamp BIOS succeeds.

[gwprod12]

It would be interesting to try a PPC Mac Video Cards in a Mac Pro (though I doubt they'd work) as well as trying Mac Pro video cards in a hackintosh (still waiting on that).

[Superhai]

Radeon.efi is the firmware for the x1600 cards, but i don't know if it is loaded from the card rom or the efi rom. And neither do I care. The case is that the initializing of the card is done by radeon.efi. The ATY_Wormy kext is what configures the card, and seem to be created by radeon.efi. And radeon.efi I believe are more modules in one, one are the uga driver.

 

I have checked around in the kernel source for 10.4.7 and there are many references to efi.

 

And this is efi_init() which is called inside machine_init() in the kernel, but there are lots more efi routines.

 

/* Map in EFI runtime areas. */
static void
efi_init(void)
{
boot_args *args = (boot_args *)PE_state.bootArgs;

kprintf("Initializing EFI runtime services\n");

do
{
	vm_offset_t vm_size, vm_addr;
vm_map_offset_t phys_addr;
EfiMemoryRange *mptr;
unsigned int msize, mcount;
unsigned int i;

msize = args->MemoryMapDescriptorSize;
mcount = args->MemoryMapSize / msize;

mptr = (EfiMemoryRange *)args->MemoryMap;
for (i=0; i < mcount; i++, mptr = (EfiMemoryRange *)(((vm_offset_t)mptr) + msize)) {
	if (((mptr->Attribute & EFI_MEMORY_RUNTIME) == EFI_MEMORY_RUNTIME) ) {
	vm_size = i386_ptob((uint32_t)mptr->NumberOfPages);
	vm_addr =   (vm_offset_t) mptr->VirtualStart;
	phys_addr = (vm_map_offset_t) mptr->PhysicalStart;
	pmap_map(vm_addr, phys_addr, phys_addr + round_page(vm_size),
		 (mptr->Type == kEfiRuntimeServicesCode) ? VM_PROT_READ | VM_PROT_EXECUTE : VM_PROT_READ|VM_PROT_WRITE,
		 (mptr->Type == EfiMemoryMappedIO)	   ? VM_WIMG_IO   : VM_WIMG_USE_DEFAULT);
	}
}

	if (args->Version > 1)
			panic("Incompatible boot args version %d\n", args->Version);

	kprintf("Boot args version %d revision %d mode %d\n", args->Version, args->Revision, args->efiMode);
	if (args->Revision >= 4 && args->efiMode == kBootArgsEfiMode64) {
			efi_set_tables_64((EFI_SYSTEM_TABLE_64 *) args->efiSystemTable);
	} else {
			efi_set_tables_32((EFI_SYSTEM_TABLE *) args->efiSystemTable);
	}
}
while (FALSE);

return;
}

 

(from model_dep.c)

[bofors]

The ATY_Wormy kext is what configures the card, and seem to be created by radeon.efi.

 

This is a critical issue to resolve.

 

Can you explain in detail what your observations that indicate this relationship between Radeon.efi and the ATY_Wormy.kext are?

[rogabean]

ATY_Wormy.kext you say?

 

I've actually been chasing my tail so to speak with this IOName elsewhere in OS X...

 

Radeon.efi creates this file? Once created can it be pulled from the Intel Mac or does it solely reside in memory?

[bofors]

Perhaps consideration of the Radeon.efi decompliation can help elucidate its function.

 

// Radeon.efi decompilation by Boomerang Win32-Alpha-0.2

int proc1(int param4, int param3, int param2, int param1);
void proc2(int param1);

// address: 0x1fd301ab
int main(int argc, char* argv[], char** envp) {
int local0; 		// r28{50}
int local1; 		// r28{38}
int local10; 		// r24
int local2; 		// r24{17}
int local3; 		// r28{27}
int local4; 		// r28{17}
int local5; 		// r27
int local6; 		// r29
int local7; 		// r30
int local8; 		// r31
int local9; 		// r25

*(int*)(%esp - 4) = local5;
*(int*)(%esp - 8) = local6;
*(int*)(%esp - 12) = local7;
*(int*)(%esp - 16) = local8;
*(int*)(%esp - 20) = 0x7880;
*(char*)(%esp - 24) = global2[argc];
local2 = proc1(*(int*)(%esp - 24), 0x7880, local9, local6); /* OUT: local4 */
*(int*)(local4 - 4) = 0x7910;
*(char*)(local4 - 8) = global2[argc];
local10 = proc1(*(int*)(local4 - 8), 0x7910, local9, 0x7910); /* OUT: local3, local6 */
*(int*)(local3 - 4) = 0;
*(int*)(local3 - 8) = 0x7904;
*(char*)(local3 - 12) = global2[argc];
local1 = proc2(*(int*)(local3 - 12));
*(int*)(local1 - 4) = local2 & -2;
*(int*)(local1 - 8) = 0x7880;
*(char*)(local1 - 12) = global2[argc];
local0 = proc2(*(int*)(local1 - 12));
*(int*)(local0 - 4) = local10 & -2 | 2;
*(int*)(local0 - 8) = local6;
*(char*)(local0 - 12) = global2[argc];
proc2(*(int*)(local0 - 12));
return 0;
}

// address: 0x1fd2da23
int proc1(int param4, int param3, int param2, int param1) {
*(int*)(%esp - 4) = param1;
*(int*)(%esp - 8) = param2;
*(int*)(%esp - 8) = 0;
*(int*)(%esp - 12) = %esp - 8;
*(int*)(%esp - 16) = 1;
*(int*)(%esp - 20) = 0;
*(int*)(%esp - 24) = param3;
*(int*)(%esp - 28) = 2;
*(int*)(%esp - 32) = 2;
*(int*)(%esp - 36) = param4;
(*global0[param4])(%pc, param4, 2, 2, param3, 0, 1, %esp - 8, 0, param1, param4, %esp - 4, LOGICALFLAGS32(0), LOGICALFLAGS32(0));
return *(int*)(param1 - 4);	/* *(int*)param1 */
}

// address: 0x1fd2da06
void proc2(int param1) {
*(int*)(%esp - 4) = %esp + 12;
*(int*)(%esp - 8) = 1;
*(int*)(%esp - 12) = 0;
*(int*)(%esp - 16) = param1;
*(int*)(%esp - 20) = 2;
*(int*)(%esp - 24) = 2;
*(int*)(%esp - 28) = param1;
(*global1[param1])(%pc, param1, 2, 2, param1, 0, 1, %esp + 12, param1);
return;
}

 

To start with, I think we should ask does this decompilation of Radeon.efi appear complete and correct?

 

Next, what does "%esp" represent?

 

Then, I assume *global0[param4] and *global1[param1] represent global function. But what exactly are they? Can we find there source or assembly code?

[joblo10]

Back to the bootx example, BootX finds the device contexts (one of the missing symbols in the IORegistry on the hackintosh) and stores it in openfirmware for access at a later time. Clearly that information is important, because it's used to establish the display device, identify it, and match it with drivers. Again, darwin bootloader doesnt do this (BIOS doesnt really have this ability AFAIK).

 

This is also what I understand for video devices. I have been tracking all sort of different weird issues with the ATI drivers and there's a lot of misconfigured things because we don't have a good boot initialization. For example, why people have two IOPCIDevices created for each ATI head, when it's supposed to have one Parent and two children(ATY_Wormy@0 and ATY_Wormy@1, or ATY_Tracer for my X850). That problem can be fixed, but not easily, because to make it even more complicated, each IOPCIDevice has half the VRAM divided and set in the pci BARs(only true for < ATIRadeonX1000). This begins to be hard to fix past the boot process. I truly encourage you to go ahead

[bofors]

Here is related boot loader thread where Tom H is describing his work:

 

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

 

It appears that he has a debugger working too!

[bofors]

However, in heavily modifying boot.efi, or inspecting it very closely, we may be able to find dependencies: <i>why</i> it isn't working on our systems.

 

For this reason, Boot.efi is essential. It can tell us a lot about which modules we need, and which we don't. What's controlled by the OS and what isn't.

 

I think it would be a mistake to ignore the kernel (and its source code) in favor of boot.efi analysis.

 

Our goal should be to use boot.efi "as is" and only bypass the kernel's TPM calls as needed.

 

I think we need to compile the new kernel source and either use "print" commands or a debugger to determine where the problemsl with boot.efi are.

 

Here is a related boot loader thread where Tom H is describing his work:

 

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

 

It appears that he has a debugger working too!

[Superhai]

Next, what does "%esp" represent?

 

ESP is the CPU stack pointer, but it is a register and can be anything really.

 

That source you have there don't make any sense at all.

[Superhai]

ATY_Wormy.kext you say?

 

I've actually been chasing my tail so to speak with this IOName elsewhere in OS X...

 

Radeon.efi creates this file? Once created can it be pulled from the Intel Mac or does it solely reside in memory?

 

Why I believe it is created by radeon.efi is when I look thru the file with a hex editor. And I believe it is solely in memory. I am not sure if it is a kext in that sense, but it got inserted into the iokit tree.

[bofors]

That source you have there don't make any sense at all.

 

Do you want to post the assembly so we can start annotating it?

 

Why I believe it is created by radeon.efi is when I look thru the file with a hex editor.

Can you post the code you think is relevant?

[bofors]

Attached is a block of text found (via a hexeditor, which is in an a strange encoding that this board does accept) near the end of Radoen.efi, that Superhai has been referencing. It seems to be something like a parameter list. The references made in it support Superhai's assertation that Radeon.efi is more than just a UGA driver.

 

Specically, Radeon.efi appears to be some kind of a shell for four other EFI drivers:

 

(1) ~\radeon_1_1.c

 

(2) ~\radeoncomponentname.c01.00.068DeviceIDmodelATY

 

(3) ~\radeonapple.c1compatibledisplayATY

 

(4) ~\radeonuga.cATY

 

 

While (1) and (4) seem to be associated with a UGA driver, (2) and (3) are associated with a variety of parameters that one would think goes far beyond what it is need for a UGA driver.

RadeonText.txt

[bofors]

Does anybody know what "ATY" means? I have been treating it as "ATI" but there must be some difference.

[Suspect]

ATY is ATI's stock symbol. ATYT is ATI USA's stock symbol.

[nekton]

Just read this:

 

I personally e-mailed Rob at BareFeats and suggested he try installing a PC GPU in a Mac Pro, he first responded; ATI engineers confirmed that you can NOT use a PC graphics card. The Mac Pro requires a special firmware. And those cards are not compatible with the G5 with PCIe slots. After another exchange he wrote, This is what the ATI engineer said: "The Mac Pro cards do require special EFI firmware, so unfortunately a standard "PC" card won't work." His article also says this; http://www.barefeats.com/quad05.html

 

Is ATi just spreading FUD or do ATi video cards really require a special efi firmware flash? Is this efi stored in onboard ROM or loaded from the OS at boot? What the enigineer says is open to interpretation and seems to imply that efi is onboard. Could we test this by downloading the "efi firmware" from a Mac ATi (or even NVidia in a Mac Pro) card and then loading it onto a standard PC GPU?

[enb14]

Remember that mac video cards have 128K ROM and PC video cards have 64k so you have to find a card with 128K ROM

[Superhai]

Is ATi just spreading FUD or do ATi video cards really require a special efi firmware flash? Is this efi stored in onboard ROM or loaded from the OS at boot? What the enigineer says is open to interpretation and seems to imply that efi is onboard. Could we test this by downloading the "efi firmware" from a Mac ATi (or even NVidia in a Mac Pro) card and then loading it onto a standard PC GPU?

 

Well I still believe radeon.efi is the firmware or part of it... so i believe it is true.

[cyclonefr]

about the ATY WORMY .kext, in fact the macpro 10.4.7 drivers contains a new ATINDRV.kext which include ATYWORMY.kext = works as fine as ATINDRV 10.4.5 on my X1600PRO, and other ATY*.* like ATYSAPHIR.kext etc

get a look at it

[Superhai]

about the ATY WORMY .kext, in fact the macpro 10.4.7 drivers contains a new ATINDRV.kext which include ATYWORMY.kext = works as fine as ATINDRV 10.4.5 on my X1600PRO, and other ATY*.* like ATYSAPHIR.kext etc

get a look at it

 

yes, i know. but it is just a replacement of atindrv.kext, it is not the driver who sits between display and atindrv.