Jump to content

Zenith432

Zenith432

Member Since 21 Jun 2009
Offline Last Active Yesterday, 05:24 PM
*****

#2572009 Clover problems report & features request

Posted by Zenith432 on Yesterday, 11:12 AM

Before 4385, if you had both OsxAptioFixDrv and OsxAptioFix2Drv in drivers64UEFI, it would pick up the one that occurs first in the FAT32 directory iteration.  After 4385 there is a prioritisation, so OsxAptioFix2Drv is picked up first.  I suggest you keep just the one that works for use in drivers64UEFI and move the others to drivers-Off/drivers64UEFI. Had to change OsxAptioFixDrv2 to  OsxAptioFixDrv for 4385  :thumbsup_anim:
  • nms likes this

#2571641 Clover problems report & features request

Posted by Zenith432 on 18 January 2018 - 05:02 PM

Try r4385 Anybody tried 4384, don't work here, had to revert to 4380

#2554694 Clover General discussion

Posted by Zenith432 on 22 December 2017 - 02:51 PM

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.

#2551264 Clover General discussion

Posted by Zenith432 on 15 December 2017 - 09:33 PM

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.If Clover is already patching the kernel for booter kexts, why not revert to what I said here and patch the kernel to make the messages go away?  What cecekpawon said may make the messages go away when there's no injection, but will still be there with injection. PS: I realise that this may be the reason why in VMware the injected kexts are left hanging around.  Because the firmware injects them, but does not patch the kernel, so they're ignored.  This also explains why the messages are not appearing in VMware.

#2549941 Clover General discussion

Posted by Zenith432 on 13 December 2017 - 11:05 AM

That certainly helped find the problem, because stock GCC5 toolchain build breaks in CpuDxe instead of generating code that crashes.Maybe if Clover used the stock standard tools_def.txt and build_rule.txt and GccBase.lds it will compile ok.

#2549837 Clover General discussion

Posted by Zenith432 on 13 December 2017 - 06:54 AM

I'll check it today. I get bad compiled boot6 and boot7 with gcc7 after your changes to tools_def.txt in commit r4350.  Build parameters: Update: it's the mcmodel=small -fpie. I reverted 4350. Will try to figure out what's wrong and get the small model to work in the future.

#2545265 macOS 10.13.2 Update is out

Posted by Zenith432 on 06 December 2017 - 07:35 PM

Updated 10.13.2 successfully inside VMware guest, which is my guinea pig before updating on host system. 8 hours remaining to download iOS 11.2 373MB update...

#2545261 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 06 December 2017 - 07:33 PM

     EDK2 (UEFI) Shell issues/bugs?    I didn't keep following that thread after my post about using vanilla shell successfully. @Sherlocks: I seem to remember something about bootx1alt (as opposed to boot0xg) that did have something to do with Clover. It is a variant of exfat boot code that allows to press a numeric key to choose which 2nd-stage boot file to load.

#2544715 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 05 December 2017 - 07:51 PM

Ok, the problem is actually in svn commit 25815 that adds some code to GenSec.c that doesn't compile with Xcode.  The tool wasn't built, so I didn't have it which is why the build broke. Here's a patch to fix GenSec.cdiff a/BaseTools/Source/C/GenSec/GenSec.c b/BaseTools/Source/C/GenSec/GenSec.c--- a/BaseTools/Source/C/GenSec/GenSec.c+++ b/BaseTools/Source/C/GenSec/GenSec.c@@ -1034,9 +1034,9 @@ Returns: CHAR8 *DummyFileName; FILE *DummyFile; UINTN DummyFileSize;- UINT8 *DummyFileBuffer;+ CHAR8 *DummyFileBuffer; FILE *InFile;- UINT8 *InFileBuffer;+ CHAR8 *InFileBuffer; UINTN InFileSize; InputFileAlign = NULL;@@ -1326,13 +1326,13 @@ Returns: DummyFile = fopen (LongFilePath (DummyFileName), "rb"); if (DummyFile == NULL) { Error (NULL, 0, 0001, "Error open...

#2544572 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 05 December 2017 - 04:19 PM

edk2 svn commit 25816 breaks Clover build.

#2542625 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 01 December 2017 - 07:18 PM

Don't thank me.  Thank GCC 7.2.1.  Do you seriously think I'd have found that myself?  I'm not that bored.@Zenith432, Thanks for the review/fix in r4330.

#2542405 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 01 December 2017 - 11:48 AM

This doesn't happen to me, but I use vanilla shell from edk2/ShellBinPkg/UefiShell/X64/Shell.efiAnyone else having trouble with Clovers shell, i.e if I do a map -r -b it prints out then hangs if I press q or enter

#2542159 Clover General discussion

Posted by Zenith432 on 30 November 2017 - 06:50 PM

UEFI specification section 2.3 defines EFI ABI for x86, x86_64, Intel Itanium, ARM 32-bit, ARM 64-bit.  The only connection to Microsoft is that Intel is heavily connected to Microsoft, so they sometimes copy their technology.  In fact, EFI as whole feels a lot like a modern re-incarnation of DOS.  I think Intel's C/C++ compiler also generates Microsoft ABI for x86_64.Anyway, GCC and clang both allow to build cross-ABI binaries in x86_64, using both ms_abi and sysv_abi.  So only EFIAPI functions in x86_64 need to have ms_abi.

#2538010 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 21 November 2017 - 07:50 PM

Imagine a hypothetical leaf function that fills a buffer with a pixel color.  Imagine that this function stores the value of the pixel color just under the stack pointer, in its red zone, without adjusting the stack pointer.  Imagine that a timer interrupt drops by to visit while our leaf function is filling the buffer.  Imagine that the rude interrupt handler stomps the pixel color, leaving the red value at zero, the green value at zero, and the blue value equal to the GDT selector of the code segment that happens to be in use by UEFI firmware.  What would this buffer look like if blitted to a screen? If you have a fast enough CPU, you may never get to see it. I was going to paste the code and disassembly which would have made it a long explanation.  I think enough said. This bug is my fault.  -mno-red-zone is in the GCC build CC_FLAGS, and I missed how important it is for writing kernel-mode code with sysv abi.

#2537963 Clover Bug/Issue Report and Patch

Posted by Zenith432 on 21 November 2017 - 06:06 PM

Plus I'm unsure what the rules of that typecasting would be from (UINTN)-1, does it get extended first and then converted to unsigned or converted unsigned and then extended?The rules of STDC are rigid enough to dictate that a signed int would first get promoted to a larger-sized signed int, and finally reinterpreted as unsigned. For 2's complement, the promotion part is to sign-extend.  For 1's-complement or sign-magnitude (which are also permitted), you'd get a different bit string as a result.

© 2017 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy