Clover General discussion

[cecekpawon]

3. There actually is, I discovered that the current Clover kext injection implementation does not properly inject Info.plists, for some reason OSKextExcludeList will not be present in a kext injected by Clover effectively making XNU to panic.

I confirmed that with my 10.13

In other case, I have bad experienced injecting plist with CRLF line ending edited from Windows may causing panic. So it would be nice if Clover take care of that before injecting something.

[Dr. Hurt]

Is the embedded theme missing apfs icons? Please add them (re-use hfs icons to save space)...

 

Does clover legacy have an integrated apfs driver?

[Slice]

Is the embedded theme missing apfs icons? Please add them (re-use hfs icons to save space)...

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.

Does clover legacy have an integrated apfs driver?

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

[cyrhex]

@slice still receiving blackscreen issue on my r7 250 with latest version of clover im using 0X68101002 as fake id,using Radeon framebuffer...

[Sherlocks]

i have a question

https://sourceforge.net/p/cloverefiboot/code/4359/tree//rEFIt_UEFI/Platform/gma.c?diff=504c3833fd48f873331ebd05:4358

 

do these keys have a benefit?

i want to know role of these key.

 

newer portable mac series do not have this key.

also seems to consider desktop case.

 

thanks

[wern apfel]

i have a question

https://sourceforge.net/p/cloverefiboot/code/4359/tree//rEFIt_UEFI/Platform/gma.c?diff=504c3833fd48f873331ebd05:4358

 

do these keys have a benefit?

i want to know role of these key.

 

newer portable mac series do not have this key.

also seems to consider desktop case.

 

thanks

According to my experience, they are not needed for Intel graphics, but for nvidia mobile cards i need the backlight-control entries.

[cecekpawon]

#HCKCN17 - Clover Workshop MacGrummel

 

[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