Clover General discussion

[Badruzeus]

Sometimes..   

[apianti]

The macOS either loads prelinkedkernel or booter kexts. As we want to use prelinkedkernel for speed but also have kext injection, Clover patches the conditional jump so both run. cecek is suggesting this should not happen when there are no kexts to inject.

 

OMG, how on earth did I forget about this.... I actually just realized that we could probably force the kernel to be loaded through a booter extension to boot without caches....

 

if an icon missing then clover used some common icon. I don't think embedded theme should be advanced. If user wants beauty theme he can choose it.

 

Depends on what the outcome is, if it looks messed up, maybe it should be fixed, if it's merely a cosmetic, I expected this but instead saw this, it's not a big deal. Unless it's like showing Windows entries for macOS... lol

 

No, it is too large. Clover legacy (boot file) is restricted in size. All drivers it can load external.

 

What is the restriction on the size though? Isn't it arbitrary to fit in some sort of firmware ROM size? Why can't we increase the size since it will always be loaded from disk?

[mhaeuser]

OMG, how on earth did I forget about this.... I actually just realized that we could probably force the kernel to be loaded through a booter extension to boot without caches....

 

Why would you want to do that though?

[apianti]

Why would you want to do that though?

 

To boot without caches...? I said that.

 

EDIT: Like it seems that if there is no kernel cache then there is expected to be booter extension that somehow rectifies this...? Why else would it be an if/else..?

[mhaeuser]

To boot without caches...? I said that.

 

"To do that" is not an answer to the question "why do that"

prelinkedkernel is speedier and may have a lesser footprint than linking etc. at runtime.

[apianti]

"To do that" is not an answer to the question "why do that"

prelinkedkernel is speedier and may have a lesser footprint than linking etc. at runtime.

 

Well one reason is that booting without caches used to be an easy workaround to the memory allocation problem. Because the kernel has control of memory by the time it's loading most stuff. Also getting a kext out of the cache that causes problems. Pretty much the same reason the feature has always existed. Also patching some kexts fails due to prelink info not being directly placed in the kernelcache image, someone showed that a little while ago... Too lazy to look for it now.

 

EDIT: And I sure know that the prelinked kernelcache is going to be much faster than booting without caches but that's not the point when you need the feature. It's mainly about just being able to boot to fix stuff so you don't need to do that stuff again.

 

EDIT2: Haha... C R A P apparently needs to be censored. Jeez maybe you guys should just start random word censorship where every day a new random word gets censored. Then we all have no idea what any words mean any more cause we're all soooooooo offended by words not directed at anything but inanimate objects and terrible ideas.

[mhaeuser]

Well one reason is that booting without caches used to be an easy workaround to the memory allocation problem. Because the kernel has control of memory by the time it's loading most stuff. Also getting a kext out of the cache that causes problems. Pretty much the same reason the feature has always existed. Also patching some kexts fails due to prelink info not being directly placed in the kernelcache image, someone showed that a little while ago... Too lazy to look for it now.

 

Regarding memory alloc: I suppose it worked with no-cache-boot because the prelink sections are loaded at a predefined address while booter kexts are allocate of the 'booter memory heap'. I don't think this will fix it because it's boot.efi throwing the errors while loading the kernel, except ofc if you want to interfere with boot.efi loading the kernel, patching it on file-read-level.

 

Regarding kext out of kextcache: Was it ever tested trashing the kext's info in __prelink_info and also trashing its binary data in __prelink_text? Might work, idk.

 

Regarding patching: Yeah, above could be done for kexts that need such patching. Thought how would it interfere with data loaded from that plist cache that prelinked loads? idk, I'm not a XNU guru. Maybe Zenith/vit know more on this?

[apianti]

Regarding memory alloc: I suppose it worked with no-cache-boot because the prelink sections are loaded at a predefined address while booter kexts are allocate of the 'booter memory heap'. I don't think this will fix it because it's boot.efi throwing the errors while loading the kernel, except ofc if you want to interfere with boot.efi loading the kernel, patching it on file-read-level.

 

That's exactly how booting without caches works, it blocks the kernelcache through filesystem injection. This used to automatically load the kernel, it now does nothing and crashes, probably as I said because it expects a booter extension to take such action.

 

EDIT: Just realized there is still no kernel loaded, so it wouldn't matter. I wonder what would happen if the kernelcache was actually redirected to just the kernel through file system injection would work.

 

Regarding kext out of kextcache: Was it ever tested trashing the kext's info in __prelink_info and also trashing its binary data in __prelink_text? Might work, idk.

 

I've tried several ways to block from the cache, including destroying the kexts like that, but that crashes, the most is that you can get is to force relink the kext, I think, but that may not even be possible anymore as I haven't tried recently. But maybe someone else may know a more precise solution. 

 

Regarding patching: Yeah, above could be done for kexts that need such patching. Thought how would it interfere with data loaded from that plist cache that prelinked loads? idk, I'm not a XNU guru. Maybe Zenith/vit know more on this?

 

I think Zenith might have been the one who brought attention to the prelinked information not being directly inserted into the cache and instead into archives loaded later. Best case, the prelinked would not be used so there would be no loading of the archive for the kext(s). However, not sure, I have a feeling that if you can get it to even reload to relink it should be fine.

[gujiangjiang]

HD5300 in laptop must use 1024x768 to boot into macOS?

7:263  0:000  Intel HD Graphics 5300 [8086:161E] :: PciRoot(0x0)\Pci(0x2,0x0)
7:263  0:000    Found XGA Display - 4:3 :: Width=1024 Height=768
7:264  0:000    Beginning DualLink auto-detection
7:264  0:000    Low Resolution Display
7:264  0:000    AAPL00,DualLink: not used
7:264  0:000    FakeID Intel GFX: not set
7:264  0:000    ig-platform-id: not set
7:264  0:000    Beginning Intel GFX auto-detection with ACPI injection
7:264  0:000    Found FakeID Intel GFX = 0x161E8086
7:264  0:000    Found ig-platform-id = 0x16260006
7:264  0:000  Intel GFX revision  = 0x9
7:264  0:000   detected codec: 8086:2808
7:264  0:000   detected codec: 10EC:0269
7:264  0:000  stringlength = 1856
7:264  0:000  CurrentMode: Width=1024 Height=768

Now it must set with 4:3 and Width=1024 Height=768 can boot into macOS but boot logo are not very well.

 

But i laptop use 1536x2048 resolution but i cant set this.

 

When i set CloverGUI to 1536x2048 it cant boot into macOS.

 

And when i set CloverGUI to 2048x1536 but Clover cant recognize this resolution or ratio like 3:4.

 

Now i must set CloverGUI to 1024x768 to make it boot into macOS but i hope i can use 2048x1536 or 1536x2048 to boot with Clover.

 

Thanks.

 

[telepati]

Guys is this the right place for HorizontalSyncPulseWidth? 

 

[Slice]

 

 

What is the restriction on the size though? Isn't it arbitrary to fit in some sort of firmware ROM size? Why can't we increase the size since it will always be loaded from disk?

AFAIK the size limited by loading process, see efildr.c sources. May be it assumes 16 bit Real Mode.

Also the keyword is "low-ebda" reducing the size from 483kb to 450kb. We can reduce the size but hardly increase.

[wyhtc]

When I use official osxaptiov2 have no problem.

 

I will test more and give some feedback.

 

 

从我的 iPhone 发送，使用 Tapatalk

肛肛

[Zenith432]

boot6 or boot7 are loaded by the stage-1 bootloader in 16-bit real mode at address 0x20200, so they must fit in the space up until the EBDA.  The startup code at 0x20200 then switches to long mode, copies EFILDR to address 0x10000 and jumps to its entry point.  EFILDR lzma-decompresses DxeIpl and DxeCore into high memory, and also the firmware-volume.

Loading from disk into memory above 1MB in 16-bit real mode is an int 13 extension which is not present in all bioses, so cannot be relied on.

 

As for prelinked kernel - kexts that are necessary for booting console mode have their iokit personalities cached in __PRELINK_INFO.  All other kexts in prelinked do not have their iokit personalities cached in the prelinked.  The personalities are loaded from a separate cache on the root filesystem once available.

[apianti]

AFAIK the size limited by loading process, see efildr.c sources. May be it assumes 16 bit Real Mode.

Also the keyword is "low-ebda" reducing the size from 483kb to 450kb. We can reduce the size but hardly increase.

 

I'm aware of the limitations of real mode. But my question was not about real mode... Why can we not create a multiple firmware volume firmware? OVMF does this so that nvram can be loaded read-write while the rest is read-only. I believe this would allow for a skeleton first volume that loads a much larger second volume, removing the need for size restriction.

 

boot6 or boot7 are loaded by the stage-1 bootloader in 16-bit real mode at address 0x20200, so they must fit in the space up until the EBDA.  The startup code at 0x20200 then switches to long mode, copies EFILDR to address 0x10000 and jumps to its entry point.  EFILDR lzma-decompresses DxeIpl and DxeCore into high memory, and also the firmware-volume.

Loading from disk into memory above 1MB in 16-bit real mode is an int 13 extension which is not present in all bioses, so cannot be relied on.

 

Yes, I was referring to creating a smaller firmware volume that is loaded initially that then loads a second firmware volume with additional stuff which would allow for any size and not have any size restrictions.

 

As for prelinked kernel - kexts that are necessary for booting console mode have their iokit personalities cached in __PRELINK_INFO.  All other kexts in prelinked do not have their iokit personalities cached in the prelinked.  The personalities are loaded from a separate cache on the root filesystem once available.

 

Yes, and these can't be patched? So that's a problem that would be solved by without caches. Like what about sound kexts?

[Zenith432]

Yes, I was referring to creating a smaller firmware volume that is loaded initially that then loads a second firmware volume with additional stuff which would allow for any size and not have any size restrictions.

The existing firmware volume already has just the bare necessities to access disks and filesystems. Everything else can be loaded as .efi from driver64 or drivers64UEFI. No need for a 2nd firmware volume.

 

 

Yes, and these can't be patched? So that's a problem that would be solved by without caches. Like what about sound kexts?

What can be patched is what's inside prelinked kernel, and what's loaded as booter kexts. There is an existing solution for anything that can't be patched which is to put it on kexts/Other to be loaded as a booter kext - which makes it patchable. Booting without caches does not provide anthing useful.

[Slice]

boot1f32 works in Real mode and can't load large firmware.

But first firmware contains FS driver and Sata driver in EFI framework and it is CloverEFI.

But we can do intermediate boot loader which contains FS driver using legacy INT13 calls but in Protected mode. This second stage bootloader will be able to load large EFI Firmware.

[apianti]

The existing firmware volume already has just the bare necessities to access disks and filesystems. Everything else can be loaded as .efi from driver64 or drivers64UEFI. No need for a 2nd firmware volume.

 

That's 100% not the case, the firmware has an immense amount of stuff that is not needed to start such as nvram, graphics, console, etc. Second, a firmware volume is going to be much faster than loading individual drivers, and won't require reconnecting again, like loading from folder does. I'd rather not load drivers from a folder when they could be initialized in the firmware much quicker and with less reading from disk. Not to mention that I hope for the v2 GUI to be dead soon.

 

What can be patched is what's inside prelinked kernel, and what's loaded as booter kexts. There is an existing solution for anything that can't be patched which is to put it on kexts/Other to be loaded as a booter kext - which makes it patchable. Booting without caches does not provide anthing useful.

 

Injecting a kext that is already prelinked does nothing, it is discarded. What do you propose for patches needed for the installer?

 

boot1f32 works in Real mode and can't load large firmware.

But first firmware contains FS driver and Sata driver in EFI framework and it is CloverEFI.

But we can do intermediate boot loader which contains FS driver using legacy INT13 calls but in Protected mode. This second stage bootloader will be able to load large EFI Firmware.

 

Yes, I see no reason why there should be a restriction on the size.

 

EDIT: Zentih432 said that most BIOS do not support int 13h function 42h, which is probably true of older firmwares that don't support 3TB+ disks. So int 13h can't read into memory above 0x100000. However, that does not mean it can't be used to read into a buffer below that barrier and copy that buffer into higher memory.

[LockDown]

hi

since i cant post in developer thread, i will report it here.

 

i still have Snow Leopard & Lion. sometimes when i need to boot in 32bit mode, i get KP regarding AppleEFIRuntime. Booting in 64bit is ok. im sure this is a bug. tried what ever the latest clovet release and still the same KP

 

Thanks

[Slice]

hi

since i cant post in developer thread, i will report it here.

 

i still have Snow Leopard & Lion. sometimes when i need to boot in 32bit mode, i get KP regarding AppleEFIRuntime. Booting in 64bit is ok. im sure this is a bug. tried what ever the latest clovet release and still the same KP

 

Thanks

This is a bug of Snow Leo. Use Clover-32 to boot it.

[Dr. Hurt]

Sorry to bring up the same point again, but why not "load" the HFS+ icon (which is already integrated into the binary) for APFS partitions? I haven't looked at the code so excuse my question...

 

To reproduce issue, just delete Themes folder from Clover directory.

[apianti]

Hello everyone! Just an update that clover v3 is moving along well and a reminder that I need donations to continue working on v3 at a quicker pace, otherwise I'm going to have to start working on other projects to make money to like stay alive and stuff. So if you are able please make a donation, any amount helps. Thanks!

 

Donate to my PayPal:

 

 

EDIT: Almost forgot, merry christmas, happy holidays, and happy new years!

EDIT2: If you donate, please PM me so I can add you to the list of donors.

[Funky frank]

I have a little problem with updating my Vaio F11 to High Sierra:

 

The BIOS does not properly support EFI booting, so I am using 10.12.6 and a system partition _without_ an efi partition. This works nicely with clover in legacy mode.

 

My questions are now:

 

- Will clover still boot 10.13.2 if I do not convert to APFS and keeping clover on the system partition in the EFI directory?

 

- Is there any way to convert to APFS and still booting clover from the system partition instead from EFI partition?

[Slice]

I have a little problem with updating my Vaio F11 to High Sierra:

 

The BIOS does not properly support EFI booting, so I am using 10.12.6 and a system partition _without_ an efi partition. This works nicely with clover in legacy mode.

 

My questions are now:

 

- Will clover still boot 10.13.2 if I do not convert to APFS and keeping clover on the system partition in the EFI directory?

 

- Is there any way to convert to APFS and still booting clover from the system partition instead from EFI partition?

We have boot1h to boot from HFS+ partition no matter it is Sierra or High Sierra.

We have no boot1apfs boot sector.

[macandrea]

Hi, on my new X299-A PRIME ASUS board, when trying to:

 

- inject ATI

- inject FB Name

 

injection does not work, I just have the "RadeonFrameBuffer" FB and card is recognised as AMD Radeon HD 7xxx. I need to switch to "Futomaki" in order to properly enable DIsplayport connector.

 

I see in IOReg two devices:

- GFX0@0

- GFX0@0,1

 

Injection worked fine with the same Graphics Card and X99-A ASUS Mainboard, same configurations.

 

Setup: X299-A PRIME, X9 7920x, Radeon R9 270x

Clover revision: 4359

 

Can someone please help me to understand what is happening?

iMac.ioreg.zip

[Sherlocks]

hello

can we improve clover log for edid?

now, i don't use edid injection option on my desktop.

 

16:221  0:000  EdidDiscovered size=128

16:221  0:000  ---Discovered EDID Table size:128

16:221  0:000  000  |  00  FF  FF  FF  FF  FF  FF  00  5D  34

16:221  0:000  010  |  13  22  CD  33  22  06  05  13  01  03

16:221  0:000  020  |  80  2F  1D  78  2A  C9  05  A3  57  4B

16:221  0:000  030  |  9C  25  12  50  54  AF  CF  00  01  01

16:221  0:000  040  |  01  01  81  40  81  80  01  01  B3  00

16:221  0:000  050  |  D1  C0  01  01  FC  3A  80  18  71  38

16:221  0:000  060  |  46  40  30  20  36  00  DA  28  11  00

16:221  0:000  070  |  00  1A  00  00  00  FD  00  38  4C  1F

16:221  0:000  080  |  53  11  00  0A  20  20  20  20  20  20

16:221  0:000  090  |  00  00  00  FC  00  44  56  49  0A  20

16:221  0:000  100  |  20  20  20  20  20  20  20  20  00  00

16:221  0:000  110  |  00  FE  00  0A  20  20  20  20  20  20

16:221  0:000  120  |  20  20  20  20  20  20  00  69

16:221  0:000  --- Patched EDID size:128

16:221  0:000  000  |  00  FF  FF  FF  FF  FF  FF  00  5D  34

16:221  0:000  010  |  13  22  CD  33  22  06  05  13  01  03

16:221  0:000  020  |  80  2F  1D  78  2A  C9  05  A3  57  4B

16:221  0:000  030  |  9C  25  12  50  54  AF  CF  00  01  01

16:221  0:000  040  |  01  01  81  40  81  80  01  01  B3  00

16:221  0:000  050  |  D1  C0  01  01  FC  3A  80  18  71  38

16:221  0:000  060  |  46  40  30  20  36  00  DA  28  11  00

16:221  0:000  070  |  00  1A  00  00  00  FD  00  38  4C  1F

16:221  0:000  080  |  53  11  00  0A  20  20  20  20  20  20

16:221  0:000  090  |  00  00  00  FC  00  44  56  49  0A  20

16:221  0:000  100  |  20  20  20  20  20  20  20  20  00  00

16:221  0:000  110  |  00  FE  00  0A  20  20  20  20  20  20

16:221  0:000  120  |  20  20  20  20  20  20  00  69

 

but still shown edid log 2 times.

 

old clover shown only edid original log when don't use edid injection.

if use any vendor/product for edid, shown patched edid log

 

thanks in advance