Jief_Machak Posted April 19, 2021 Share Posted April 19, 2021 On 4/16/2021 at 9:05 PM, Slice said: @Jief_Machak I have Qemu-5 and it works if make symbol link ln -s qemu_portable libs Is it interesting for you? qemu-system-x86_64.7z 2.64 MB · 17 downloads How did you get that version ? Compiled yourself ? With brew ? Link to comment Share on other sites More sharing options...
Slice Posted April 19, 2021 Share Posted April 19, 2021 38 minutes ago, Jief_Machak said: How did you get that version ? Compiled yourself ? With brew ? No, I was using MacPort. Qemu's libs are mostly in /opt/local/... but your libraries from qemu_portable are good enough. Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 19, 2021 Share Posted April 19, 2021 Just now, Slice said: No, I was using MacPort. Qemu's libs are mostly in /opt/local/... but your libraries from qemu_portable are good enough. MacPort ? For an unknown reason, I thought brew took over and didn't use MacPorts in years. I'll try. I am making a script that can take an executable, copy it to a folder and copy all it's library dependency and adjust each library path. Because libs also have path to other libs, doing it manually can be super-annoying and time consuming. But currently, my script only works if path to library are absolute. That's why I want to compile the same version as you and update the script. On 4/17/2021 at 9:14 AM, Jief_Machak said: ==> Installing dependencies for qemu: libtool, ninja, meson, gettext, libffi, pcre, glib, autoconf, automake, gnu-sed, bdw-gc, libunistring, guile, libidn2, libtasn1, nettle, p11-kit, libevent, c-ares, jemalloc, libev, nghttp2, unbound, gnutls, jpeg, libpng, libssh, libusb, lzo, ncurses, pixman, snappy and vde Will see if MacPort has more sensible dependency graph ! With brew, it took 2 hours to compile Qemu, bcause of all these dependencies. Link to comment Share on other sites More sharing options...
Slice Posted April 19, 2021 Share Posted April 19, 2021 I have long experience with MacPort creating libs for Wine. And now for Qemu I just already have mostly all of them. Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 19, 2021 Share Posted April 19, 2021 New qemu version committed. A script "copy_and_make_portable" is committed in the qemu folder. I can be used for anything. I used it for having gcc from brew also portable. And other thing I compiled with brew. I probably should switch back to MacPorts ! Qemu compiled with MacPorts has only 12 dependent libs. With brew it's 24 ! Total is 15MB instead of 24MB. Not bad Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 19, 2021 Share Posted April 19, 2021 Interestingly enough, your qemu executable has a longer list of dependent list, including : @executable_path/../libs/libintl.8.dylib @executable_path/../libs/libpixman-1.0.dylib The rest is in /opt/local/lib. The macos one are in /usr/lib or /System/Library but we don't need this ones. When I installed with MacPorts, my executable has less dependent libs and none are in @executable_path/../libs/. Just curiosity, I wonder what's the difference... Link to comment Share on other sites More sharing options...
Slice Posted April 19, 2021 Share Posted April 19, 2021 The difference can be in default features at configure the qemu. I don't remember if I chosen them. Link to comment Share on other sites More sharing options...
Slice Posted April 19, 2021 Share Posted April 19, 2021 Yes, your qemu-5.2.0 is working. So 4.2.0 can be eliminated? Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 19, 2021 Share Posted April 19, 2021 It's not big. I thought it doesn't hurt to keep it there. But I don't know if someone can need it. Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 20, 2021 Share Posted April 20, 2021 I'm looking at ParseLoadOptions(). It looks like there is the possibility to have a whole config.plist in efi load options. I can't really imagine someone typing a Clover config.plist in its load options... What was it for originally ? Does someone still use that ? Should we still support that ? Same question about GetBootFromOption(). If load options start with a clover sign, load options will interpreted as default volume and default loader. I'm not even sure I can enter a clover sign in the load options. What is it for ? Should we still support that ? 1 Link to comment Share on other sites More sharing options...
Slice Posted April 20, 2021 Share Posted April 20, 2021 5 hours ago, Jief_Machak said: I'm looking at ParseLoadOptions(). It looks like there is the possibility to have a whole config.plist in efi load options. I can't really imagine someone typing a Clover config.plist in its load options... What was it for originally ? Does someone still use that ? Should we still support that ? Same question about GetBootFromOption(). If load options start with a clover sign, load options will interpreted as default volume and default loader. I'm not even sure I can enter a clover sign in the load options. What is it for ? Should we still support that ? Originally it was UEFI BIOS boot option like boot0003 which contains file path to CloverX64.efi and some arbitrary bytes can be interpreted as a name of config.plist. The idea was press F12 and select 1. Boot Clover with config1.plist 2. Boot Clover with config2.plist and so on. But nobody ever used this. Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 20, 2021 Share Posted April 20, 2021 1 minute ago, Slice said: Originally it was UEFI BIOS boot option like boot0003 which contains file patch to CloverX64.efi and some arbitrary bytes can be interpreted as a name of config.plist. The idea was press F12 and select 1. Boot Clover with config1.plist 2. Boot Clover with config2.plist and so on. But nobody ever used this. I understand selecting another config.plist could be interesting in some rare case (but now we can even duplicate the whole Clover folder if we want multiple configuration). What about ParseLoadOptions() where it seems that we can put a while config.plist IN load options ? Or do I misread the code ? 1 Link to comment Share on other sites More sharing options...
Slice Posted April 20, 2021 Share Posted April 20, 2021 Whole config.plist? It should be an error. 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 20, 2021 Share Posted April 20, 2021 (edited) 10 minutes ago, Slice said: Whole config.plist? It should be an error. void ParseLoadOptions ( OUT XStringW* ConfNamePtr, OUT TagDict** Dict ) { CHAR8 *End; CHAR8 *Start; UINTN TailSize; UINTN i; CONST CHAR8 *PlistStrings[] = { "<?xml", "<!DOCTYPE plist", "<plist", "<dict>", "\0" }; UINTN PlistStringsLen; *Dict = NULL; XStringW& ConfName = *ConfNamePtr; Start = (CHAR8*)self.getSelfLoadedImage().LoadOptions; End = (CHAR8*)((CHAR8*)self.getSelfLoadedImage().LoadOptions + self.getSelfLoadedImage().LoadOptionsSize); while ((Start < End) && ((*Start == ' ') || (*Start == '\\') || (*Start == '/'))) { ++Start; } TailSize = End - Start; //DBG("TailSize = %d\n", TailSize); if ((TailSize) <= 0) { return; } for (i = 0; PlistStrings[i][0] != '\0'; i++) { PlistStringsLen = AsciiStrLen(PlistStrings[i]); //DBG("PlistStrings[%d] = %s\n", i, PlistStrings[i]); if (PlistStringsLen < TailSize) { if (AsciiStriNCmp(PlistStrings[i], Start, PlistStringsLen)) { DBG(" - found plist string = %s, parse XML in LoadOptions\n", PlistStrings[i]); if (ParseXML(Start, Dict, TailSize) != EFI_SUCCESS) { *Dict = NULL; DBG(" - [!] xml in load options is bad\n"); return; } return; } } } while ((End > Start) && ((*End == ' ') || (*End == '\\') || (*End == '/'))) { --End; } TailSize = End - Start; // DBG("TailSize2 = %d\n", TailSize); if (TailSize > 6) { if (AsciiStriNCmp(".plist", End - 6, 6)) { End -= 6; TailSize -= 6; // DBG("TailSize3 = %d\n", TailSize); } } else if (TailSize <= 0) { return; } ConfName.strncpy(Start, TailSize + 1); } In this function, there is : Start = (CHAR8*)self.getSelfLoadedImage().LoadOptions; and then : if (ParseXML(Start, Dict, TailSize) != EFI_SUCCESS) { The dict generated is store in gConfigDict[1] by the caller (in main.cpp). I imagine the purpose is NOT to put the whole thing, of course. The caller check a tag "Unite". And if "Unite" is false, gConfigDict[0] is not read. So it looks like a way of replacing or uniting config.plist with an xml passed into load options ? Could I simplify and drop that support ? (and re introduce something if a user is asking, one day). Edited April 20, 2021 by Jief_Machak Link to comment Share on other sites More sharing options...
Slice Posted April 20, 2021 Share Posted April 20, 2021 7 hours ago, Jief_Machak said: Could I simplify and drop that support ? (and re introduce something if a user is asking, one day). Yes, simply drop. I never understood the idea of this unite. There are bad messages about Xcode12 compilation again. https://www.applelife.ru/threads/clover.42089/page-1378#post-936652 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 21, 2021 Share Posted April 21, 2021 From what I see in the russian thread, Clover seems to work but macos kernel panic... Hard to debug, but what I can do is going over ALL the objects in Clover and add a default ctor. I'll do that tmo. Also, here is the very first compilation of Clover using the new XML parser : CloverX64-2021-04-21-13-18-28-a1a27d2-dirty-jief.zip As usual, there should be no difference for you (and that's exactly what I want to test). We already know that the new parser gives the same result... but who knows. As usual, be sure to have a plan B in case this one doesn't boot. PS : please don't ask why I spend so much time to do thing that make no difference for the user... 3 Link to comment Share on other sites More sharing options...
kushwavez Posted April 21, 2021 Share Posted April 21, 2021 Why are you spending so much time to do thing that make no difference for the user? (jk) 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 21, 2021 Share Posted April 21, 2021 I have yet to answer that question to myself. 1 2 Link to comment Share on other sites More sharing options...
Matgen84 Posted April 21, 2021 Share Posted April 21, 2021 (edited) Hi @Jief_Machak The compilation of Clover using new XML Parser 2021-04-21-13-18-28-a1a27d2-dirty-jief boot fine (Z390 config Big Sur 11.3 RC) I test the CLOVERX64 posted on AppleLife: boot fine too, the same config. But I notice some problems with new XML Parser: in Clover GUI Options/SMBIOS, there are some difference between Clover and my Imac19,1 SMBIOS config.plist: BiosVersion, BiosRelease date, EFI version No Problem with CloverX64TestNewParser version 13.EDIT: Why this in debug.log : '\EFI\CLOVER__Test/smbios.plist' not loaded. Efi error Not Found don't exist before Spoiler 2021-4-21_8-10_CloverX64-2021-04-21-13-18-28-a1a27d2-dirty-jief.efi.log 2021-4-21_11-11_CLOVERX64_AppleLife.efi.log Résultat CLOVERX64TestNewParser.txt Edited April 21, 2021 by Matgen84 2 Link to comment Share on other sites More sharing options...
JorgeMax Posted April 21, 2021 Share Posted April 21, 2021 (edited) Here also giving error in the SMBIOS information Spoiler SMBIOS generated by the clover: SMBIOS generated by information from my "config.plist": Edited April 21, 2021 by JorgeMax 1 Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 21, 2021 Share Posted April 21, 2021 Yes yes, found it, thanks. CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist. The other are not fixed yet. Link to comment Share on other sites More sharing options...
JorgeMax Posted April 21, 2021 Share Posted April 21, 2021 20 minutes ago, Jief_Machak said: Yes yes, found it, thanks. CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 1 download Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist. The other are not fixed yet. I think it's the same way 1 Link to comment Share on other sites More sharing options...
Matgen84 Posted April 21, 2021 Share Posted April 21, 2021 (edited) 40 minutes ago, Jief_Machak said: Yes yes, found it, thanks. CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 1 download Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist. The other are not fixed yet. Hi @Jief_Machak I don't try this efi file. But in previous one, Clover search smbios.plist instead of config.plist. So this line in debug.log: '\EFI\CLOVER__Test/smbios.plist' not loaded. Efi error Not Found Edited April 21, 2021 by Matgen84 Link to comment Share on other sites More sharing options...
Matgen84 Posted April 21, 2021 Share Posted April 21, 2021 48 minutes ago, Jief_Machak said: Yes yes, found it, thanks. CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.zip 824.42 kB · 1 download Could you try this efi and see it that fixed to ROM version (or BiosVersion) in config.plist. The other are not fixed yet. Hi again @Jief_Machak ROM version fixed in Clover GUI only. Not in debug.log BIOSVersion=EFIversion ??? 2021-4-21_11-39_CloverX64-2021-04-21-15-59-08-a1a27d2-dirty-jief.efi.log Link to comment Share on other sites More sharing options...
Jief_Machak Posted April 21, 2021 Share Posted April 21, 2021 18 minutes ago, Matgen84 said: BIOSVersion=EFIversion When you setup a BiosVersion AND an EfiVersion in your config or smbios plist, EfiVersion will be sent to smbios. It always has been like this. I just recently make the message. I'll have a look later... Thanks for the tests. 2 Link to comment Share on other sites More sharing options...
Recommended Posts