Gigabyte Aero 15 v8 (FB0A BIOS Unlocked)

Disclaimer: Do this at your OWN RISK! I will not be held responsible for anyone bricking their machine!

I made the mods based on @Lost_N_BIOS's post here and by following the How-2-Rip-It-Open-Yourself guide here.

This patch has been confirmed to work with both 15X v8 and 15W v8 models. Make sure you have your Aero's BIOS flashed to version FB0A using the official release on the Gigabyte website here before attempting the following.

First you must run command prompt (as Administrator) and run "FPTw.exe -bios -d biosreg.bin". You can get FPTw.exe from Intel CSME System Tools v12 r18 (located in the "Flash Programming Tool" folder).

Next you will need to run UEFITool 0.26.0 and open biosreg.bin. Select File->Search... Text tab and enter AMITSE. A list of search results will show at the bottom. Double click on "Unicode text "AMITSE" found in User interface section at offset 0h". Right click on the "PE32 image section" and select "Replace as is...". Browse to the (unzipped) file attached (Section_PE32_image_AMITSE_AMITSE.zip). File->Save image file... and call it biosmod.bin.

Then you need to run AMIBCP 5.02.0031 and open biosmod.bin to set the menu access to USER like so:

Once you File->Save run "FPTw.exe -bios -f biosmod.bin".

If you get the following error:

Quote:Error 167: Protected Range Registers are currently set by BIOS, preventing flash access.

This is caused by the BIOS Lock variable set to 0x01 (Enabled):
Code:
BIOS Lock, VarStoreInfo (VarOffset/VarName): 0xA12

How to set the BIOS Lock variable to 0x00 (Disabled):

  1. Make sure you have following values set in BIOS:
      - Legacy Support: Disable
      - Secure Boot: Disable
  2. Take USB stick and format to FAT32
  3. Create directory structure EFI\Boot
  4. Download and unzip bootx64.7z
  5. Put BOOTX64.EFI into Boot directory
  6. Boot from this USB stick
  7. Run command: setup_var 0xA12 0x00
  8. Run command: reboot

Attempt to write the modified BIOS again using FPTw.exe.

If successful this time run "FPTw.exe -greset" to reboot.

Press F2 to enter BIOS you should (hopefully) be greeted with some extra menus...



Big thanks to @Lost_N_BIOS!

USB KVM

Menu bar software for macOS 64-bit to support ActionStar chip based KVM hardware.

Vendor ID 0x2101 / 0x0835 is ActionStar (www.actionstar.com.tw)

Supported Hardware:

2101:1403, 2101:1404, 2101:1406, 2101:1407, 2101:1411, 0835:1403, 0835:1404, 0835:1406, 0835:1407, 0835:1411

Credits:

Source

GitHub Link

BrcmPatchRAM2 for macOS 10.15 Catalina

I'm just going to run through some of the changes I made to RehabMan's BrcmPatchRAM project for it to function in macOS Catalina. I don't really have time to go any further with it but hopefully my research and testing can help get an official working version out.

I'm using BrcmFirmwareData.kextBrcmPatchRAM2.kext and BrcmBluetoothInjector.kext and place them inside EFI/CLOVER/kexts/Other

BrcmBluetoothInjector.kext was not required on previous macOS releases but is on Catalina because of the following missing IOCatalogue methods:

kxld[com.no-one.BrcmPatchRAM2]: The following symbols are unresolved for this kext:
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::addDrivers(OSArray*, bool)
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::removeDrivers(OSDictionary*, bool)
kxld[com.no-one.BrcmPatchRAM2]: IOCatalogue::startMatching(OSDictionary*)

Since these methods are no longer available they must be removed from the project. The easiest way to do this is to comment out publishPersonality() and publishResourcePersonality() methods from BrcmPatchRAM.cpp / BrcmPatchRAM.h. Also remove all calls to these methods in BrcmPatchRAM.cpp.

The next issue is dealing with the 0xe00002c2 error when reading and writing to the BRCM hardware. Starting with BrcmPatchRAM::continuousRead() and BrcmPatchRAM::readCompletion() we need to add an kIODirectionIn option.

ie.
mReadBuffer = IOBufferMemoryDescriptor::inTaskWithOptions(kernel_task, kIODirectionIn, 0x200);

IOReturn result = mReadBuffer->prepare(kIODirectionIn);

IOReturn result = me->mReadBuffer->complete(kIODirectionIn);

Next in BrcmPatchRAM::bulkWrite we need to add kIODirectionOut options.

if (IOMemoryDescriptor* buffer = IOMemoryDescriptor::withAddress((void*)data, length, kIODirectionOut))

if ((result = buffer->prepare(kIODirectionOut)) == kIOReturnSuccess)

if ((result = buffer->complete(kIODirectionOut)) != kIOReturnSuccess)

Now that we don't have IOCatalogue::addDriversIOCatalogue::removeDrivers and IOCatalogue::startMatching methods to switch from using the uploader driver to native macOS driver we have to use BrcmBluetoothInjector.kext instead.

So my Bluetooth device is a BCM20702A0 with VendorID 0x0A5C and ProductID 0x216F (Dell DW1560 4352+20702 M.2) located in internal USB port HS14. So I'll use it as an example for the following modifications.

In BrcmPatchRAM2-Info.plist we need the following entry. Note the addition of the IOProbeScore. When the kext is loaded it will call BrcmPatchRAM::probe which will update the firmware and return NULL and then the BrcmBluetoothInjector.kext should load instead.

        <key>0a5c_216f</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.no-one.$(PRODUCT_NAME:rfc1034identifier)</string>
            <key>DisplayName</key>
            <string>DW1560 Bluetooth 4.0 LE</string>
            <key>FirmwareKey</key>
            <string>BCM20702A1_001.002.014.1443.1572_v5668</string>
            <key>IOClass</key>
            <string>BrcmPatchRAM2</string>
            <key>IOMatchCategory</key>
            <string>BrcmPatchRAM2</string>
            <key>IOProviderClass</key>
            <string>IOUSBHostDevice</string>
            <key>IOProbeScore</key>
            <integer>4000</integer>
            <key>idProduct</key>
            <integer>8559</integer>
            <key>idVendor</key>
            <integer>2652</integer>
        </dict>

In BrcmBluetoothInjector-Info.plist we need the following entry. Note again the addition of the IOProbeScore. We want the BrcmBluetoothInjector.kext to load the macOS kext after the firmware has been uploaded to the hardware. Since BrcmBluetoothInjector.kext has not been updated in a long time you may need to add your hardware manually to the plist. Note that your Bluetooth device VendorID / ProductID is not the same as your WiFi hardware and will not show up in your PCI list. You will need to look at the USB ports to get this info.

        <key>0a5c_216f</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string>
            <key>IOClass</key>
            <string>BroadcomBluetoothHostControllerUSBTransport</string>
            <key>IOProviderClass</key>
            <string>IOUSBHostDevice</string>
            <key>IOProbeScore</key>
            <integer>3000</integer>
            <key>idProduct</key>
            <integer>8559</integer>
            <key>idVendor</key>
            <integer>2652</integer>
        </dict>

You will know the firmware is uploaded when its version in About This Mac->System Report...->Bluetooth shows something like:

 Firmware Version:    v14 c5668

If it shows 4096 then the upload has failed.

I will attach my compiled versions for people to help test. I'm not 100% sure if this is method is going to work so I'd appreciate feedback on it.

Downloads (acidanthera)