xCuri0 / ReBarUEFI

Resizable BAR for (almost) any UEFI system
MIT License
1.32k stars 59 forks source link

Enable 4G Decoding for Tesla P40 none of the described methods worked until now #63

Closed SirNoName2705 closed 11 months ago

SirNoName2705 commented 11 months ago

System

Description Background: We want to use an old PC as a server for large language models; hence, I established an SSH connection from my working PC to the server PC. But I do have physical access to the llm-server-pc. Problem Drivers for Tesla P40 were not working, and I found out, that Above 4G decoding is needed. I have tried everything on the driver side and after 2 weeks of trying everything lead me to see that the graphics card cannot be addressed properly. I saw a lot of errors that said something like:

[ 2805.584742] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: NVRM: BAR1 is 0M @ 0x0 (PCI:0000:01:00.0) [ 2805.585711] nvidia: probe of 0000:01:00.0 failed with error -1 [ 2805.585725] NVRM: The NVIDIA probe routine failed for 1 device(s).

Finally, it has led me to this repo. Now I have been trying to get this working with UEFI modification using tutorials from this repo. I started with that about one week ago.

Goal: We really do not need ReBar, but it would be nice. What we really need is Above 4G decoding enabled so that we can use the Graphics card for ML.

Issues: PC won't boot after I applied the UEFI Patch with DSDT Patch. If I start it, there is no video output at all. Hence, I cleared the CMOS and will try other solutions. I am pretty convinced that I messed up something, as I find the tutorial perplexing. But I think it is more on my side than on your side, as I sincerely appreciate your help and all the efforts you all have put into the wiki.

I decided to document very thoroughly all the things I have tried. I will go through all the tutorials a second time and make retroactively screenshots of everything.

Here is what I have done, in chronological order:

1. linux-no-4g-decoding-fix (Wrong!)

The first thing I tried was the DSDT Only fix. But I think I messed up this part quite good. Therefore, I do not recommend following these steps. I saw a link on the DSDT-Patching site there was a Link leading to an Arch wiki page. ... override DSDT without any BIOS modification on Linux ... I started by reading the arch wiki page from the beginning, after I have read the part 2. Recompiling it yourself, I started to implement it as well. In hindsight, I now see that I should not have done that because there was a reason that the link on the DSDT-Patching site was leading me to Part 3. of the tutorial and not to the second part of the arch wiki tutorial.

Details

I decompiled the DSDT-file, changed the version number from 0x0...088 to 0x0... and compiled it. Of course, I had some errors.

How I have changed the Version number

I changed this line: ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/dfa417e5-1b9e-414e-b34f-83e61b53f1dc) to this: ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/484ef326-75ac-4138-b66f-629887394121)

```shell sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat iasl -d dsdt.dat iasl -tc dsdt.dsl iasl -ve -tc dsdt.dsl (This one is only for documentation) ``` > Intel ACPI Component Architecture > ASL+ Optimizing Compiler/Disassembler version 20200925 > Copyright (c) 2000 - 2020 Intel Corporation > > Compiler aborting due to parser-detected syntax error(s) > dsdt.dsl 6751: Zero > Error 6126 - syntax error ^ > > Input file: dsdt.dsl - Compilation aborted due to parser-detected syntax error(s) > Hex Dump: dsdt.hex - 641565 bytes > > Compilation failed. 1 Errors, 130 Warnings, 129 Remarks > No AML files were generated due to syntax error(s) That means on line 6751 is an error with the number 6126. The error number is not important, but the line is. So, on line 6751, found that the lines 6750 to the line 6869 were only "Zero" and the next line.
surrounding code at line 6751

... Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table { If (PICM) { Return (AR0F ()) } Return (PR0F ()) } } Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero Zero } Scope (\_GPE) ...

So, I fixed the error by deleting all the Zeros. I compiled it again by using `iasl -ve -tc dsdt.dsl` and I now get no errors anymore. Only 130 Warnings etc. But Warnings are not Errors; hence we can ignore them. Then I followed [the arch wiki tutorial part 3.1](https://wiki.archlinux.org/title/DSDT#Using_a_CPIO_archive) until the bootloader thing. I really did not want to compile it into my kernel, so I tried this part. At first, I did not know how to change Grub, so it loads the modified DSDT, actually I do not know if I know it now, but I wanted to change my bootloader back then. I failed, hence I researched some more. I found some tutorials which use grub-update and used that at first, but then I have done that, what some said you should not do and that was changing: /boot/grub/grub.cfg at the ### BEGIN /etc/grub.d/10_linux ### part.
My added menue entry

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-218a605f-858c-4716-a300-8d22baf1f0ca' { recordfail load_video gfxmode $linux_gfx_mode insmod gzio if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi insmod part_gpt insmod ext2 set root='hd0,gpt2' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 218a605f-858c-4716-a300-8d22baf1f0ca else search --no-floppy --fs-uuid --set=root 218a605f-858c-4716-a300-8d22baf1f0ca fi linux /boot/vmlinuz-5.19.0-45-generic root=UUID=218a605f-858c-4716-a300-8d22baf1f0ca ro quiet splash pci=realloc $vt_handoff initrd /boot/initrd.img-5.19.0-45-generic } menuentry 'efi hack' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-218a605f-858c-4716-a300-8d22baf1f0ca' { recordfail load_video gfxmode $linux_gfx_mode insmod gzio if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi insmod part_gpt insmod ext2 set root='hd0,gpt2' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 218a605f-858c-4716-a300-8d22baf1f0ca else search --no-floppy --fs-uuid --set=root 218a605f-858c-4716-a300-8d22baf1f0ca fi linux /boot/vmlinuz-5.19.0-45-generic root=UUID=218a605f-858c-4716-a300-8d22baf1f0ca ro pci=realloc mitigations=off initrd /boot/initrd.img-5.19.0-45-generic echo 'Loading EFI hack' initrd /boot/acpi_override }

This entry would not boot unfortunately, I do not know exactly why, it said something about vfs could not be loaded, but I have no clue why the virtual file system would not want to load. I have no good screenshots from that, If one wants to see them I could try to recreate them. In hindsight, however, I wonder if removing booth quiet and splash kernel parameters was the problem. I thought that removing them would prevent the system from loading the UI, but that was completely wrong, as it has nothing to do with the UI.

2. Enable hidden 4G decoding tutorial: https://github.com/xCuri0/ReBarUEFI/wiki/Enabling-hidden-4G-decoding

Sadly, I think now, there is no hidden Option. But I hope this documentation helps anybody.

Tools I have used

I have used booth ifrextractors, the one for Linux and the older one for windows, using wine. - [the old version 0.3.6_win](https://github.com/LongSoft/Universal-IFR-Extractor/releases) - [the newer version which natively supports Linux](https://github.com/LongSoft/IFRExtractor-RS/releases/tag/v1.5.1) Sadly, to no avail. I also used booth UEFI tool versions - [the old version](https://github.com/LongSoft/UEFITool/releases/tag/0.28.0) - [new version](https://github.com/LongSoft/UEFITool/releases/tag/A66) I now know that the reason we cannot use the newer NE one all the time is that it does not support adding modules. But at that time I did not know that I thought I give it a shot.

What I have done

All my screenshots are for the newest UEFITool version, which is the NE Alpha 67 at the time I took them. The first step is to open the UEFI Tool. That did not work for me directly at the beginning, as there was some qt package missing. If you encounter the same issue, just install those packages: `sudo apt install qt6-base-dev libqt6svg6-dev qt6-base-private-dev` After that was done, I opened the newest version of my bios. That was for me, the `Z97PD3.F9b`. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/d42ce850-a8bc-4424-8881-faad0b9847d4) I then hit `Ctrl + f` , clicked on text and entered `4G Decod` ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/c27e7126-df88-44e5-9998-088873de576e) Then I saw the search tab, where something new was present. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/f65b7084-2339-41ef-bb4b-ba163be1ee6e) I double-clicked on that and I saw this ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/fd3b218c-d648-43da-8642-98aa5dc461a8) I right-click the entry and then clicked on extract body. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/ef10172a-62e9-42d6-b3d9-5771851de437) I then saved it and put it in a folder where I know to find it. The newly created file has the name `Section_Freeform_subtype_GUID_MiniSetupResourceSection_Setup_Setup_body.bin` in my case. Thereafter, I opened a terminal in the folder where both the ifrextractor and the newly created file is. Then I typed the following command in the terminal: `./ifrextractor ./Section_Freeform_subtype_GUID_MiniSetupResourceSection_Setup_Setup_body.bin` This returned 8 files for me. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/6045f576-62ad-402d-83a8-9df4d4307c7e) Now I open every one of them and search for `4G Decod`. It says in every one of them that nothing was found. Then I do that again, this time searching for `Above 4G` in the generated files. This time I found something. `OneOf Prompt: "Memory Remap", Help: "Enable or disable memory remap above 4G.", QuestionFlags: 0x10, QuestionId: 0x289, VarStoreId: 0x1, VarOffset: 0x2F2, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x0, Step: 0x0`. But it says Memory Remap, so I looked for `Memory Remap` in the whole Repo and found out that [Memory Remap](https://github.com/xCuri0/ReBarUEFI/wiki/Common-issues-(and-fixes)#is-memory-remap-in-the-same-as-4g-decoding-) and Above 4G Decoding is not the same. Then I retried the same approach in the UEFI tool, but this time I searched for `Above 4G`. It found the same entry as before: ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/0fe55c53-92ee-4347-9a2a-8efe008648e5) Then I thought, well, I might as well search for MMIO. I found two new Entries: ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/866a52d1-d5dd-4961-9163-b5a9de06dd27) Then I redo the whole process with ifrextracter etc. `./ifrextractor ./Section_UI_AhciMmioSmm_AhciMmioSmm_body.bin` Found no IFR Entries. And `./ifrextractor ./Section_Freeform_subtype_GUID_MiniSetupResourceSection_Setup_Setup_body.bin` Found again eight different files. In none of these were anything found for `4G Decod`. For `Above 4G` I found only the same entry again: `OneOf Prompt: "Memory Remap", Help: "Enable or disable memory remap above 4G.", QuestionFlags: 0x10, QuestionId: 0x289, VarStoreId: 0x1, VarOffset: 0x2F2, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x0, Step: 0x0` ### The next Part is something I previously did not do. I searched for `MMIO` in the generated files: I found one very interesting entry: `OneOf Prompt: "Max TOLUD", Help: "Maximum Value of TOLUD. Dynamic assignment would adjust TOLUD automatically based on largest MMIO length of installed graphic controller", QuestionFlags: 0x10, QuestionId: 0x283, VarStoreId: 0x1, VarOffset: 0x2F5, Flags: 0x10, Size: 8, Min: 0x0, Max: 0x0, Step: 0x0 OneOfOption Option: "Dynamic" Value: 0, Default, MfgDefault OneOfOption Option: "1 GB" Value: 3 OneOfOption Option: "1.25 GB" Value: 4 OneOfOption Option: "1.5 GB" Value: 5 OneOfOption Option: "1.75 GB" Value: 6 OneOfOption Option: "2 GB" Value: 7 OneOfOption Option: "2.25 GB" Value: 8 OneOfOption Option: "2.5 GB" Value: 9 OneOfOption Option: "2.75 GB" Value: 10 OneOfOption Option: "3 GB" Value: 11 OneOfOption Option: "3.25 GB" Value: 12 End ` That's sounds exactly what I was searching for. But TOLUD is not the same I redo the same thing for the previously generated files. > And only now I realize it was the same entry all along.

3. Applying Uefi Patch and Editing DSDT Patch.

This is the last thing I have tried, and after this one has failed, I thought I may as well write an Issue before I continue ^^.

Tools I have used

I have used booth ifrextractors, the one for Linux and the older one for windows, using wine. - [UEFIPatch_0.28.0 for Linux](https://github.com/LongSoft/UEFITool/releases/tag/0.28.0) - [The old version of UEFI tool](https://github.com/LongSoft/UEFITool/releases/tag/0.28.0) - [AmiBoardInfoTool](https://github.com/xCuri0/AmiBoardInfoTool/releases/tag/0.1) As I use Linux, I need to compile AmiBoardInfoTool with Cmake. While trying the second time to I have not done that before, so I may as well explain how I did that, for other users.

How to compile AmiBoardInfoTool on Ubuntu 22.04

@xCuri0 if you want, you could add this to the README AmiBoardInfoTool 1. Download the src as zip of the [AmiBoardInfoTool](https://github.com/xCuri0/AmiBoardInfoTool/releases) 2. Extract the content 3. Go into the AmiBoardInfoTool-0.1 folder 4. Open a terminal in that folder 5. Use the following commands: 6. `sudo apt install libdistorm3-dev build-essential tar curl zip unzip -y` 7. `git clone https://github.com/microsoft/vcpkg` 8. `./vcpkg/bootstrap-vcpkg.sh` 9. `./vcpkg/vcpkg install distorm` 10. `cmake -B ./ -S . "-DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake"` 11. `make AmiBoardInfoTool`

What I have done

### Patching the UEFI I downloaded the [patches.txt](https://github.com/xCuri0/ReBarUEFI/blob/master/UEFIPatch/patches.txt) and put it in the same folder as the UEFIPatch tool. Then I also put the latest BIOS version into the folder and opened a terminal in the same directory. I typed in the following command, without modifying the patches.txt: `./UEFIPatch Z97PD3.F9b patches.txt`

This returned the following text

patch: replaced 146 bytes at offset B98h 080000004823C1483BC3770C48BE0000000004000000EB7A48BB000000000C000000483BC3770C48BE0000000002000000EB5F48BB000000000E000000483BC3770C48BE0000000001000000EB4448BB000000000F000000483BC37707BE00000080EB2E48BB000000800F000000483BC37707BE00000040EB1848BB000000C00F000000483BC30F87A4FEFFFFBE00000020 -> 010000004821C84839D8480F47D848BE00000000100000004829DE9090909090909066909066906690909090909090909066906690909090909090909066909066906690909090909090909066906690909090909090909066909066909090909090669066909090909090909090669090669090909090906690669090909090909090906690909090909090909090909090 patch: replaced 11 bytes at offset 81D6h B8FFFFFFFF030000004C3B -> B8FFFFFFFFFFFFFF004C3B patch: replaced 8 bytes at offset 1683h FF000000760B48B8 -> 00100000760B48B8 patch: replaced 17 bytes at offset 8542h B9FFFFFFFF490FAFC14903C0483BC1776C -> 6690669090490FAFC14903C06690906690 patch: replaced 17 bytes at offset 861Eh B9FFFFFFFF490FAFC14903C0483BC1776C -> 6690669090490FAFC14903C06690906690 patch: replaced 7 bytes at offset 193Eh 493B4C24C0771B -> 66906690669090 patch: replaced 7 bytes at offset 19E5h 493B4C24C0771C -> 66906690669090 Image patched

Then I had the `Z97PD3.F9b.patched`. ### DSDT Extraction The Extraction part was quite hard to figure out.
Details

I opened the new Uefi tool and opened the Patched bios file. I typed in `AmiBoardInfo` and found the following: ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/c6e4a6b7-9357-460c-be69-ed5ba4a34cc2) But I could not Extract it as EFI. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/c2bee8f6-4150-4e7b-bb88-04ba7d84d723) Then I thought maybe I should only search for `Ami` I found quite a lot of Entries, therefore I extracted all which can be extracted as efi.

Entries

> I removed all entries which are not unique Unicode text "AmiBoardInfo" found in AmiBoardInfo/.../UI section at header-offset 04h Unicode text "Ami" found in FileSystem/.../PE32 image section at header-offset 6DDCh Unicode text "Ami" found in CORE_DXE/.../PE32 image section at header-offset 5B344h Unicode text "Ami" found in FlashDriver/.../PE32 image section at header-offset E1C4h Unicode text "Ami" found in PciBus/.../PE32 image section at header-offset BD44h Unicode text "Ami" found in AmiBoardInfo/.../UI section at header-offset 04h Unicode text "Ami" found in AmiTxtDxe/.../UI section at header-offset 04h Unicode text "Ami" found in SbRun/.../PE32 image section at header-offset 1994h Unicode text "Ami" found in NbDxe/.../PE32 image section at header-offset 7BB4h Unicode text "Ami" found in Nvme/.../PE32 image section at header-offset 398Ch Unicode text "Ami" found in Ahci/.../PE32 image section at header-offset 67B4h Unicode text "Ami" found in A684C332-5DDA-492E-8DDD-9F373E3DBC05/.../PE32 image section at header-offset 2BC4h Unicode text "Ami" found in AMITSE/.../PE32 image section at header-offset 50F12h Unicode text "Ami" found in AMITSE/.../MiniSetupResourceSection at header-offset 1544h Unicode text "Ami" found in AMITSE/.../setupdata at header-offset 1BB30h Unicode text "Ami" found in AMITSE/.../UI section at header-offset 04h Unicode text "Ami" found in FBE835E8-513E-4176-8749-27C59990A669/.../Raw section at header-offset 4C1Eh Unicode text "Ami" found in SmbiosBoard/.../PE32 image section at header-offset E6Ch Unicode text "Ami" found in Uhcd/.../PE32 image section at header-offset B96Ch Unicode text "Ami" found in Uhcd/.../PE32 image section at header-offset BA4Ch Unicode text "Ami" found in UsbInt13/.../PE32 image section at header-offset 118Ch Unicode text "Ami" found in Setup/.../PE32 image section at header-offset 197FCh Unicode text "Ami" found in Setup/.../MiniSetupResourceSection at header-offset 5F7Dh Unicode text "Ami" found in CORE_PEI/PE32 image section at header-offset 1D10Ch Unicode text "Ami" found in AmiTxtPei/UI section at header-offset 04h Unicode text "Ami" found in AmiCpuS3Pei/UI section at header-offset 04h Unicode text "Ami" found in SbPei/PE32 image section at header-offset 57C0h Unicode text "Ami" found in Capsule/.../PE32 image section at header-offset C04h

I put all the extracted files into a folder and wrote a shell script which tries to use the AmiBoardInfoTool on any of these files.
Shell Script

```bash #!/bin/zsh cd ./efis for file in ./*.efi do ../AmiBoardInfoTool -a "./$file" -d DSDT.aml done ```

But to no avail, none of these were the correct file. I tried some other things, like making a shell script that extracts all .efi files from the given bios, but I failed because I did not know how to use the UEFI tool from the shell. Sadly these files were lost. I do not the other things I have tried, but I have put a lot of time into that. Then I thought, well, look again at the tutorial. And I saw this image: ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/239bf8d4-e441-4a89-b058-45e1ae17fcd1) I figured well maybe I only need these PE32 image sections. I opened UEFITool again and searched once more for `AmiBoardInfo`. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/474fc8f0-1f0a-46f8-8ea9-42d937925095) Above the UI section was this PE32 image, and that was the correct one. I extracted the body and put the `Section_PE32_image_AmiBoardInfo_AmiBoardInfo_body.efi` file into the same folder as the `AmiBoardInfoTool`. I entered `./AmiBoardInfoTool -a Section_PE32_image_AmiBoardInfo_AmiBoardInfo_body.efi -d DSDT.aml` into a terminal which was opened in the same folder. Then I finally had my DSDT.aml file.

### DSDT Modding Haswell I renamed the file to DSDTMod.aml I decompiled that file. `iasl DSDTMod.aml` And to check something, I recompiled it again. I got different errors than on my first try with the Linux Haswell fix.
iasl Errors

Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20200925 Copyright (c) 2000 - 2020 Intel Corporation Compiler aborting due to parser-detected syntax error(s) DSDTMod.dsl 13906: } Error 6126 - ^ syntax error DSDTMod.dsl 18072: Error 6126 - syntax error and premature End-Of-File Input file: DSDTMod.dsl - Compilation aborted due to parser-detected syntax error(s) Compilation failed. 2 Errors, 0 Warnings, 0 Remarks No AML files were generated due to syntax error(s)

> Does anyone of you know why that is? > While I write this I realized also that I have decompiled it on my client PC not on the Server. Maybe that is also an error. > I think, I have compiled it on the server all the time. But that could also be an mistake. I searched the DSDTMod.dsl for `DWordMemory`. I found a lot of those entries and scrolled down. I saw the following code: ```asl ... DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0xFEAFFFFF, // Range Maximum 0x00000000, // Translation Offset 0xFEB00000, // Length ,, _Y1C, AddressRangeMemory, TypeStatic) QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x0000000000000000, // Granularity 0x0000000000010000, // Range Minimum 0x000000000001FFFF, // Range Maximum 0x0000000000000000, // Translation Offset 0x0000000000010000, // Length ,, _Y1E, AddressRangeMemory, TypeStatic) }) ... ``` This confused me quite good because I thought I had to add something similar to the file at exactly the same place. But I realized there were more `DWordMemory` entries in the file, so in searched the file for more entries.# But then at the real end, I pasted the code from the tutorial into it.
Before

```asl ... DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000F0000, // Range Minimum 0x000FFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00010000, // Length ,, _Y1B, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0xFEAFFFFF, // Range Maximum 0x00000000, // Translation Offset 0xFEB00000, // Length ,, _Y1D, AddressRangeMemory, TypeStatic) }) Name (EP_B, Zero) Name (MH_B, Zero) Name (PC_B, Zero) Name (PC_L, Zero) Name (DM_B, Zero) Method (GEPB, 0, Serialized) ... ```

After adding the code

```asl ... DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000F0000, // Range Minimum 0x000FFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00010000, // Length ,, _Y1B, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0xFEAFFFFF, // Range Maximum 0x00000000, // Translation Offset 0xFEB00000, // Length ,, _Y1D, AddressRangeMemory, TypeStatic) QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x0000000000000000, // Granularity 0x0000000000010000, // Range Minimum 0x000000000001FFFF, // Range Maximum 0x0000000000000000, // Translation Offset 0x0000000000010000, // Length ,, _YAF, AddressRangeMemory, TypeStatic) }) Name (EP_B, Zero) Name (MH_B, Zero) Name (PC_B, Zero) Name (PC_L, Zero) Name (DM_B, Zero) Method (GEPB, 0, Serialized) ... ```

The next step is to search for `M1LN` which I have done.
This is what I have found

```asl ... Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { ... If ((PM0H == One)) { If ((Local1 >= 0x07D9)) { CreateBitField (BUF0, \_SB.PCI0._Y1A._RW, F0RW) // _RW_: Read-Write Status F0RW = Zero } Else { CreateBitField (BUF1, \_SB.PCI0._Y1B._RW, F0R2) // _RW_: Read-Write Status F0R2 = Zero } } If ((Local1 >= 0x07D9)) { CreateDWordField (BUF0, \_SB.PCI0._Y1C._MIN, M1MN) // _MIN: Minimum Base Address CreateDWordField (BUF0, \_SB.PCI0._Y1C._MAX, M1MX) // _MAX: Maximum Base Address CreateDWordField (BUF0, \_SB.PCI0._Y1C._LEN, M1LN) // _LEN: Length M1MN = (TLUD << 0x14) M1LN = ((M1MX - M1MN) + One) } Else { CreateDWordField (BUF1, \_SB.PCI0._Y1D._MIN, M1N2) // _MIN: Minimum Base Address CreateDWordField (BUF1, \_SB.PCI0._Y1D._MAX, M1X2) // _MAX: Maximum Base Address CreateDWordField (BUF1, \_SB.PCI0._Y1D._LEN, M1L2) // _LEN: Length M1N2 = (TLUD << 0x14) M1L2 = ((M1X2 - M1N2) + One) } If ((Local1 >= 0x07D9)) { If ((M64L == Zero)) { CreateDWordField (BUF0, \_SB.PCI0._Y1E._LEN, MSLN) // _LEN: Length MSLN = Zero } Else { CreateQWordField (BUF0, \_SB.PCI0._Y1E._LEN, M2LN) // _LEN: Length CreateQWordField (BUF0, \_SB.PCI0._Y1E._MIN, M2MN) // _MIN: Minimum Base Address CreateQWordField (BUF0, \_SB.PCI0._Y1E._MAX, M2MX) // _MAX: Maximum Base Address M2LN = M64L /* External reference */ M2MN = M64B /* External reference */ M2MX = ((M2MN + M2LN) - One) } } If ((Local1 >= 0x07D9)) { Return (BUF0) /* \_SB_.PCI0.BUF0 */ } Else { Return (BUF1) /* \_SB_.PCI0.BUF1 */ } } ... ```

I do not know where to add the code from the tutorial. I think many places would be possible. But the compiler thought otherwise. Therefore, I replaced the section which looked similar, with the code from the tutorial.
Code after change

```asl If ((PM0H == One)) { If ((Local1 >= 0x07D9)) { CreateBitField (BUF0, \_SB.PCI0._Y1A._RW, F0RW) // _RW_: Read-Write Status F0RW = Zero } Else { CreateBitField (BUF1, \_SB.PCI0._Y1B._RW, F0R2) // _RW_: Read-Write Status F0R2 = Zero } } If ((Local1 >= 0x07D9)) { CreateDWordField (BUF0, \_SB.PCI0._Y1C._MIN, M1MN) // _MIN: Minimum Base Address CreateDWordField (BUF0, \_SB.PCI0._Y1C._MAX, M1MX) // _MAX: Maximum Base Address CreateDWordField (BUF0, \_SB.PCI0._Y1C._LEN, M1LN) // _LEN: Length M1MN = (TLUD << 0x14) M1LN = ((M1MX - M1MN) + One) } Else { CreateDWordField (BUF1, \_SB.PCI0._Y1D._MIN, M1N2) // _MIN: Minimum Base Address CreateDWordField (BUF1, \_SB.PCI0._Y1D._MAX, M1X2) // _MAX: Maximum Base Address CreateDWordField (BUF1, \_SB.PCI0._Y1D._LEN, M1L2) // _LEN: Length M1N2 = (TLUD << 0x14) M1L2 = ((M1X2 - M1N2) + One) } If ((Local1 >= 0x07D9)) { If ((M64L == Zero)) { CreateDWordField (BUF0, \_SB.PCI0._Y1E._LEN, MSLN) // _LEN: Length MSLN = Zero } Else { // DSDT Mod ----------------------------------------------------------------------------------------------------- CreateQWordField (BUF0, \_SB.PCI0._YAF._LEN, M2LN) // _LEN: Length CreateQWordField (BUF0, \_SB.PCI0._YAF._MIN, M2MN) // _MIN: Minimum Base Address CreateQWordField (BUF0, \_SB.PCI0._YAF._MAX, M2MX) // _MAX: Maximum Base Address // 39-bit for Haswell and up M2MX = 0x8000000000 - One If ((TUUD >= 0x1000)) { M2MN = (TUUD << 0x14) } Else { M2MN = 0x100000000 } M2LN = ((M2MX - M2MN) + One) //DSDT Mod end -------------------------------------------------------------------------------------------------- /* code which was replaced CreateQWordField (BUF0, \_SB.PCI0._Y1E._LEN, M2LN) // _LEN: Length CreateQWordField (BUF0, \_SB.PCI0._Y1E._MIN, M2MN) // _MIN: Minimum Base Address CreateQWordField (BUF0, \_SB.PCI0._Y1E._MAX, M2MX) // _MAX: Maximum Base Address M2LN = M64L // External reference M2MN = M64B // External reference M2MX = ((M2MN + M2LN) - One) */ } } ```

I think this replacement of the code, could be a mistake, but I do not know. Subsequently, I compiled the DSDT. Then I needed to fix this error: ``` Compiler aborting due to parser-detected syntax error(s) DSDTMod.dsl 13923: } Error 6126 - ^ syntax error ```
Reason for the error

```asl Method (ADBG, 1, Serialized) { If (CondRefOf (MDBG)) { Return (MDBG) /* External reference */ Arg0 <-------- the line from the rror } Return (Zero) } ```

I just deleted the Arg0. I do not know if that was wrong. I mean, I know programming in C, Java and python a bit. But I do not know the semantics of this code. At first, I thought that MDBG was a function and Arg0 should be its parameter, but that was not the case. The compiler said that MDBG is an Integer. If the deletion of Arg0 was wrong, please tell me where this parameter belongs to. Thereafter, I was done with the DSDT mod. ### Adding the DSDTMod to the patched bios I executed `./AmiBoardInfoTool -a AmiBoardInfo.efi -d DSDTMod.aml -o AmiBoardInfoMod.efi`
Terminal Return

* Patching header... SizeOfInitialzedData: 10FE0 --> 11340 SizeOfImage: 118C0 --> 11C20 * Patching directory entries... - DataDirectory 05: VirtualAddress: 118A0 --> 11C00 * Patching sections... - Section: .text Nothing to do here... - Section: .rdata Nothing to do here... - Section: .data PhysicalAddress: 10ECE --> 1122E SizeOfRawData: 10EE0 --> 11240 - Section: .empty VirtualAddress: 11880 --> 11BE0 PointerToRawData: 11880 --> 11BE0 - Section: .reloc VirtualAddress: 118A0 --> 11C00 PointerToRawData: 118A0 --> 11C00 * Patching actual relocations... - Relocation Table 0: Nothing to do here - VirtualAddress < DSDTOffset (0 < A30) - Relocation Table 1: - VirtualAddress: 11000 --> 11000 - Relocation: 0 Offset: 738 --> A98 - Relocation: 1 Offset: 7B0 --> B10 - Relocation: 2 Offset: 7B8 --> B18 * Patching addresses in code offset: 0000006C: MOV RAX, [RIP+0x11500] [11500] --> [11860] offset: 000000A1: LEA R9, [RIP+0x114b3] [114b3] --> [11813] offset: 000000A8: LEA R8, [RIP+0x114a4] [114a4] --> [11804] offset: 000000AF: LEA RDX, [RIP+0x10ef5] [10ef5] --> [11255] offset: 000000CC: MOV RDX, [RIP+0x11488] [11488] --> [117e8] offset: 000000D3: MOV RCX, [RIP+0x11479] [11479] --> [117d9] offset: 000000F8: MOV RDX, [RIP+0x1145c] [1145c] --> [117bc] offset: 0000011D: MOV RCX, [RIP+0x1142f] [1142f] --> [1178f] offset: 00000193: MOV RCX, [RIP+0x113b9] [113b9] --> [11719] offset: 000001A7: MOV RDX, [RIP+0x113ad] [113ad] --> [1170d] offset: 0000021C: MOV RCX, [RIP+0x11330] [11330] --> [11690] offset: 0000022A: MOV RDX, [RIP+0x1132a] [1132a] --> [1168a] offset: 0000026B: LEA RCX, [RIP+0x112f1] [112f1] --> [11651] offset: 00000279: MOV RAX, [RIP+0x112f3] [112f3] --> [11653] offset: 00000297: CMP QWORD [RIP+0x112cc], 0x0 [112cc] --> [1162c] offset: 000002A1: MOV [RIP+0x112c3], RDX [112c3] --> [11623] offset: 000002AC: MOV [RIP+0x112c0], RAX [112c0] --> [11620] offset: 000002B7: MOV [RIP+0x112c5], RCX [112c5] --> [11625] offset: 000002BE: MOV [RIP+0x112b6], RAX [112b6] --> [11616] offset: 000002EB: MOV RAX, [RIP+0x11281] [11281] --> [115e1] offset: 000002F5: LEA RDX, [RIP+0x11247] [11247] --> [115a7] offset: 00000320: MOV RAX, [RIP+0x1124c] [1124c] --> [115ac] offset: 00000330: LEA RDX, [RIP+0x10c84] [10c84] --> [10fe4] offset: 000003B2: MOV RAX, [RIP+0x111ba] [111ba] --> [1151a] Patched 24 instructions

After Opening UEFITool non NE 28, I searched for AmiBoardInfo. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/35229617-5064-4591-a5f8-97e6dd14e8a8) I clicked on the PE32 Image again in, then on replace with. Selected "AmiBoardInfoMod.efi" and continued. ![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/626952f6-3cfd-4df3-a48a-cab5d1d46412) I then opened the new bios Image. And opened another instance of the UEFITool. In the new Instance I opened the latest version of the BIOS, which was not patched. Then I searched in both for `pad-file`, `padfile`, `pad_file` and `PEbiosinteface` but found nothing. Therefore, I did nothing and continued. ### Flashing the BIOS I put the modified file on the USB stick and entered the BIOS. My Gigabyte board has dual bios and this QFlash utility. So I checked if CMS was disabled, as sometimes it activates itself again. (Hmm. maybe it activates itself while flashing?) I used that to flash my bios. It reboots after that as normal. But then there was nothing. Like, not even any video output. I then waited for about 15 minutes and forced the power off. The next boot was as the last, and I could not enter the BIOS anymore. I then cleared the CMOS by removing the battery, and hence the bios is now on the latest working version, which is the 9b as before. I have appended a zip file containing images of my BIOS config. I cannot embed them and do not know why. [BiosConfig.zip](https://github.com/xCuri0/ReBarUEFI/files/11858097/BiosConfig.zip)

Miscellaneous

I know it is a long description, but I hope that it helps someone. I also hope that it is not too bad to read. I tried my absolute best to organize it and use the supported functions to bring structure into my description. (mostly details) If anyone has any plan how to fix that, I would much appreciate your help. Thanks to all of you who helped to build this repo and its wiki.

Here is what I plan to do:

If anyone of you has an educated guess as to what to try next, please let me know.

  1. [X] write an Issue in case I miss something obvious to other people
  2. [ ] See if any of the previous versions of the bios has hidden 4G decoding
  3. [ ] Brutforce the placement of the code of the DSDT patch (I mean trying all sensible placement of the Tutorial code)
  4. [ ] Use the Linux only version of the created DSDT using half of your Tutorial and half of the Arch Linux wiki tutorial
  5. [ ] Using the uefi flash mod from win raid even I thought I did not get the error described there.
  6. [ ] Use the older mb Z87-G41 PC Mate from msi, which I have lying around.
  7. [ ] Trying to change this TOLUD thing.
  8. [ ] Using the older version of UEFIExtract and Retry 3.
  9. [ ] Try to flash the Patched UEFI without the DSDT Haswell Fix
  10. [ ] Try to compile the DSDT again to see if I accidentally compiled it on the client PC
xCuri0 commented 11 months ago

@SirNoName2705 DSDT Modification will fix it but only for Linux, you don't need to flash BIOS just follow the Arch wiki guide for overriding it. Like the wiki says you must use runtime extracted DSDT as base not one extracted from BIOS.

Your BIOS probably getting corrupt from pad file problem which needs MMTool to fix (Windows only).

The Z87 likely won't work, TOLUD also won't help because it only fixes 2GB BAR

SirNoName2705 commented 11 months ago

So, then it was right that I extracted the DSDT like it was described on the Arch wiki page? Then I would redo that again, apply the fix from your Tutorial and modify grub again. I write back when I have done that. I would replace the marked part with the Tutorial code: image

Thank you very much for your help @xCuri0 :)

SirNoName2705 commented 11 months ago

Okay I did the following. I changed the dsdt file like it was described in my last post. Then I checked the kernel Config

Kernel Config

![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/f3a1c080-ef19-4b6f-bdbf-78885aecc594)

which looked fine. So I Followed this part:

image

Except for not having a ssdt1.aml, as this was not described by the tutorial. I could get this if needed via apcidump.

When I have made the archive and loaded it in my grub config. I named the archive acpi_override and placed the following line into the grub menu entry: initrd /boot/acpi_override2

Details

![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/0b822bea-ad74-430c-8b15-a95d13177225)

this would boot into my OS. Sadly, with dmesg | grep ACPI revealed not the same output as described in the arch wiki. And also under DSDT it showed the old version of the dsdt, as it was 0x...880 and my dsdt file had the version 0x.....890. So the arch wiki way does not work to load my dsdt file. But maybe I am missing something here.

Then I googled and found out there is another way of loading a custom dsdt. So I removed the previous line. Then I copied my compiled dsdt.aml file into the /boot folder and renamed it to modded_dsdt.aml. Then I added the following to my grub menu entry: acpi /boot/modded_dsdt.aml

The Whole Grub menu entry

![image](https://github.com/xCuri0/ReBarUEFI/assets/66351995/3c8811eb-d89b-4fce-a92e-384a82f49a7f)

But this won't work. Every time I start it, it will reboot to the Grub menu.

Do you have any Idea of what I could have done wrong? Maybe I did wrong by replacing the existing code of my dsdt with the code from your tutorial, but then again, I do not know where to put it then.

xCuri0 commented 11 months ago

@SirNoName2705 I don't have Linux installed anymore but I used the initrd method successfully with it

SirNoName2705 commented 11 months ago

Okay, which OS did you used?

Could you maybe tell me If my replacement of the original code in the dsdt was right?

xCuri0 commented 11 months ago

Ubuntu

On Sun, Jun 25, 2023, 6:48 PM SirNoName2705 @.***> wrote:

Okay, which OS did you used?

Could you maybe tell me If my replacement of the original code in the dsdt was right?

— Reply to this email directly, view it on GitHub https://github.com/xCuri0/ReBarUEFI/issues/63#issuecomment-1606090650, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBJLVK6FSCL3VSLSEWILK3XNA3D5ANCNFSM6AAAAAAZSWVHSQ . You are receiving this because you were mentioned.Message ID: @.***>

SirNoName2705 commented 11 months ago

I think I got it now. But to my dismay, the card died.

Nhayes05 commented 3 months ago

I reckon I have this same problem. hp z230 sff, I7 4790, lga 1150, win 10, c226, newest BIOS version. I did check the oldest BIOS I could find as well, no dice. This seems to be my only real option, but I don't know if a ton of time for only 1gb decoding would be worth it in the slightest. My card is an asrock a380lp with 6gb.