Jump to content

Trung_Nguyen

Members
  • Content Count

    106
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Trung_Nguyen got a reaction from Badruzeus in VirtualSMC — SMC Emulator   
    I cloned the repo and Built it myself and It just works!!
    Thanks Acidanthera team for those kexts and efi
  2. Like
    Trung_Nguyen got a reaction from Badruzeus in VirtualSMC — SMC Emulator   
    I cloned the repo and Built it myself and It just works!!
    Thanks Acidanthera team for those kexts and efi
  3. Like
    Trung_Nguyen reacted to vit9696 in VirtualSMC — SMC Emulator   
    This is your magic formula:
    1. Always stay with the latest binary releases of all kexts
    2. Do not download or upload binary releases yourself
    3. Let the official binary releases stay for a day or two before updating all kexts

    If you are building from master, well, you are supposed to know a word or two how macOS kernel drivers work, how to read logs, how to troubleshoot your system. The reason for this should be troubleshooting some bug or implementing a new feature.
     
    The latter ie expected from any person making oneself a hackintosh, in case you are unqualified and are not interested in educating, http://store.apple.com is your friend. Or at least do not whine about things .
  4. Like
    Trung_Nguyen reacted to vit9696 in FileVault 2   
    Alright, after a couple of weeks of hard work performed by: ath, Download-Fritz, slice, savvas, and myself FileVault 2 should work everywhere now. Additionally thanks to iNDi for help and initial discovery of certain FV aspects.
     
    This means that everybody gets some pros for this but mainly Clover.
    Everything works in test mode for the time being, so you better wreck your disk drives and tell us how much fun it was

    Clover:
    In brief you are required to install a set of drivers present at least in r3876. There are two driver categories, and each one will be addressed separately.
    UI drawing. Make sure that you remove all the legacy drivers implemented in the past. The list includes: AppleImageCodec-64.efi, AppleKeyAggregator-64.efi, AppleKeyMapAggregator.efi, AppleEvent.efi, AppleUITheme-64.efi, EnglishDxe-64.efi, FirmwareVolume-64.efi, HashServiceFix-64.efi Avoid OsxAptioFix1/2/3, because they may cause boot hang during recovery entrance. Use AptioMemoryFix. The following is mandatory: AppleUiSupport.efi — or you will get cursor error; VirtualSmc.efi (for VirtualSMC) or SMCHelper.efi (for FakeSMC). Password input. To do that you need a keyboard driver, which knows about Apple key aggregation protocol.
    There are two input drivers for the time being:
      AptioInputFix — my driver specific to AMI APTIO IV UEFI BIOS. Still in process of a rewrite and release.
    Pros:
    — works without keyboard reconnect or driver flash with USB and PS/2 keyboards in AMI UEFI BIOS;
    — fixes not working mouse input on Z87 and possibly newer;
    Cons:
    — some multisymbol hotkeys will not work (e.g. 3+2, 6+4);
    — key autorepeat might cause issues on some systems;
    — mouse might work a bit slowly on some systems (better than nothing).

    Recommendations:
    A lightweight solution that will mostly work well for some people. If it works for you and you have no desire to flash your BIOS, perhaps it is a good idea. Modified UsbKbDxe, a slightly altered version is present in Clover.
    Pros:
    — works with any USB keyboard in any BIOS;
    — offers completely functional Apple boot keys (CMD+V, 3+2, CMD+R, etc.);
    Cons:
    — might require a physical keyboard reconnect after driver load with AMI UEFI BIOS;
    — might lead to a complete freeze of the system with AMI UEFI BIOS.

    Recommendations:
    It is recommended to use this driver from BIOS or via legacy clover boot. In this case you will have no issues with keyboard connection. To solve freezing issues you will need to rebuild UsbKbDxe with a forced controller disconnect at EXIT BS.
    In case of Clover use:
      ./ebuild.sh -D EXIT_USBKB=1 In case of the original driver see these PCDs. Both should be set to TRUE.
    In case of Clover FixOwnership might help you, but I would not recommend this. AppleKeyFeeder — a solution by Jief_Machak for very very broken systems, for e.g. PS/2 keyboards on laptops. It does not emulate all the keys and does not support key combination, but is definitely better than nothing.Link to a binary.  
    Hibernation is a no go for those having no hardware nvram and no StrictHibernate in clover config
    No solutions for the time being and no solutions planned. Shutdown button on login screen may cause a restart
    No solutions for the time being. Password change/reset during the volume encryption might cause issues when logging in
    Apple issue. Please refrain from changing or resetting the password before the encryption completes. In cases this is required use your generated recovery key to login into the system.
  5. Like
    Trung_Nguyen got a reaction from Matgen84 in [pre-release] macOS Mojave   
    please HELP
    I updated to beta6. It went well and then when I shutdown and start again. I got apple logo stuck before FileVault 2 authentication(no progress bar, Just Apple, sometimes screen go slight brighter and then go darker again). I even tried unlock it with the recovery partition but it doesn't work.
     
    EDIT1:
    The verbose show LoginWindow initalize failed DUInitialize 0xe ERROR!Can't unlock CoreStorage volume
     
    EDIT2:
    Okay, It booted now after updatePreboot. It takes longer to initialize EFI loginWindow.
  6. Haha
    Trung_Nguyen reacted to fantomas in [pre-release] macOS Mojave   
    Guys, you do know we have a dedicated forum to discuss about your Clover preferences, right? 
  7. Like
    Trung_Nguyen got a reaction from Matgen84 in [pre-release] macOS Mojave   
    I prefer AptioMemoryFix
    oops, I did compile r4586, but I wrote it r4582
  8. Like
    Trung_Nguyen got a reaction from Nightf4ll in [pre-release] macOS Mojave   
    AptioMemoryFix have native nvram while OsxAptioFixDrv doesn't. OsxAptioFixDrv must be used with EmuVariableUEFI and rc script to read&write nvram to nvram.plist
  9. Like
    Trung_Nguyen got a reaction from Nightf4ll in [pre-release] macOS Mojave   
    AptioMemoryFix have native nvram while OsxAptioFixDrv doesn't. OsxAptioFixDrv must be used with EmuVariableUEFI and rc script to read&write nvram to nvram.plist
  10. Like
    Trung_Nguyen got a reaction from Matgen84 in [pre-release] macOS Mojave   
    Hello, can somebody tell me what's the purpose for apfssupportpkg? Thanks
  11. Thanks
    Trung_Nguyen reacted to arsradu in [pre-release] macOS Mojave   
    Config -> System Parameters -> Inject Kexts -> YES (instead of Detect). Could you please, try that?
  12. Like
    Trung_Nguyen got a reaction from Matgen84 in [pre-release] macOS Mojave   
    I lost the audio input since updating to beta2, the built-in microphone still lives in b1 with the new applealc 1.2.8v2 built by someone on this thread earlier, but now everything gone
    I'm using IDT92HD93BXX(layout-id 12)
  13. Like
    Trung_Nguyen got a reaction from AlyssaTallent in Apple Hackintosh SMBIOS Blacklist   
    Hi guys,
    Today, I tried to switch the SMBIOS to the MBA5,2 from MBP9,2 to try the PowerNap.
    When I online, Apple Locked my iCloud password and I have to reset it.
    But, the thing is that a years ago, I start Hackintosh with 10.11.5 and use the MBA5,2 SMBIOS like from the tutorial by Jake Lo from OSXLatitude.
    I have to reset the password many times, almost after every minor/major update.
    But when I switch to the MBP9,2 like Herve, Everything went well, Apple seem to accept it.
    So, I thought maybe Apple have a list of SMBIOS model that shouldn't be fake and a list that contain fake-acceptable?
    I'm not sure about it because it may caused by the Fake serial number?
    Anyway, Have a good day!
  14. Like
    Trung_Nguyen got a reaction from AlyssaTallent in Apple Hackintosh SMBIOS Blacklist   
    Hi guys,
    Today, I tried to switch the SMBIOS to the MBA5,2 from MBP9,2 to try the PowerNap.
    When I online, Apple Locked my iCloud password and I have to reset it.
    But, the thing is that a years ago, I start Hackintosh with 10.11.5 and use the MBA5,2 SMBIOS like from the tutorial by Jake Lo from OSXLatitude.
    I have to reset the password many times, almost after every minor/major update.
    But when I switch to the MBP9,2 like Herve, Everything went well, Apple seem to accept it.
    So, I thought maybe Apple have a list of SMBIOS model that shouldn't be fake and a list that contain fake-acceptable?
    I'm not sure about it because it may caused by the Fake serial number?
    Anyway, Have a good day!
  15. Like
    Trung_Nguyen got a reaction from zxv in Clover General discussion   
    Currently, I'm working to make all Apple Boot Keys works(for AMI Aptio boards, at least for laptops) even the alt key. Trying to make the AptioInputFix more useful , attempt to make it to sent modifier key like Alt for GUI, Shift for Safe Mode. 
  16. Like
    Trung_Nguyen reacted to apianti in Clover General discussion   
    Yes. There has never been a mac with PS/2 support, lol. Not one, ever. They had their own proprietary interface before, kinda the preface to firewire/usb/thunderbolt called apple desktop bus. It was created by steve wozniak and released in 1986 on one of the Apple II redesigns GS or GT or something. PS/2 wasn't released until the following year, with IBM's PS/2 model computer, that was almost positively to compete against the much better ADB over straight twisted pair serial ports.... So they made a serial bus that could only be used for specific purposes, in fact you used to have to specifically plug in the correct device or the protocol to recognize it was not even associated with the port. ADB works more like thunderbolt, only still a serial interface, but in 1986....... That guy is a {censored} genius.
     
    EDIT: If you have a PS/2 controller, then you will need to modify the PS2 keyboard driver as well to populate the aggregator and database.
     
    EDIT2: Also don't remove any keys from there, just inspect the protocol interfaces.
     
    EDIT3: Oh just in case any one is wondering, SPI is Serial Peripheral Interface and is basically all of these put together, lol.
     
    EDIT4: It looks like newer MacBookPros, especially with the touch bar probably use SPI too. Well, more specifically it's probably using Intel's proprietary eSPI. But there are evidence of SPI drivers needed for MacBookPro13,1+ in Ubuntu. As well as the afore mentioned newer MacBook.
  17. Like
    Trung_Nguyen reacted to Download-Fritz in Clover General discussion   
    Alt is a modifier, not a key.
  18. Like
    Trung_Nguyen got a reaction from nms in Clover General discussion   
    GOT IT WORKING:Apple boot key.
    Just test it with CMD+V
    Currently trying to get the alt key to invoke GUI
  19. Like
    Trung_Nguyen reacted to apianti in Clover General discussion   
    It does. That's why you can't press a key and get into the GUI, because the key aggregator ate all the previous key strokes. The code you gave just discards them instead of using them in the aggregator or the GUI properly. Locate the key aggregator proctocol and check that it has any keys in it's buffer, if you really want to be thorough only set KeyPressedForGUI if the keystrokes in the key aggregator are not relevant to a startup command.
     
     
    Yes, some are handled by boot.efi, by the firmware gathering keystrokes into the key aggregator and that is examined by boot.efi. So if you read all the keystrokes before the driver is loaded then you discarded them before the driver could gather them. So you've exchanged the functionality of the key aggregator before boot for the functionality of the GUI appearing, they should not be mutually exclusive.
     
     
    You cannot boot without FakeSMC.... Also almost guarantee you are just copying FakeSMC.kext straight from the download and not removing any of it's plugins, which is where the monitor is usually.
     
     
    EIST is speedstep..... Why would speedstep be causing issues? Who is not enabling speed step? WTF is this post about?
     
     
    https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/refit/menu.c#l2535
     
     
    If you have a table named CpuPm or that already defines any of those methods you cannot inject that table or it will just be discarded. You don't need an speedstep SSDT for XCPM because the state data is stored elsewhere in OS resources. Most likely you don't want to drop those tables, especially CpuPm if you are going to be using them. So you'll probably have to edit your CpuPm table anyway because of the name and it probably most likely already has a _DSM method, so maybe just edit that and add that code to it?
  20. Like
    Trung_Nguyen reacted to vit9696 in AptioMemoryFix   
    Here and there: boot.efi printing now and then.
     
    UPDATED: 31.01.2018 with fixes to certain misunderstandings and relevant NVRAM variables to control boot.efi logging behaviour.
     
    Scroll all the way down to "How is this configured" if you need boot.efi debug printing.
     
    Apple developers improved boot.efi printing quite a lot as of High Sierra.
    The good thing is that we could make a good use of it, the bad thing, it is not too obvious.
     
    Just like everything else boot.efi follows edk2-like error level reporting.
    In release boot.efi only DEBUG_ERROR (0x80000000) is available, the rest are stripped.
     
    First of all, boot.efi has an unholy amount of different print functions for all the needs.
    So it will be a good start to list them. The function names may not be ideal, but I left the examples with strings to let one get an idea.
     
    1. VOID PerfRecordPrint(CONST CHAR8 *Format, ...)
     
    There are tons of its calls, for example:
    PerfRecordPrint("Start");
    PerfRecordPrint("Start OSName");
    PerfRecordPrint("End OSName");
    PerfRecordPrint("Start LoadCoreStorageConfiguration");
     
    Its designation is to measure how much it took for boot.efi to execute each certain step and provide Apple the performance details.
    Prior to 10.13 it was only possible to use it to log to NVRAM (efiboot-perf-record-data, efiboot-perf-record-data-size).
    Starting with 10.13 it may also print via logging 'drivers', which print via different implementations.
     
    2. VOID AppleLoggingPrintAll(UINTN ErrorLevel, CONST CHAR8 *Format, ...)
     
    Known for printing especially crtitical messages like:
    AppleLoggingPrintAll(DEBUG_ERROR, "This version of Mac OS X is not supported on this platform!\n");
    AppleLoggingPrintAll(DEBUG_ERROR, "This system was automatically rebooted after panic\n");
     
    Prior to 10.13 it was an unconditional formatted print via gST->ConOut or gST->StdErr if unavailable.
    Starting with 10.13 it prints via logging 'drivers', which print via different implementations.
    AppleLoggingPrintAll is designed to print via all the 'drivers'.
     
    3. VOID FatalError(CONST CHAR8 *Format, ...)
     
    Known usages, for example:
    FatalError("Can not initialize console\n");
    FatalError("ERROR!!! Recovery Image verification fail with status [0x%llx]\n", Status);
    FatalError("Couldn't allocate bootArgs\n");
     
    This is the well known print the error, sleep for 10 secs, and reboot.
    Prior to 10.13 it used an unconditional formatted print via gST->ConOut or gST->StdErr if unavailable.
    Starting with 10.13 it also prints via logging 'drivers', all of them.
     
    4. VOID AppleLoggingPrintAllStyled(UINTN Level, CONST CHAR8 *Format, ...)
     
    AppleLoggingPrintAllStyled(DEBUG_ERROR, "ERROR!!! Load prelinked kernel with status 0x%lx\n", Status);
    AppleLoggingPrintAllStyled(DEBUG_ERROR, "(no root UUID found for boot device)\n");
    AppleLoggingPrintAllStyled(DEBUG_ERROR, "Boot failed, sleeping for 10 seconds before exiting...\n");
    AppleLoggingPrintAllStyled(0x80000000ui64, "ERROR!!! Uncompress prelinked kernel\n");
     
    This one has always been printing via all of the logging 'drivers', starting with 10.11 at least.
     
    Main internal implementation
     
    Prior to 10.13 most of the prints went through a direct call through gST->ConOut/gST->StdErr, and printing drivers were almost unused and left unnoticed. Starting with 10.13 printing drivers are for almost everything, and we need to take good care of them. Interestingly they could also do additional formatting to the output (like timestamps).
     
    These functions are the main functions Apple uses to print stuff.
    To fully understand them one needs to go deeper into the implementation.
     
    The idea is to have a formatter function similar to vprintf.
    void AppleLoggingFormatter(CONST CHAR8 *Format, APPLE_LOGGING_PUTCHAR PutChar, AppleLoggingState *State, va_list *Args)
    The arguments are as follows:
    - a format string;
    - some internal state;
    - a putchar-like function, which will use the state;
    - a variable list of arguments.
     
    Prior to 10.13 everything went through a simple putchar function, that did not even need a state.
    All the above functions but PerfRecordPrint would invoke DirectLoggingPrintf or alike under some condition and print to gST->ConOut or gST->ConOut.
     
     
     
     
    The exceptional PerfRecordPrint required a special nvram variable (efiboot-perf-record) to be present.
    When it was there, boot.efi would print to a memory buffer until the very end, and will later store its data in efiboot-perf-record-data/efiboot-perf-record-data-size variables.
    As a bonus it is also passed via BootArgs structure, so a bootloader can easily obtain this data too.
     
     
     
     
    Printing drivers used throughout 10.13
     
    While printing drivers are not new to 10.13, and they existed in the previous operating systems, nothing really used them. Currently there are three, each exposing 2 funcs to enable/disable and its own bit used in logging usage mask.
     
    1 — AppleLoggingConOutOrErrSet/AppleLoggingConOutOrErrPrint (classical ConOut or StdErr on failure)
    2 - AppleLoggingStdErrSet/AppleLoggingStdErrPrint (StdErr or serial?)
    4 - AppleLoggingFileSet/AppleLoggingFilePrint (BOOTER.LOG/BOOTER.OLD file on EFI partition)
     
    So, from now on to be able to print via either of the driver one must do 3 things:
    - include the bit in the printer driver mask (this is done pretty much everywhere);
    - enable the driver itself by calling its Set function with 0 argument;
    - pray that the driver works fine
     
    Relevant decompiled code is included below:
     
     
     
     
    So, the functions are now modified to print their output via 2 new interfaces:
    void AppleLoggingPrintfStyled(UINTN PrinterMask, UINTN Level, const char *Format, va_list *Args);
    void AppleLoggingPrintf(UINTN PrinterMask, UINTN Level, const char *Format, va_list *Args);
     
    PrinterMask is responsible for choosing the drivers to use. Currently Apple seems to pass 0x37 everywhere.
    So it means that by default all the drivers should at least try printing.
    The only difference between Styled and non-styled is that styled depending on gBootArgDebug.variable value may print a timestamp.
     
     
     
     
    What are the changes to the top functions?
    There is nothing interesting besides the use of AppleLoggingPrintfs. But FatalError and PerfRecordPrint got something special.
    First one no longer uses direct ConOut/StdErr logging for printing errors, but has a well-known "does printf work??" message going through it.
    So we can conclude that AppleLoggingPrintf does not work on most of hacks.
    Second one will now use AppleLoggingPrintfStyled to print debug messages, which means if AppleLoggingPrintfStyled begins to work, we will be able to print the whole boot.efi trace log onscreen.
     
     
     
     
    How is this configured?
     
    Initially I confused this part quite a lot due to various circumstances . Now it is much better.
    To configure the driver logging boot.efi uses nvram bootercfg and bootercfg-once variables, which are very similar to boot-args.
    bootercfg-once is a way to change the debugging for a single boot only, and it is read and deleted by boot.efi only if bootercfg is not present.
     
    The accepted values for all the arguments are hexadecimal 64-bit values with or without 0x prefix:
    — log=VALUE
    — debug=VALUE
    — level=VALUE
    — kc-read-size=VALUE
     
    For log the valid bits are enabled log drivers:
    1 — AppleLoggingConOutOrErrSet/AppleLoggingConOutOrErrPrint (classical ConOut or StdErr on failure)
    2 — AppleLoggingStdErrSet/AppleLoggingStdErrPrint (StdErr or serial?)
    4 — AppleLoggingFileSet/AppleLoggingFilePrint (BOOTER.LOG/BOOTER.OLD file on EFI partition)
     
    For debug the valid bits are:
    1 — enables print something to BOOTER.LOG (stripped code implies there may be a crash)
    2 — enables perf logging to /efi/debug-log in the device three
    4 — enables timestamp printing for styled printf calls
     
    Thus to quickly disable the logging functionality in -v mode in boot.efi you could use sudo nvram bootercfg="log=0".
     
    For level the value is the verbosity level of DEBUG output. Since everything but 0x80000000 is stripped from the binary, and this is the default value, it is not very handy.
     
    For kc-reead-size the value is a chunk size used for buffered i/o from the network (unsupported obviously) or the disk for stuff like prelinkedkernel reading. By default it is set to 1MB (0x100000), but you may try to increase it for a millisecond faster booting
     
    Interanlly there are three functions to configure printing driver usage, in particular these:
    - AppleLoggingSet (a dedicated func to speficific drivers on or off)
    - AppleLoggingEnable
    - AppleLoggingDisable
     
    The only usage of the first one is in boot key parsing code.
    Pressing Cmd + V (verbose mode) will enable the 1st driver (classical ConOut or StdErr on failure).
    It is really weird, because -v in boot-args does not do it, but I guess Cmd + V is considered more special than -v.
     
    Which adds to the top of the ice-berg is that AppleLoggingDisable is called before boot.efi goes down or booter services will be no longer available due to os start:
    - right before rebooting into Recovery
    - right before chainloading a second boot.efi
    - before printing "Boot failed, sleeping for 10 seconds"
    - during memory map allocation close to XNU start
    - right before EXIT_BOOT_SERVICES
     
     
     
     
    To unconditionally and quickly enable the debug log in 10.13 one may still patch the check in the beginning of the logger function (ConOut/StdErr method).
    But I suppose it will be better to implement some interface to set bootercfg from Clover (or at least stop it from messing with it):
    48 81 EC 50 01 00 00 80 3D -> 48 81 EC 50 01 00 00 EB 07
  21. Like
    Trung_Nguyen got a reaction from Peanut-Pulp in Fan and OS X   
    Regenerate the SSDT with the latest ssdtprgen.sh from pikeralpha
  22. Like
    Trung_Nguyen got a reaction from Peanut-Pulp in Fan and OS X   
    They are regulate by FakeSMC.
  23. Like
    Trung_Nguyen reacted to apianti in Clover General discussion   
    Unfortunately, no, those keys are being consumed by the input buffer for FileVault2 for startup keys and stuff.... For now you will have to put at least Timeout=1, in the future I guess that protocol will need to be located and checked for this purpose.... I've no idea who's going to do that....
     
    EDIT: I should also point out the startup combinations for mac don't work because that is part of the mac firmware and is not implemented in clover.... Yet, I guess.
  24. Like
    Trung_Nguyen reacted to Slice in AptioMemoryFix   
    Dell Latitude E6430
    Latest AptioMemoryFix (RC8) from github today
    slide=0
    Works fine!
    AptioMemoryFix.efi.zip
  25. Like
    Trung_Nguyen reacted to MaLd0n in ACPI Error slow boot down   
    DSDT.aml.zip
    use patch ECDV to EC
    change ECDV to EC 45434456  45435f5f 
×