renato97/hackintosh-asus-b760-i7-13700k
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: clean unnecessary markdown files for CV sharing

Browse Source
This commit is contained in:
Renato97
2026-03-31 01:16:14 -03:00
parent d7dbebb239
commit fd088f9c7e
45 changed files with 0 additions and 13472 deletions
Download Patch File Download Diff File Expand all files Collapse all files

184
hackintosh-guide/Utilities/EnableGop/README.md
View File

@@ -1,184 +0,0 @@
# Provides standalone GOP driver for EFI era Mac Pro and iMac
## Releases
EnableGop version (OpenCore version)
### 1.4 (0.9.3)
- Incorporates recent updates to OpenCore console control code, but no difference in behaviour compared
to version 1.3 is expected on any supported systems.
### 1.3 (0.9.2)
- Included fix to GopBurstMode for non-standard frame buffer information on AMD Radeon HD 7970 and similar
- Applied GopBurstMode even on natively supported cards, as it can provide a noticable speed up
### 1.2 (0.9.1)
- Added GopBurstMode support
*Note 1*: This should provide faster GOP rendering on all EnableGopDirect systems; and rendering at least at
the same speed as before, and on some systems noticeably faster than before, on almost all EnableGop systems.
*Note 2*: The compressed driver for version 1.2 is 1KB larger than for version 1.1, so for AMD GPU firmware which is
tight on space version 1.1 may be used instead to avoid the need for VGA stripping to make additional space.
### 1.1 (0.9.0)
- Fixed early verbose boot lines appearing over picker
- Added EnableGop version number to UI section
### 1.0 (0.8.9)
- Initial public release
## Status
**Current status: Beta release.**
This driver has been tested and is working on several iMac models
with several different GPUs, and on several MacPro4,1/5,1 machines with several different GPUs. However, in the worst
case (and still possible) scenario, an incompatible or incorrectly installed driver
in firmware may brick your hardware.
*In all cases take a backup of the main firmware or GPU firmware which you are modifying, and confirm that
you can successfully restore from this, before starting.*
## Recovery from bricked hardware
- If attempting main firmware insertion on a MacPro4,1/5,1, for recovery from a bricked device you will either
need a Matt card (which may breach intellectual property laws in some jurisdictions) or the ability to
desolder and reprogram your own SPI flash chip.
- If testing via main firmware insertion on an iMac, you will need the ability to disassemble your iMac and
reprogram its SPI flash chip using a SOIC clip attached to a CH341A controller running on another computer.
- If testing via GPU firmware insertion (iMac or Mac Pro), you will need the ability to disassemble your system,
likely remove the heat sink from the graphics card, and then reprogram its SPI flash chip using a SOIC
clip attached to a CH341A controller running on another computer.
- If testing via GPU firmware insertion, in some cases it may also be possible
to use physical electrical connection to your GPU in order to enable booting with no graphics even though the GPU
is present, then connect to your machine with `ssh` (which must have been enabled beforehand) and reprogram the GPU
firmware. Advice on this headless boot approach is not provided here, but may be found for instance on the iMac GPU
related forum threads listed below.
*If you are not familiar with the above procedures, you are strongly recommended to wait for further testing by
users who are. No further help can be provided here, and you proceed entirely at your own risk.*
## Summary
Targetting EFI-era (~2009-2012) MacPro4,1/5,1 and iMac firmware, this driver gathers and injects the parts of
OpenCore needed for pre-boot graphics support with non-natively supported GPUs.
The requirements for using this driver are:
- EFI-era (~2009-2012) MacPro4,1/5,1 or iMac with most recent main firmware.
- A GPU which does not produce native pre-boot graphics (such as native picker when pressing ALT key during boot)
before OpenCore starts (otherwise, you do not need it).
- A GPU which produces graphics when using OpenCore (this must include successfully showing the native Apple boot
picker when started via the latest version of OpenCore tool `BootKicker.efi`) (otherwise, the driver will not work).
- *Note*: If your OpenCore installation includes a required GOP driver for your graphics card, then you would
also need to burn that driver to the firmware of your graphics card in order to obtain pre-OpenCore graphics;
instructions for this are outside the scope of this tutorial, although the procedures required for modifying
GPU firmware are similar to what is covered here.
Note that such a driver is added by the OCLP **Enable AMD GOP** option, which is enabled automatically on some
systems by recent versions of OpenCore Legacy Patcher, as a way to enable the OpenCore menu in cards such as ex-mining GPUs.
When installed, the driver should enable:
- Native boot picker via ALT key
- Firmware password UI
- Target disk mode UI
- macOS boot progress screen
- etc.
Compiled versions of the driver files and these instructions may be found in the `Utilities/EnableGop`
directory of the OpenCore release package.
For GPUs needing `DirectGopRendering` in OpenCore configuration, use `EnableGopDirect.efi`, otherwise use `EnableGop.efi`
as it renders faster on most other systems.
The driver may be installed to GPU or main motherboard firmware. It is expected that most Mac Pro users will use main firmware insertion
and most iMac users will chose GPU firmware insertion, however both techniques work on both systems (but it is harder to modify the
iMac main firmware, since there is no simple way to enable writing to it).
Further discussion and community support for this driver is available at:
- https://forums.macrumors.com/threads/pre-opencore-gop-support-for-efi-era-imacs-and-mac-pros.2378942/
## Usage
## Install to main firmware
For reading and writing to main firmware on the Mac Pro, @Macschrauber's [Rom Dump](https://github.com/Macschrauber/Macschrauber-s-Rom-Dump) works
well. Alternatively the kexts and executables which this uses can be sourced individually (or extracted from the Rom Dump app) and
run from the command line.
The main firmware on the iMac cannot be updated without an initial hardware flash (SOIC clip plus CH341A controller), therefore
the recommended approach on iMac systems is [GPU firmware injection](#install-to-gpu-firmware). However, the below instructions for firmware
injection do work, if you are willing to do a hardware flash of the resulting firmware file, or if you have already
[unprotected your iMac firmware](https://forums.macrumors.com/threads/imac-2011-see-more-uefi-firmware-mod.2257435/page-3?post=31087001#post-31087001) -
which reduces security, and is only recommended for those actively developing firmware modifications.
The `.ffs` file provided in this directory can be manually added to the extracted firmware file using [`UEFITool`](https://github.com/LongSoft/UEFITool),
or automatically added using @dosdude1's [`DXEInject`](https://dosdude1.com/apps/). Once more, if you are not familiar with these procedures,
you are recommended to proceed with extreme caution.
### Using DXEInject
To install the driver via `DXEInject`, the command is:
- `DXEInject {original}.rom {modified}.rom EnableGop.ffs`
The file `{modifed}.rom` is ready for burning, although the result can be checked using UEFITool, if required.
> *Note*: If only reading a file with UEFITool, the latest version is recommended, as it provides the most information.
For writing, the older version 0.25.1 must be used, as described below.
### Using UEFITool
The `.ffs` file may be inserted anywhere within the same firmware volume which contains `DuetBds`
(file GUID `A6F691AC-31C8-4444-854C-E2C1A6950F92`). However, for simplicity, these instructions
will insert it in the same place that `DXEInject` does:
- Use UEFITool 0.25.1 (it must be that old version, not the newer NE or new engine versions, which
cannot yet edit)
- Perform a header-only GUID search for `BAE7599F-3C6B-43B7-BDF0-9CE07AA91AA6`
- Double-click on the search result
- Right-click on the DXE driver with that GUID which should then appear
- Choose "Insert after..." and select `EnableGop.ffs`
- Save the modified firmware
The end result, after saving and re-loading, should look like this:
<img src="UEFITool_Inserted_Screenshot.png">
## Install to GPU firmware
Instructions and a script for inserting the driver into Nvidia or AMD GPU firmware (aka VBIOS) are provided.
Please note all the cautions already given above about the difficulty of recovering, unless you are familiar with
the procedures necessary, if this process fails.
To use the provided `vBiosInsert.sh` script:
- Locate an appropriate version of the `nvflash` tool (Nvidia) or `amdvbflash` tool (AMD) (both are available for
Linux and Windows), which can be used to read from and write to the GPU firmware.
- Use that tool to read a copy of the GPU firmware.
- Run `./vBiosInsert.sh [-a|-n] {original}.rom EnableGop.efi {modified}.rom`, with `-a` for AMD and `-n` for Nvidia.
- If you have any problems with `vBiosInsert.sh` from a specific release
of EnableGop, please try the version included with the latest release of OpenCore
before reporting any issues.
The script receives updates to support additional graphics cards independently
of any bumps to the release version of EnableGop. If you need to, you can use
the latest version of `vBiosInsert.sh` to inject older versions of EnableGop.
- The new file `{modified}.rom` may be burnt to the GPU firmware.
In the case of AMD, considerably less space is normally available, due to a strict limit of 128k for legacy and EFI
parts of the larger ROM image. If there is not enough space (i.e. script reports
data would be truncated) then it is necessary to [strip some legacy VGA parts of the
GPU firmware](https://github.com/Ausdauersportler/IMAC-EFI-BOOT-SCREEN/wiki/Deleting-the-VGA). This is beyond the scope
of these instructions.
If required to manually detect the GOP offset (this should normally be autodetected):
> Using a hex editor, search in the GPU firmware dump for the byte sequence `F1 0E 00 00` with the byte sequence `55 AA` coming
close before it; the start address of the `55 AA` is the GOP offset value needed.
For further information on GPU firmware modification, see:
- https://forums.macrumors.com/threads/2011-imac-graphics-card-upgrade.1596614/
- https://forums.macrumors.com/threads/imac-2011-maxwell-and-pascal-gpu-upgrade.2300989/
- https://github.com/Ausdauersportler/IMAC-EFI-BOOT-SCREEN/wiki
- https://winraid.level1techs.com/t/amd-and-nvidia-gop-update-no-requests-diy/30917

4
hackintosh-guide/Utilities/FindSerialPort/README.md
View File

@@ -1,4 +0,0 @@
FindSerialPort
================
This script finds PCIe serial ports and outputs their paths. Thanks [joevt](https://github.com/joevt) for writing it.

7
hackintosh-guide/Utilities/LegacyBoot/README.md
View File

@@ -1,7 +0,0 @@
BootInstall
===========
This tool installs legacy DuetPkg environment on GPT-formatted disk
to enable UEFI environment on BIOS-based systems.
Source code: https://github.com/acidanthera/DuetPkg

17
hackintosh-guide/Utilities/LogoutHook/README.md
View File

@@ -1,17 +0,0 @@
# LogoutHook
## Script
### Usage
```./Launchd.command```
### Installation
```./Launchd.command install```
### Status
```./Launchd.command status```
Shows non-empty daemon pid only, if installed with default settings.
### Log
```/var/log/org.acidanthera.nvramhook.launchd/launchd.log```

107
hackintosh-guide/Utilities/ShimUtils/README.md
View File

@@ -1,107 +0,0 @@
## OpenCore + OpenLinuxBoot + Secure Boot
If you want to use OpenCore + OpenLinuxBoot + Secure Boot it is possible to sign everything
manually yourself, including any new Linux kernels after updates. This is possible since most
standard distros leave at least the previous kernel bootable (and OpenLinuxBoot exposes
this, via the Auxiliary menu), so you can boot into the old kernel, then sign the new
kernel yourself.
More convenient may be to trust the signing keys of the specific distros which you
want to boot, which are bundled into the `shimx64.efi` file installed with each distro.
You can extract these with `shim-to-cert.tool` distributed with OpenCore, then install
them in your system Secure Boot `db` variable. Best practice would be to install the deny
list (`vendor.dbx`) from `shimx64.efi`, if any, into your system `dbx` variable, as well.
(Otherwise you are ignoring any revocations which the vendor has made.)
Recently, Shim has added SBAT support, as a more efficient way to revoke unsafe
binaries. Unfortunately, the SBAT enforcement code is part of Shim, and is not
something you can extract and add to your system Secure Boot database.
To work round this, the new recommended way to boot OpenCore + OpenLinuxBoot +
Secure Boot is to make a user build of Shim. The vendor certificates
and revocation lists extracted from the distro `shimx64.efi` files are combined
and signed by you, into your own build of Shim; in this approach, these vendor
certificates should NOT also be included in the system Secure Boot database,
and should be removed if you added them previously. Including them in both places
will still boot under Secure Boot, but will effectively disable SBAT revocation.
> If you are signing everything yourself, including Linux kernels after updates, that
will still work as before and the below is not needed. Equally, if you are not
using Secure Boot the below is not needed.
The advantages of using a user build of Shim are:
- No need to sign every kernel after updates (same as previous method)
- Linux SBAT integration (new)
- Linux MOK integration (new)
- No need to include the Windows intermediate CA - you are trusting whichever distro
keys you choose to include in your own Shim, directly (new)
Disadvantages are:
- Need to update when distro keys or distro revocation lists within Shim are updated
(same as previous method)
- Need to udpate when Shim SBAT level is updated (new)
### Method
`Utilities/ShimUtils` includes a script `shim-make.tool` which will download the
current Shim source and build it for you, on macOS (using Ubuntu multipass) or on
Linux (Ubuntu and Fedora supported, others may work).
- Extract `vendor.db` and `vendor.dbx` files from the `shimx64.efi` file of each distro
which you want to load (using `shim-to-cert.tool`)
- For non-GRUB distros, the required public keys for this process cannot be extracted
from `shimx64.efi` and so must be found by additional user research
- Concatentate these (e.g. `cat fedora/vendor.db ubuntu/vendor.db > combined/vendor.db`
and `cat fedora/vendor.dbx ubuntu/vendor.dbx > combined/vendor.dbx`)
- Do not concatenate `.der` files directly, it will not work
- If you have a single distro with a single `.der` file, you can use `VENDOR_CERT_FILE`
instead of `VENDOR_DB_FILE` in the `make` options below; otherwise, you will need to use
`cert-to-efi-sig-list` from `efitools` to convert the `.der` file to a sig list - this
is done automatically by `shim-to-cert.tool` when `efitools` are available (in
Linux; or from within Ubuntu multipass on macOS, e.g. `multipass shell oc-shim`)
- Build a version of Shim which includes these concatenated signature lists (and
launches OpenCore.efi directly):
- `./shim-make.tool setup`
- `./shim-make.tool clean` (only needed if remaking after the initial make)
- `./shim-make.tool make VENDOR_DB_FILE={full-path-to}/vendor.db VENDOR_DBX_FILE={full-path-to}/vendor.dbx`
- On macOS, the paths to these files must either be within the multipass VM, or
within a subdirectory visible to macOS and the VM on the same path, such as
`/Users/{username}/shim_root` when using `shim-make.tool` default settings
- Copy the relevant files (`shimx64.efi` and `mmx64.efi` as well as `BOOTX64.CSV`) to your mounted ESP volume, e.g.:
- `./shim-make.tool install /Volumes/EFI` (macOS)
- `sudo ./shim-make.tool install /boot/efi` (Linux)
- Sign the newly built `shimx64.efi` and `mmx64.efi` with your own ISK (see e.g.
https://habr.com/en/articles/273497/ - Google translate is your friend)
- If you do not copy and sign `mmx64.efi` as well as `shimx64.efi`, your system will hang if any MOK operations are attempted
- `BOOTX64.CSV` is not required and is for information only
As before you need to sign `OpenCore.efi` and any drivers it loads with your ISK.
You now also need to add an empty SBAT section to `OpenCore.efi` before signing it.
> An empty SBAT section means: 'I'm not part of the system which allocates SBAT names
and signs them into boot files, and I don't want this boot file to be revoked by any
future SBAT revocations'. Of course, you can still revoke boot files you signed yourself
by rotating your own signing keys.
As noted [here](https://github.com/fwupd/fwupd/issues/2910) and
[here](https://github.com/rhboot/shim/issues/376),
the [documented](https://github.com/rhboot/shim/blob/main/SBAT.md) method for adding an
SBAT section to an already-linked `.efi` file does not work correctly (GNU `objcopy`
corrupts the executable). This
[third party python script](https://github.com/rhboot/shim/issues/376#issuecomment-1628004034)
does work. A suitable command is:
`pe-add-sections.py -s .sbat <(echo -n) -z .sbat -i OpenCore.efi -o OpenCore_empty_sbat.efi`
This file then needs to be signed and copied back into place, e.g.:
`sbsign --key {path-to}/ISK.key --cert {path-to}/ISK.pem OpenCore_empty_sbat.efi --output OpenCore.efi`
Finally, in order for OpenCore integration with Shim to work correctly
`UEFI/Quirks/ShimRetainProtocol` must be enabled in `config.plist`, and
`LauncherPath` should be set to `\EFI\OC\shimx64.efi`.
> Using Ubuntu multipass, it is now possible to operate entirely within macOS for signing,
key generation, etc. Note that the `~/shim_root` directory is already shared between
macOS and the `oc-shim` multipass VM (under its macOS path, e.g. `/Users/username/shim_root`),
and other macOS folders and volumes can be mounted if you wish, e.g.
`multipass mount /Volumes/EFI oc-shim:/Volumes/EFI`.

8
hackintosh-guide/Utilities/macrecovery/README.md
View File

@@ -1,8 +0,0 @@
## macrecovery
macrecovery is a tool that helps to automate recovery interaction. It can be used to download diagnostics and recovery as well as analyse MLB.
Requires python3 to run. Run with `-h` argument to see all available arguments.
To create a disk image for a virtual machine installation use `build-image.sh`.

224
hackintosh-guide/Utilities/macserial/FORMAT.md
View File

@@ -1,224 +0,0 @@
Apple Mac Serial Format
=======================
It is reasonably important to get more information about the goods you buy, especially if they are not new, and you do not have absolute confidence in the seller. Serial numbers are the first thing to look at. For Apple products [Apple Check Coverage](https://checkcoverage.apple.com) is your best friend.
However, it does not show all the details encoded in the serial, and in some case it may be important. For example, certain shady dealers may change one valid serial by the other, and it will not be obvious at a glance that the serial does not belong to the actual model. This FAQ attempts to explain the reverse-engineered structure of the serials used in Apple hardware.
You could always receive information about the current serial number of your Mac by running `./macserial`. For the other serial use `./macserial -i SERIALNUMBER`, where `SERIALNUMBER` is the serial you check.
## Apple base 34
Select fields in the numbers are encoded values in base 34. So, certain alpha-numeric characters represent a slightly uncommon base 34 code excluding `O` and `I`.
| Char | Value | Char | Value |
| ---- | ----- | ---- | ----- |
| `0` | `0` | `H` | `17` |
| `1` | `1` | `J` | `18` |
| `2` | `2` | `K` | `19` |
| `3` | `3` | `L` | `20` |
| `4` | `4` | `M` | `21` |
| `5` | `5` | `N` | `22` |
| `6` | `6` | `P` | `23` |
| `7` | `7` | `Q` | `24` |
| `8` | `8` | `R` | `25` |
| `9` | `9` | `S` | `26` |
| `A` | `10` | `T` | `27` |
| `B` | `11` | `U` | `28` |
| `C` | `12` | `V` | `29` |
| `D` | `13` | `W` | `30` |
| `E` | `14` | `X` | `31` |
| `F` | `15` | `Y` | `32` |
| `G` | `16` | `Z` | `33` |
## Serial number (SN)
There generally are 2 similar formats of serial encoding: the old 11 character format, and the new 12 character format.
| Type | Location | Year | Week | Line | Product |
| --------- | --------- | ---- | ---- | ----- | -------- |
| Old (11) | `LL` | `Y` | `WW` | `SSS` | `PPP` |
| New (12) | `LLL` | `Y` | `W` | `SSS` | `PPPP` |
Note: Models late 2021+ contain SN with 10 character format.
### Location
This value encodes the manufacturing location, which is often more descriptive than `Made in China`, since it may reveal the responsible company and the city. For example, `F5K` means `USA (Flextronics)` and `QT` means `Taiwan (Quanta Computer)`. The list is not standardised or published anywhere, but you can see several known locations by running `./macserial -l`.
One of the important locations for old-style serials (11 characters) is `RM`. It means that the model was refurbished. For new-style serials you have to call [Apple support](https://support.apple.com) to know this.
### Year
Year encodes the actual manufacturing year of each model. For refurbished models it is unknown whether it is replaced by the remanufacturing year.
For old-style serials it always is a digit that encodes the last digit of the year. For example, `8` means 2008 and `1` means 2011. Only `0` to `9` digitis are used for year encoding. Old-style serials are out of use starting with 2013, so `3` means 2003 not 2013.
| Char | Year |
| ---- | ---- |
| `3` | 2003 |
| `4` | 2004 |
| `5` | 2005 |
| `6` | 2006 |
| `7` | 2007 |
| `8` | 2008 |
| `9` | 2009 |
| `0` | 2010 |
| `1` | 2011 |
| `2` | 2012 |
For new-style serials it is an alphanumeric value, which not only encodes the year, but its half as well. Not all the values are allowed. The table below outlines the pairs of characters which are assumed to encode each supported year. First character in the pair is believed to encode the first half of the year, and the second character — the second half.
| Pair | Year |
| -------- | ---- |
| `C`, `D` | 2010 |
| `F`, `G` | 2011 |
| `H`, `J` | 2012 |
| `K`, `L` | 2013 |
| `M`, `N` | 2014 |
| `P`, `Q` | 2015 |
| `R`, `S` | 2016 |
| `T`, `V` | 2017 |
| `W`, `X` | 2018 |
| `Y`, `Z` | 2019 |
| `C`, `D` | 2020 |
| `F`, `G` | 2021 |
### Week
Week encodes the actual manufacturing week of each model. This week has nothing in common with [ISO 8601](https://en.wikipedia.org/wiki/ISO_week_date), and appears to be encoded literally as 7-day sequences starting from January, 1st. Since each year has either 365 or 366 days, 53rd week is extremely rare, and you are lucky to have such a serial.
For old-style serials week is encoded in plain numeric digits with leading zeroes. `01`, `02`, ... `53`. For new-style serials an alpha-numeric code is used. Encoded year half also counts and means adds 26 weeks for the second one.
| Char | 1st half | 2nd half |
| ---- | -------- | -------- |
| `1` | `1` | `27` |
| `2` | `2` | `28` |
| `3` | `3` | `29` |
| `4` | `4` | `30` |
| `5` | `5` | `31` |
| `6` | `6` | `32` |
| `7` | `7` | `33` |
| `8` | `8` | `34` |
| `9` | `9` | `35` |
| `C` | `10` | `36` |
| `D` | `11` | `37` |
| `F` | `12` | `38` |
| `G` | `13` | `39` |
| `H` | `14` | `40` |
| `J` | `15` | `41` |
| `K` | `16` | `42` |
| `L` | `17` | `43` |
| `M` | `18` | `44` |
| `N` | `19` | `45` |
| `P` | `20` | `46` |
| `Q` | `21` | `47` |
| `R` | `22` | `48` |
| `T` | `23` | `49` |
| `V` | `24` | `50` |
| `W` | `25` | `51` |
| `X` | `26` | `52` |
| `Y` | `-` | `53` |
For old-style serials it is a pair of two digits, which encode the manufacturing week.
### Production line and copy
Production line is believed to be related to some identifier at assembly stage. It is encoded in base 34, but the actual derivation process is unknown and can only be guessed with relative success.
Current model, which apparently works well, represents it as a sum of three alpha-numeric characters with `1`, `34`, and `68` multipliers. The actual formula looks as follows:
```
base34[S1] * 68 + base34[S2] * 34 + base34[S3] = production line
```
This formula effectively defines a compression function, which allows to encode a total of `3400` production lines from `0` to `3399`. The compression produced by shortening `39304` space to `3400` allows multiple encodings of the same line. For example, for `939` line there can be `14` derivatives or "copies": `0TM`, `1RM`, `2PM`, `3MM`, `4KM`, ..., `D1M`.
While the formula does look strange, it was experimentally discovered that up to `N` first encoded derivatives are valid, and starting with the first invalid derivative there will be no valid ones. Thus for a complete serial list made up with all the derivatives from the above the following is assumed to be true: if `0TM` and `2PM` are valid and `3MM` is invalid, then `1RM` will also be valid, and `4KM` to `D1M` will be invalid. From this data it could be theorised that the encoded value is incremented for each model produced from the same line. So `0TM` is the first copy produced, and `D1M` is the last copy.
**Update**: At a later stage very few examples of valid derivatives after invalid were found. These exceptions disprove at least some parts of the model, but currently there exists no better theory.
### Product model
Last 3 (for legacy serials) or 4 (for new serials) symbols encode the actual product identifier of this exact piece of the hardware. This is probably the most useful part of the serial, since it allows you to get the detailed description of your hardware directly from the dedicated Apple Specs portal. To do so you need to modify the following URI to contain your real product code instead of `PPPP` and follow it in your browser:
```
http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP
```
For example, for iMacPro1,1 it could be [HX87](http://support-sp.apple.com/sp/index?page=cpuspec&cc=HX87) and for MacBookPro14,3 it could be [HTD5](http://support-sp.apple.com/sp/index?page=cpuspec&cc=HTD5).
The list is not standardised or published anywhere, but you can see most products by running `./macserial -lp` and `./macserial -l` to match against mac models. The value seems to be a classic base 34 sequence: `P1 * 39304 + P2 * 1156 + P3 * 34 + P4`. The ranges seem to be allocated in chunks in non-decreasing manner. Normally each chunk is distanced from another chunk by up to 64 (90% matches).
## Logic board serial number (MLB)
There generally are 2 formats of logic board serial encoding: the old 13 character format, and the new 17 character format. Unlike serial number, these formats are quite different and in addition very little is known about MLB in general.
| Type | Location | Year | Week | Item | Infix | Product | Suffix |
| --------- | --------- | ---- | ---- | ------ | ------ | -------- | ------ |
| Old (13) | `LL` | `Y` | `WW` | `IIII` | | `EEE` | `C` |
| New (17) | `LLL` | `Y` | `WW` | `III` | `AA` | `EEEE` | `CC` |
While it is unclear if this is intentional, for 17 character MLB it is possible to perform basic validation online through `osrecovery.apple.com`. The recovery server will return valid latest recovery image only when MLB is valid. Use `./macrecovery.py verify -m MLB -b BOARD-ID` to try verifying your MLB number.
It is not clear how strongly MLB is attached to serial number (SN). The following is known:
- Minimal supported macOS version is identified by `EEEE`
- Maximum supported macOS version is identified by `EEEE` and `board-id`
- Recovery server accepts a range of models with the same MLB (with only latest os different)
The following is suspected:
- `EEEE` is unique number for all MLBs
- `EEEE` are shared across different models and thus cannot identify the model
### Location
MLB location is equivalent to serial number location but does not necessarily match it, as logic boards can be manufactured at a different place.
### Year and week
MLB year and week in both 13-character and 17-character MLB are equivalent to legacy serial number year and week. The values are slightly lower as logic board is manufactured prior to the complete product.
### Item
MLB item is encoded differently for 13-character and 17-character MLB. It might serve as a production item per week and could be similar to 'Production line and copy' in the serial number.
- For old MLB, this is a variant of base 34 value. First item character is always `0`.
- For new MLB, this value always is a number.
### Infix
Base 34 value present in new MLBs only. No information is known about it. Could actually be part of Item.
### Product board
Similarly to 'Product model' this field encodes logic board model number. This code is often referred to as `EEE code` in part catalogues and is useful for purchasing a compatible logic board for replacement.
For new 17 character MLBs this field is also used for identification at `osrecovery.apple.com` to provide a compatible internet recovery image and diagnostic tools upon request.
### Suffix
Base 34 value with unclear designation. Might be used for checksum validation. Checksum validation algorithm is reverse engineered from diagnostics tools and is valid for all 17 character MLBs. It is not clear whether 13 character MLBs have any checksum. 17 character MLB checksum follows.
```C
static bool verify_mlb_checksum(const char *mlb, size_t len) {
const char alphabet[] = "0123456789ABCDEFGHJKLMNPQRSTUVWXYZ";
size_t checksum = 0;
for (size_t i = 0; i < len; ++i) {
for (size_t j = 0; j <= sizeof (alphabet); ++j) {
if (j == sizeof (alphabet))
return false;
if (mlb[i] == alphabet[j]) {
checksum += (((i & 1) == (len & 1)) * 2 + 1) * j;
break;
}
}
}
return checksum % (sizeof(alphabet) - 1) == 0;
}
```
## Appendix
This information was obtained experimentally and may not be accurate in certain details. Be warned that it is published at no warranty for educational and introductory purposes only.

7
hackintosh-guide/Utilities/macserial/README.md
View File

@@ -1,7 +0,0 @@
## macserial
macserial is a tool that obtains and decodes Mac serial number and board identifier to provide more information about the production of your hardware. Works as a decent companion to [Apple Check Coverage](https://checkcoverage.apple.com) and [Apple Specs](http://support-sp.apple.com/sp/index?page=cpuspec&cc=HTD5) portal. Check the [format description](https://github.com/acidanthera/OpenCorePkg/blob/master/Utilities/macserial/FORMAT.md) for more details.
Should be built with a compiler supporting C99. Prebuilt binaries are available for macOS 10.4 and higher.
Run with `-h` argument to see all available arguments.

140
hackintosh-guide/Utilities/ocvalidate/README.md
View File

@@ -1,140 +0,0 @@
ocvalidate
====================
Utility to validate whether a `config.plist` matches requirements and conventions imposed by OpenCore.
## Usage
- Pass one single path to `config.plist` to verify it.
- Pass `--version` for current supported OpenCore version.
## Technical background
### At a glance
- ocvalidate firstly calls `OcSerializeLib` which performs fundamental checks in terms of syntax and semantics. After that, the following will be checked.
- The error message `<OCS: No schema for xxx>` complained by `OcSerializeLib` indicates unknown keys that can be deprecated in new versions of OpenCore. Such keys should be ***removed*** in order to avoid undefined behaviours.
- Under active development, newer versions of OpenCore hardly have backward compatibility at this moment. As a result, please first run `ocvalidate --version` to check which version of OpenCore is supported, and thus please only use the specific version.
### Global Rules
- All entries must be set once only. Duplication is strictly prohibited.
- All strings (fields with plist `String` format) throughout the whole config only accept ASCII printable characters at most. Stricter rules may apply. For instance, some fields only accept specified values, as indicated in [Configuration.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Configuration.pdf).
- All the paths relative to OpenCore root must be less than or equal to 192 bytes (`OC_STORAGE_SAFE_PATH_MAX`) in total including '\0' terminator.
- Most binary patches must have `Find`, `Replace`, `Mask` (if used), and `ReplaceMask` (if used) identical size set. Also, `Find` requires `Mask` (or `Replace` requires `ReplaceMask`) to be active (set to non-zero) for corresponding bits.
- `MinKernel` and `MaxKernel` entries should follow conventions specified in [Configuration.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Configuration.pdf). (TODO: Bring decent checks for this)
- `MinKernel` cannot be a value that is below macOS 10.4 (Darwin version 8).
- Entries taking file system path only accept `0-9, A-Z, a-z, '_', '-', '.', '/', and '\'`.
- Device Paths (e.g. `PciRoot(0x0)/Pci(0x1b,0x0)`) only accept strings in canonic string format.
- Paths of UEFI Drivers only accept `0-9, A-Z, a-z, '_', '-', '.', and '/'`.
- Entries requiring bitwise operations (e.g. `ConsoleAttributes`, `PickerAttributes`, or `ScanPolicy`) only allow known bits stated in [Configuration.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Configuration.pdf) to be set.
- Entries involving GUID (mainly in Section `NVRAM`) must have correct format set.
### ACPI
#### Add
- Entry[N]->Path: Only `.aml` and `.bin` filename suffix are accepted.
### Booter
#### MmioWhitelist
- Entry[N]->Enabled: When at least one entry is enabled, `DevirtualiseMmio` in `Booter->Quirks` should be enabled.
#### Patch
- Entry[N]->Arch: Only `Any`, `i386`, or `x86_64` are accepted.
- Entry[N]->Identifier: Only `Any`, `Apple`, or a specified bootloader with `.efi` sufffix, are accepted.
#### Quirks
- When `AllowRelocationBlock` is enabled, `ProvideCustomSlide` should be enabled altogether.
- When `EnableSafeModeSlide` is enabled, `ProvideCustomSlide` should be enabled altogether.
- If `ProvideMaxSlide` is set to a number greater than zero, `ProvideCustomSlide` should be enabled altogether.
- `ResizeAppleGpuBars` must be set to `0` or `-1`.
- When `DisableVariableWrite`, `EnableWriteUnprotector`, or `ProvideCustomSlide` is enabled, `OpenRuntime.efi` should be loaded in `UEFI->Drivers`.
### DeviceProperties
- Requirements here all follow Global Rules.
### Kernel
#### Add
- Entry[N]->Arch: Only `Any`, `i386`, or `x86_64` are accepted.
- Entry[N]->BundlePath: Filename should have `.kext` suffix.
- Entry[N]->PlistPath: Filename should have `.plist` suffix.
- Entry[N]: If `Lilu.kext` is used, `DisableLinkeditJettison` should be enabled in `Kernel->Quirks`.
- `BrcmFirmwareRepo.kext` must not be injected by OpenCore.
- For some known kexts, their `BundlePath`, `ExecutablePath`, and `PlistPath` must match against each other. Current list of rules can be found [here](https://github.com/acidanthera/OpenCorePkg/blob/master/Utilities/ocvalidate/KextInfo.c).
- Plugin kext must be placed after parent kext. For example, [plugins of Lilu](https://github.com/acidanthera/Lilu/blob/master/KnownPlugins.md) must be placed after `Lilu.kext`.
#### Delete
- Entry[N]->Arch: Only `Any`, `i386`, or `x86_64` are accepted.
- Entry[N]->Identifier: At least one dot (`.`) should exist, because any identifier looks like a domain sequence (`vendor.product`).
#### Quirks
- `CustomSMBIOSGuid` requires `PlatformInfo->UpdateSMBIOSMode` set to `Custom`.
- `SetApfsTrimTimeout` cannot be a value that is greater than `MAX_UINT32`, or less than `-1`.
#### Scheme
- KernelArch: Only `Auto`, `i386`, `i386-user32`, or `x86_64` are accepted.
- KernelCache: Only `Auto`, `Cacheless`, `Mkext`, or `Prelinked` are accepted.
### Misc
#### BlessOverride
- Entries cannot be `\EFI\Microsoft\Boot\bootmgfw.efi` or `\System\Library\CoreServices\boot.efi` since OpenCore knows these paths.
#### Boot
- HibernateMode: Only `None`, `Auto`, `RTC`, or `NVRAM` are accepted.
- PickerMode: Only `Builtin`, `External`, or `Apple` are accepted.
- `PickerAudioAssist` requires `AudioSupport` in `UEFI->Audio` to be enabled.
- LauncherOption: Only `Disabled`, `Full`, `Short`, or `System` are accepted.
- `LauncherPath` cannot be empty string.
#### Security
- AuthRestart: If enabled, `VirtualSMC.kext` should be present in `Kernel->Add`.
- DmgLoading: Only `Disabled`, `Signed`, or `Any` are accepted.
- Vault: Only `Optional`, `Basic`, or `Secure` are accepted.
- SecureBootModel: Only `Default`, `Disabled`, `j137`, `j680`, `j132`, `j174`, `j140k`, `j780`, `j213`, `j140a`, `j152f`, `j160`, `j230k`, `j214k`, `j223`, `j215`, `j185`, `j185f`, or `x86legacy` are accepted.
#### Serial
- RegisterAccessWidth: Only `8` or `32` are accepted.
- BaudRate: Only `921600`, `460800`, `230400`, `115200`, `57600`, `38400`, `19200`, `9600`, `7200`, `4800`, `3600`, `2400`, `2000`, `1800`, `1200`, `600`, `300`, `150`, `134`, `110`, `75`, or `50` are accepted.
- PciDeviceInfo: The last byte must be `0xFF`.
- PciDeviceInfo: Excluding the last byte `0xFF`, the rest must be divisible by 4.
- PciDeviceInfo: Maximum allowed size is 41.
### NVRAM
- Requirements here all follow Global Rules. In addition, the following keys and values are checked:
#### gAppleBootVariableGuid (`7C436110-AB2A-4BBB-A880-FE41995C9F82`)
- `nvda_drv` must have type `Plist Data` with the value of `0x30` or `0x31`.
- `boot-args` must be an ASCII string (thus `Plist String`) without trailing `\0`.
- `bootercfg` must be an ASCII string (thus `Plist String`) without trailing `\0`.
- `csr-active-config` must have type `Plist Data` and have length of 4 bytes.
- `StartupMute` must have type `Plist Data` and have length of 1 byte.
- `SystemAudioVolume` must have type `Plist Data` and have length of 1 byte.
#### gAppleVendorVariableGuid (`4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14`)
- `UIScale` must have type `Plist Data` with the value of `0x01` or `0x02`.
- `FirmwareFeatures` must have type `Plist Data` and have length of 4 bytes.
- `ExtendedFirmwareFeatures` must have type `Plist Data` and have length of 8 bytes.
- `FirmwareFeaturesMask` must have type `Plist Data` and have length of 4 bytes.
- `ExtendedFirmwareFeatures` must have type `Plist Data` and have length of 8 bytes.
- `DefaultBackgroundColor` must have type `Plist Data` and have length of 4 bytes. Also, its last byte must be `0x00`.
### PlatformInfo
- UpdateSMBIOSMode: Only `TryOverwrite`, `Create`, `Overwrite`, or `Custom` are accepted.
#### Generic
- SystemProductName: Only real Mac models are accepted.
- SystemMemoryStatus: Only `Auto`, `Upgradable`, or `Soldered` are accepted.
- SystemUUID: Only empty string, `OEM` or valid UUID are accepted.
- ProcessorType: Only known first byte can be set.
### UEFI
#### APFS
- When `EnableJumpstart` is enabled, `ScanPolicy` in `Misc->Security` should have `OC_SCAN_ALLOW_FS_APFS` (bit 8) set, together with `OC_SCAN_FILE_SYSTEM_LOCK` (bit 0) set. Or `ScanPolicy` should be `0` (failsafe value).
#### Audio
- When `AudioSupport` is enabled, `AudioDevice` must be either empty or a valid path.
- When `AudioSupport` is enabled, `AudioOutMask` must be non-zero.
#### Quirks
- When `RequestBootVarRouting` is enabled, `OpenRuntime.efi` should be loaded in `UEFI->Drivers`.
- `ResizeGpuBars` must be set to an integer value between `-1` and `19`.
#### Drivers
- When `OpenUsbKbDxe.efi` is in use, `KeySupport` in `UEFI->Input` should never be enabled altogether.
- When `Ps2KeyboardDxe.efi` is in use, `KeySupport` in `UEFI->Input` should always be enabled altogether.
- `OpenUsbKbDxe.efi` and `Ps2KeyboardDxe.efi` should never co-exist.
- When HFS+ filesystem driver or `AudioDxe.efi` is in use, `ConnectDrivers` should be enabled altogether.
- When `OpenCanopy.efi` is in use, `PickerMode` in `Misc->Boot` should be set to `External`.
- When `OpenVariableRuntimeDxe.efi` is in use, its `LoadEarly` option must be set to `TRUE`.
- `OpenRuntime.efi` must be placed after `OpenVariableRuntimeDxe.efi` when both are in use.
- `LoadEarly` for any other driver but `OpenVariableRuntimeDxe.efi` and `OpenRuntime.efi` must be set to `FALSE`.
#### Input
- KeySupportMode: Only `Auto`, `V1`, `V2`, or `AMI` are accepted.
- When `PointerSupport` is enabled, the value of `PointerSupportMode` should only be `ASUS`.
#### Output
- `ClearScreenOnModeSwitch`, `IgnoreTextInGraphics`, `ReplaceTabWithSpace`, and `SanitiseClearScreen` only apply to `System` TextRenderer
- `Resolution` should match `NUMBERxNUMBER` or `NUMBERxNUMBER@NUMBER` sequences (unless it is an `Empty string` or is set to `Max`).
- `UIScale` must be set to an integer value between `-1` and `2`.
#### ReservedMemory
- Type: Only `Reserved`, `LoaderCode`, `LoaderData`, `BootServiceCode`, `BootServiceData`, `RuntimeCode`, `RuntimeData`, `Available`, `Persistent`, `UnusableMemory`, `ACPIReclaimMemory`, `ACPIMemoryNVS`, `MemoryMappedIO`, `MemoryMappedIOPortSpace`, or `PalCode` are accepted.