ProjectOSX

Welcome Guest!

Returning User? Login here.

Want membership privileges? Register here.

67 Pages V  « < 48 49 50 51 52 > »   
Start a new topic Add Reply
> How To Make Efi Bootloader
dmazar
post Apr 7 2012, 04:47 PM
Post #981
With some new knowledge and experience, I tried again to overcome AMI APTIO memory problem. The same method as before: give boot.efi some other memory and then to fix it after it.

I've debugged it again in VBox and it turned out that it requires bootArgs pointer fixes, runtime services fix (assigning virtual addresses and defragmentation) and some small fix in device tree (bootCLUT and that other pointer). And OSX booted fine in VBox. I've also added shrinking of mem map, since this is needed in APTIO and all works fins in VBox. Debuging here is easy, since I can capture serial port output and do memory dumps.

Anyway, the same stuff does not work on AMI APTIO. There's another moment here in mem map: MemoryMappedIO. boot.efi accounts this space when allocating space for defragmented run time area, but I think this is wrong. I think this area just needs virtual address assigned but no relocation to kernel RT area. Any thoughts about MMIO?

When I try to run this stuff, system just stops for a few seconds and then restarts. I can not debug it since I have no serial port. There is a trick: I can lie (again) to boot.efi when it calls ExitBootServices and just return EFI_SUCCESS without actually calling this exit and boot.efi continues just fine. Jumps to kernel, and this jump leads back to my code where I can print to screen with boot services. All looks good here - the same as in VBox, but I can not debug code that calls SetVirtualAddressMap and after it. So, I do not see any advance here without serial port or some library for printing to video card directly.

The King, are you able to debug that kind of stuff on real board with serial port?

Note: I wanted to do this once again, since it looked that it does not require too much of new work (and it did not in VBox). But, I think this approach is not good since it depends on boot.efi internal working, which can change.

I think the proper way to overcome this memory issue is to run boot.efi in it's own virtual address space where all needed memory space can be free. But this requires some work: making a thin proxy between boot.efi and UEFI that must switch between boot.efi address mapping and UEFI address mapping whenever boot.efi calls UEFI. So, overriding all UEFI calls: boot and runtime services plus all protocols that boot.efi is using (in the same way as FSInject in Clover overrides file system protocol). Plus, maybe, overriding timer interrupt UEFI is using (or maybe it can be disabled while boot.efi is running?) and plus some other memory mambo jumbo stuff. I'll try to go this way, slowly, in my free time, but this requires quite amount of work.

Anyway, once this issue will be resolved (err ... if it will be), we will need to make Clover's efi part working in UEFI. Currently it does not work.
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot
STLVNUB
post Apr 7 2012, 06:20 PM
Post #982
QUOTE (dmazar @ Apr 8 2012, 02:47 AM) *
I've debugged it again in VBox and it turned out that it requires bootArgs pointer fixes, runtime services fix (assigning virtual addresses and defragmentation) and some small fix in device tree (bootCLUT and that other pointer). And OSX booted fine in VBox. I've also added shrinking of mem map, since this is needed in APTIO and all works fins in VBox. Debuging here is easy, since I can capture serial port output and do memory dumps.

How are you using VBox to debug??, sounds interesting.
Well I know how, just want to know your procedure, using Iso or what??
Azrock Z77 Pro3, G1610 AMD HD7750 Clover/Ozmosis
Toshiba A660-0MR00R I7-7740QM GT330M 8 Gig Clover

STLVNUB
post Apr 7 2012, 06:22 PM
Post #983
Hey Slice, whats with the bug in 352, can't build here
src/edk2/Clover/rEFIt_UEFI/Platform/cpu.c:295:29: error: 'CPU_STRUCTURE' has no member named 'BusRatioMax'
Azrock Z77 Pro3, G1610 AMD HD7750 Clover/Ozmosis
Toshiba A660-0MR00R I7-7740QM GT330M 8 Gig Clover

dmazar
post Apr 7 2012, 07:28 PM
Post #984
QUOTE (STLVNUB @ Apr 7 2012, 08:20 PM) *
How are you using VBox to debug??, sounds interesting.
Well I know how, just want to know your procedure, using Iso or what??

Making ISO image with shell as /efi/boot/bootX64.efi and my drivers on it. And then booting VBox in efi mode with this ISO as a CD. This loads shell so I can start drivers and boot.efi from there. Maybe it's possible with some fat32 partition on a host drive used as raw device in VBox, but did not try. I wish there is an easier way.

From the code: using DebugPrint() from DebugLib (BaseDebugLibSerialPort) which prints to serial port. Can be used even after ExitBootServices is called. Plus: VBox machine configured to capture serial port to local file. Very handy.

VBox has integrated debugger (<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>). I can examine memory, regs and do some disassembling from there and make memory dump with writecore. I think it's possible to connect with MS debugger to it, but I'm not familiar with that.

This post has been edited by dmazar: Apr 7 2012, 07:32 PM
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot
THe KiNG
post Apr 7 2012, 09:13 PM
Post #985
QUOTE (dmazar @ Apr 7 2012, 07:47 PM) *
The King, are you able to debug that kind of stuff on real board with serial port?

Hi,

Nice to see you are still working on this.

AFAIK I have no UEFI board now, ASRock sh*t I had crushed third time and cannot RMA it(did twice).
Even I had it, I still don't know how to debug over serial.

I am waiting for z77 boards to show up then I can help you if you tell me how biggrin.gif

But here is an idea(not mine): What if we(read you) make a small PEI driver(and include it in original frmware) where we alloc with some unimportant garbage the required boot.efi ranges then we free them OnExitBootServices?

Agree about Clover/modified rEFIt does not work on UEFI, tried before board died.

Another idea is to ask ASUS to fix this for us, since Apple asked Pegatron to not produce ASUS zenbook(and they obey) I don't think there is much love b/w Apple and ASUS now...
Who knows maybe we have luck tongue.gif
STLVNUB
post Apr 7 2012, 09:21 PM
Post #986
QUOTE (dmazar @ Apr 8 2012, 05:28 AM) *
Making ISO image with shell as /efi/boot/bootX64.efi and my drivers on it. And then booting VBox in efi mode with this ISO as a CD. This loads shell so I can start drivers and boot.efi from there. Maybe it's possible with some fat32 partition on a host drive used as raw device in VBox, but did not try. I wish there is an easier way.

From the code: using DebugPrint() from DebugLib (BaseDebugLibSerialPort) which prints to serial port. Can be used even after ExitBootServices is called. Plus: VBox machine configured to capture serial port to local file. Very handy.

VBox has integrated debugger (<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>). I can examine memory, regs and do some disassembling from there and make memory dump with writecore. I think it's possible to connect with MS debugger to it, but I'm not familiar with that.

Ok, will have to do same, thanks
Azrock Z77 Pro3, G1610 AMD HD7750 Clover/Ozmosis
Toshiba A660-0MR00R I7-7740QM GT330M 8 Gig Clover

dmazar
post Apr 7 2012, 09:31 PM
Post #987
QUOTE (THe KiNG @ Apr 7 2012, 11:13 PM) *
But here is an idea(not mine): What if we(read you) make a small PEI driver(and include it in original frmware) where we alloc with some unimportant garbage the required boot.efi ranges then we free them OnExitBootServices?

An interesting idea. I need to read some docs to see what needs to be done. But, I doubt I'll try to flash my bios. Never done it before and can not afford to loose the board.

Regarding previous issue with UEFI - isolated the problem in call to SetVirtualAddressMap. This hangs (actually restarts). Works fine in VBox. If I remove that call, I get kernel KP (efi system table not fixed).
CODE
available  0000000100000000-000000011F7FFFFF  000000000001F800 000000000000000F
MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000001
MemMapIO   00000000FF000000-00000000FFFFFFFF  0000000000001000 8000000000000001


I have 4GB memory, and this available 100000000-11F7FFFFF also confuses me. Plus MMIO.
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot
THe KiNG
post Apr 7 2012, 09:52 PM
Post #988
QUOTE (dmazar @ Apr 8 2012, 12:31 AM) *
But, I doubt I'll try to flash my bios. Never done it before and can not afford to loose the board.

I can be the 'guinea pig' usual I mess/flash BIOS at least 5 time/day(LOL), but on ASUS is easy, BIOS is on socket so easy to flas with ~20$ flashing tool from Ebay, also recent they introduced flash back technique, dunno if you have it on your board, so bios can be flashed back even w/o cpu on board lol.
Slice
post Apr 8 2012, 04:50 AM
Post #989
QUOTE (STLVNUB @ Apr 7 2012, 10:22 PM) *
Hey Slice, whats with the bug in 352, can't build here
src/edk2/Clover/rEFIt_UEFI/Platform/cpu.c:295:29: error: 'CPU_STRUCTURE' has no member named 'BusRatioMax'

Yes, I know. Rev354 is working.
Thank you for the new DarwinDumper. Very good!.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8.4), OS⌘10.9.2, OS⌘ 10.7.5 Clover FakeSMC_plugins_3.3.1 Realtek LAN v3.1.2
Slice
post Apr 8 2012, 04:55 AM
Post #990
QUOTE (dmazar @ Apr 8 2012, 01:31 AM) *
An interesting idea. I need to read some docs to see what needs to be done. But, I doubt I'll try to flash my bios. Never done it before and can not afford to loose the board.

Regarding previous issue with UEFI - isolated the problem in call to SetVirtualAddressMap. This hangs (actually restarts). Works fine in VBox. If I remove that call, I get kernel KP (efi system table not fixed).
CODE
available  0000000100000000-000000011F7FFFFF  000000000001F800 000000000000000F
MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000001
MemMapIO   00000000FF000000-00000000FFFFFFFF  0000000000001000 8000000000000001


I have 4GB memory, and this available 100000000-11F7FFFFF also confuses me. Plus MMIO.

PCI bus occupies some address space while not requires physical RAM. So some BIOSes can relocate a part of RAM from PCI addresses to upper unused space. 100000000-11F7FFFFF in your case.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8.4), OS⌘10.9.2, OS⌘ 10.7.5 Clover FakeSMC_plugins_3.3.1 Realtek LAN v3.1.2
STLVNUB
post Apr 8 2012, 05:46 AM
Post #991
QUOTE (Slice @ Apr 8 2012, 02:50 PM) *
Yes, I know. Rev354 is working.
Thank you for the new DarwinDumper. Very good!.

My pleasure.

Just need blackosx to improve on the mbr dump, i really think it needs partition/slice dump as well.
@blackosx, hint hint
Azrock Z77 Pro3, G1610 AMD HD7750 Clover/Ozmosis
Toshiba A660-0MR00R I7-7740QM GT330M 8 Gig Clover

dmazar
post Apr 8 2012, 02:50 PM
Post #992
QUOTE (Slice @ Apr 8 2012, 06:55 AM) *
PCI bus occupies some address space while not requires physical RAM. So some BIOSes can relocate a part of RAM from PCI addresses to upper unused space. 100000000-11F7FFFFF in your case.

I have a lack of knowledge here, but this sounds to me as memory mapped io. Is it? Why is it marked as conventional free memory?

By the way, got new idea hot to debug on board uefi - I have NVRAM there and could probably write debug stuff in there wit simple RT->SetVariable and then read it in shell after restart. Will have to try it when I return home. tongue.gif
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot
Slice
post Apr 8 2012, 06:39 PM
Post #993
QUOTE (dmazar @ Apr 8 2012, 06:50 PM) *
I have a lack of knowledge here, but this sounds to me as memory mapped io. Is it? Why is it marked as conventional free memory?

PCI bus occupies addresses 0xffffffff while you have a conventional memory that also can occupies it. So BIOS remap this conventional memory to 10000000.
It is really free memory.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8.4), OS⌘10.9.2, OS⌘ 10.7.5 Clover FakeSMC_plugins_3.3.1 Realtek LAN v3.1.2
blackosx
post Apr 9 2012, 05:35 PM
Post #994
QUOTE (STLVNUB @ Apr 8 2012, 06:46 AM) *
Just need blackosx to improve on the mbr dump, i really think it needs partition/slice dump as well.

I've built upon DarwinDumper_v1.2e and added a revised boot sector dump.
I'm sure it can be improved and made more efficient but for now it works.

EDIT: Ooops. Spotted a problem with the posted version.
Removed for now and will look at a fix when I get some more time.

This post has been edited by blackosx: Apr 9 2012, 06:46 PM
10.9.4 | Asus Maximus IV Gene-Z (PMpatched BIOS 3603) | i7-2600 3.40GHz | SSDT from Sam's ssdtPRGen.sh | Radeon 5770 1GB | 4GB DDR3
Booting with either Clover 2716 | Chameleon r2375 | RevoBoot v1.5.40 | Ozmosis 0894M
STLVNUB
post Apr 10 2012, 04:15 AM
Post #995
QUOTE (blackosx @ Apr 10 2012, 03:35 AM) *
I've built upon DarwinDumper_v1.2e and added a revised boot sector dump.
I'm sure it can be improved and made more efficient but for now it works.

EDIT: Ooops. Spotted a problem with the posted version.
Removed for now and will look at a fix when I get some more time.

Thanks Blackosx, this tool will come in handy
Azrock Z77 Pro3, G1610 AMD HD7750 Clover/Ozmosis
Toshiba A660-0MR00R I7-7740QM GT330M 8 Gig Clover

blackosx
post Apr 10 2012, 12:19 PM
Post #996
QUOTE (STLVNUB @ Apr 10 2012, 05:15 AM) *
Thanks Blackosx, this tool will come in handy

Here you go. Try this version.
DarwinDumper_v1.2h

Let me know if you have any issues.

This post has been edited by blackosx: Apr 10 2012, 05:31 PM
10.9.4 | Asus Maximus IV Gene-Z (PMpatched BIOS 3603) | i7-2600 3.40GHz | SSDT from Sam's ssdtPRGen.sh | Radeon 5770 1GB | 4GB DDR3
Booting with either Clover 2716 | Chameleon r2375 | RevoBoot v1.5.40 | Ozmosis 0894M
dmazar
post Apr 10 2012, 03:32 PM
Post #997
QUOTE (dmazar @ Apr 8 2012, 04:50 PM) *
By the way, got new idea hot to debug on board uefi - I have NVRAM there and could probably write debug stuff in there wit simple RT->SetVariable and then read it in shell after restart. Will have to try it when I return home.

Just an update on AMI APTIO booting: this debugging with NVRAM works fine. The stuff I am sending to SetVirtualAddressMap() is ok (in the sense that it is as I wanted), but this call restarts the system. I have traced it when it notifies RT drivers about virtual address change and drivers are calling ConvertPointer() - and it stops/restarts in some driver. This happens no matter what virtual addresses I set in mem map. Except in one case: when I leave identity mapping (physical addr equals virtual) - in that case call ends with success.

My only conclusion now is that SetVirtualAddressMap() on AMI APTIO expects actual virtual page map to be set up already. And that some runtime drivers are trying to use new virtual addresses as soon as they are notified about them.

If I understood correctly, in Linux this works like this: Linux booter does not call SetVirtualAddressMap(), but this call is executed from kernel after new page mapping is already established. In our case (OSX), it is different: boot.efi calls SetVirtualAddressMap() to prepare RT drivers, but kernel establishes new page map later.

If this is true, that RT drivers on APTIO need proper mem page map, then any method we mentioned so far for booting OSX (PEI driver, fixing after boot.efi, running boot.efi in it's own virtual addr space) will come to this same issue.

Well, the only way to test it is to try to build new page mapping where those RT areas will be mapped to virtual addresses as OSX needs and then to call SetVirtualAddressMap(). So, more reading needed ...
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot
blackosx
post Apr 10 2012, 03:53 PM
Post #998
QUOTE (dmazar @ Apr 10 2012, 04:45 PM) *
There are 2 versions of it - initial one, and the latest version with few lines removed. Maybe this is the issue?

Are there? Thanks for the note dmazar.
I'm making a comparison from the one supplied in the latest package with Clover rev354.
I'm comparing the bytes shown in the image below.



Byte 0x3F shows differences as:
A3 for Chameleon boot1h
A2 for Clover boot1h
66 for Clover boot1h2
Could the other boot1h2 have a different value?

EDIT: I've checked the version from r350 and that's the same. So maybe it was posted earlier?

EDIT2: Looking at boot1altV3 I see a difference in bytes 0x61 and 0x62 when compared to boot1h2. This is now accounted for in DarwinDumper_v1.2j.zip , but it still doesn't explain why the detection of Slice's partition boot sector failed. I'll wait until I see Slice's dump.

This post has been edited by blackosx: Apr 11 2012, 01:52 PM
10.9.4 | Asus Maximus IV Gene-Z (PMpatched BIOS 3603) | i7-2600 3.40GHz | SSDT from Sam's ssdtPRGen.sh | Radeon 5770 1GB | 4GB DDR3
Booting with either Clover 2716 | Chameleon r2375 | RevoBoot v1.5.40 | Ozmosis 0894M
dmazar
post Apr 10 2012, 05:25 PM
Post #999
QUOTE (blackosx @ Apr 10 2012, 05:53 PM) *
Byte 0x3F shows differences as:
A3 for Chameleon boot1h
A2 for Clover boot1h
66 for Clover boot1h2
Could the other boot1h2 have a different value?

Newer version also has 0x66 as byte 0x3F. So, it does not matter. Sorry for confusion.

Source boot1altV3.s contains newer version. boot1h2 is compiled from older version. But since the functionality is the same, it's not important.

This post has been edited by dmazar: Apr 10 2012, 05:25 PM
HW: Asus P8P67-M, Intel Core i5-2300, 4GB, XFX HD-567X-ZHH3 SW: SL, L, ML: Clover UEFI boot
blackosx
post Apr 10 2012, 05:28 PM
Post #1000
Thanks dmazar. I've just checked and updated my post above ^^^ as you were posting tongue.gif

This post has been edited by blackosx: Apr 10 2012, 05:28 PM
10.9.4 | Asus Maximus IV Gene-Z (PMpatched BIOS 3603) | i7-2600 3.40GHz | SSDT from Sam's ssdtPRGen.sh | Radeon 5770 1GB | 4GB DDR3
Booting with either Clover 2716 | Chameleon r2375 | RevoBoot v1.5.40 | Ozmosis 0894M

67 Pages V  « < 48 49 50 51 52 > » 
Add Reply Start a new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members: