Hi all and merry Christmas to all! I have a question and maybe, if it’s possible, a bios mod request. I have a Asus Z9PE-D8 WS mainboard, with linux installed on it (I tried different distributions, ubuntu, artix, arch, manjaro): from about 7 months I was trying to fix or find a workaround for an issue that was really struggling me (that was showing in all distributions, even with the usb bootable installer): sometimes (about 30-50% of the times) the os hangs in S5 and the workstation doesn’t complete the shutdown. I opened different bugs at bugtrackers, for example (I’m not allowed to write links): at the kernel bugtracker: show_bug.cgi?id=210689
and at the ubuntu/launchpad bugtracker: ubuntu/+source/linux/+bug/1909115
Finally I extracted the DSDT, fixed the error and modified the _PTS method logic, to include a “do nothing” if Arg0=0x05 (S5 state): after applying this modification I noticed that this was advice in the “hackintosh” world, as a workaround/fix for shutdown hang for asus mainboards.
Method (_PTS, 1, NotSerialized) { If (LEqual (Arg0, 0x05)) {} Else { Store (Arg0, DBG8) If (LAnd (LEqual (Arg0, 0x04), LEqual (OSFL (), 0x02))) { Sleep (0x0BB8) }
PTS (Arg0) Store (Zero, Index (WAKP, Zero)) Store (Zero, Index (WAKP, One)) Store (ASSB, WSSB) Store (AOTB, WOTB) Store (AAXB, WAXB) Store (Arg0, ASSB) Store (OSFL (), AOTB) Store (Zero, AAXB) Store (One, \_SB.SLPS) } }
After applying the dsdt override the system is able to complete the shutdowns in 100% of the cases. I hope this can be fixed kernel side, but I was thinking if it could be possible to modify the bios with this patch in the acpi tables and flash it.
I'm attaching my original dsdt.dsl (no errors fixed) and the fixed dsdt.dsl (errors fixed+shutdown patch)--->rename extensions from .txt to .dsl
Ok, I read something about this, I think I’m quite closed to the solution, but still need help. What I did (I mainly followed @CodeRush advices):
1- downloaded original bios from asus: Z9PE-D8 WS, v.5802 2- Downloaded UEFITool, v. 0.28 (not alpha/NE version, so I can replace/rebuild) 3- I have my patched DSDT.aml: this was compiled on mac os with maciasl 1.5.9: it uses iasl v. 20200925 4- I tested my patched DSDT by injecting at boot time: it works 5- I run UEFITool, highlighted the PE32+ submenu into the AmiBoardInfo and extracted the body as .bin 6- Opened the extracted .bin and the patched DSDT.aml in a hex editor 7- Replaced in the hex editor the DSDT part inside the .bin with that of the patched DSDT.aml (and filled at the end of the DSDT part with FF FF…till reaching the same size of the original) 8- In UEFITool, with the original asus bios opened (.cap), replaced body of PE32+ with the patched one (checked again that remove and replace had the same size) 9- Saved the patched bios image (.cap)
Part 2 - Flashing I used Afuwin to flash the chip (I downloaded v.3.05.04 with /GAN)
1- Flashed the original asus bios: afuwinx64.exe <NAME OF THE ORIGINAL BIOS>.CAP 2- Opened the .cap file of the patched bios in UEFITool 3- Right click on AMI Aptio capsule, then extract body, and save as .ROM (size was -2kb compared to original .cap, but this was expected) 4- Flashed the modded .rom: afuwinx64.exe <NAME OF THE MODDED BIOS>.ROM /GAN
No errors, but on reboot, only a black screen (…and q-code 06) Luckily I have a spare chip and with a hot swap I was able to flash again the original bios.
Did I miss anything?Checksum? Could it depend on the iasl version?Can I use a newer iasl (acpi specification 6.3, for example) to fix errors on a 2.0a acpi motherboard?
If anybody can explain me what’s wrong with the modded image I would be greatful. Here the original cap file: Edited: see post #6
Here the modded rom (image packed as described in post #2, with the exception that I made the DSDT patch the same size as the original and I used iasl 20051117 to compile the DSDT (should be the same version used to compile the original DSDT))<–archive contains: MOD rom, DSDT-patch2.aml replaced in AmiBoardInfo PE32 image and DSDT-patch2.dsl (source code): Edited: see post #6
The only thing I noticed is that the compressed section into AmiBoardInfo is different if compared to the original bios.
@ghost82 - Don’t use UEFITool 28.0 for this, use 25.0, I assume padding is being added or removed on rebuild Don’t use AFU, use flash programmer if you have, otherwise you will never know if using OLD AFU /GAN is part of the issue here
I can’t comment or help any with the actual edit your doing, all my reply is simply based on rebuilding mod BIOS / flashing etc. I see this model does not have flashback So if you do not have programmer, and nothing helps, you need to get programmer before you are sure which is failing - your edit, or the AFU /GAN flashing.
Please upload that file to another upload host so I can check your edit, I can’t download that because it’s blocked as a virus by Eset (it may be the package too, not just the site, not sure) If I can’t download from other source, then upload for me ONLY the mod BIOS in a zip Upload to one of these, thanks tinyupload.com https://ufile.io/
Thank you very much @Lost_N_BIOS ! Ok for UEFITool 25, I will try and see if there are any difference. <— Just tried, rom files are identical (0.28 - 0.25 versions) Yes, I was thinking about AFU not being the right tool to flash, I will buy the programmer in any case, I was just thinking for somebody to check the rom file to see if there are some macro errors, sorry but I’m really a novice Sorry for the links, I can ensure the files are 100% safe, I will edit my post above soon, here new links (PS I think it’s workupload site being flagged as malicious by Eset): Modded rom: https://ufile.io/3ujq95h8
You’re welcome! Make sure you use 25.0, not 25.1 or other. I do not need original rom, I have the stock BIOS already. Hot swap is OK, do while in windows or while inside EZ Flash in BIOS.
You need CH341A + U Type Flat IC extractor, if you don’t already have an extractor (save your BIOS legs from future accident, they bend SUPER easy) Yes, file is OK, it was that site you uploaded to
I checked your mod, and as suspected, padding issue (added in this case) directly below 472A583E-70CF-465A-BB77-53ADFCDB5883 padding file is added vs stock Rest of the edit I can’t comment on, sorry, I know nothing about editing DSDT stuff.
So, once you have programmer, and use UEFITool 25.0 so you don’t have that added padding (or MMTool 5.02 may work too, I did not check), and it still fails after dump/edit/program, then the issue is in the actual edit or replacing back in that table etc.
mmm I just tried with 25.0 version and compared hex of both rom files and they are identical, so I think that this padding is added also with v.25.0: can I ask you where do you see that padding being added (sorry for dumb question)?
I don’t see anything you “Filled with FF”?? Where is that? Yes, it may be that 25.0 adds padding in this one too, sometimes both new and old do it, in that cause you should use MMTool instead. I see the padding added just below the GUID I mentioned above (Search via GUID in UEFITool with BIOS open side by side, you will see) It’s just below OCMR_DXE
I will check now and see which MMTool will do this without adding that padding, or how to make 25.0 do it without adding the padding (ie extract already modified/inserted module as-is, and replace entire module with UEFITool 25.0 and see if same happens)
Thank you, yes no 0xFF, I modified my patch in respect to post #1 to have the DSDT table exactly the same size of the patch, so to exclude a possible issue of different size. No way to remove that padding, even if I remove it it’s added again once rebuild, I will try again MMTool too.
OK, thanks! See my edit above, in case you still can’t find the padding I mentioned
Send me an AFU Dumped BIOS, so I can see, it may be this padding is there in actual BIOS, but not in stock (sometimes this happens too, and it may be OK) All versions of MMTool add the padding too! Yes, you can’t remove it. To work around this will take me some time, it’s a delicate dance . I will make you BIOS for test without this, happening, please wait patiently. But, let me check your AFU dump before I spend the time doing that if it’s not necessary.
You’re welcome! Thanks, this confirms the padding is no there on chip either. This may not be the issue with your mod BIOS, but I would start suspicion here, and then if working past that fails, it’s either your actual edit or the AFU Flash Give me some time, I will redo your edit with stock BIOS and your modified AMIBoardInfo Module, without the padding being added in there on rebuild.
Thank you, no need to go fast, I lived with the stock bios for years, I think I can still live with that If it’s not too much demanding can you write how you modified it?If it’s too complicated/too long to describe it’s not a problem of course!..I’m interested more into going deeper into the issue in respect to just have a working file to flash.
I’m always behind and lost in threads here, so it may take me a little bit anyway, but I will try to get done quick as I can. If it’s easy, yes I can tell you, but generally this may take a few hours and 15-20 interim builds, so it’s really not ideal to explain or show how to do it.
On a basic level, I will remove several large modules inside the main DXE volume (The volume we’re editing in). Then with MMTool and or UEFITool I will get your mod file put back in without padding added, then add back in what was removed. Sometimes that can be adding all modules back at once, other times one by one with alternating tools, sometimes few at a time OK etc. It’s a long dance to do, but at the end, it makes stuff like this possible. I have to do it time to time for microcode edits or NVME inserts, usually on Asus, but sometimes Gigabyte too.
It seems exactly the same issue, same warning in uefitool ne when opening the original bios file.
I was thinking if the position of AmiBoardInfo inside the volume is important for a proper file build, because if extracted/modified/deleted and re-added at the end the pad-file is not generated…
@ghost82 - It’s location “should not” matter, so good eye on catching that! I’ve moved Setup to end a few times to avoid this issue too. Test a file with AMIBoardInfo moved to end instead (use 25.0), remove it, save as interim file, then on new interim file add the mod AMIBoardInfo back at end. If that fails, try same with MMTool 5.02, it will automatically insert at end when you insert This is happening because your rebuild module size is larger than the original, due to new/different compression, so everything is moved off below it (3EEF origin size >> 3EF6 Mod size) With it moved to end, only free space below that would need be affected/realigned and it does not matter so would not be. That should work
Actually here, test this - http://s000.tinyupload.com/index.php?fil…561586601390687 If this works, then I can show you what I did (made brand new AMIBoardInfo FFS / “Module” As-Is) New FFS size 43CC which is larger due to different compression method used, but maybe it’s more aligned that way, no hassle on rebuild and no padding added or removed, if inserted with UEFITool 25.0 (did not test other version, I always use 25.0 since it messes with this least of all usually) I did test insert with MMTool 5.02 = fail, padding added again, suspect same would happen with UEFITool 28.0 >> Actually << Confirmed 28.0 also OK, identical output to 25.0 in this case
@Lost_N_BIOS thank you very much!you did it! Your rom file is working perfectly, after about 20 flashes one rom that works Patch in the DSDT is also applied correctly and finally after 7+ months this motherboard is able to properly shutdown in linux.
I did not try (yet) my rom with AmiBoardInfo at the end: I read that DXE drivers should be position-independent in the volume, but I’m not too much confident it will work (let’s say I think I have 50% possibility to boot with it).
I looked at your rom image but still not clear how you did it → again, if it’s fast for you to explain it’s very appreciated 1- ok, I understood and seen clearly in uefitool that the new AmiBoardInfo is bigger and this caused "the issue" 2- you said “made brand new AMIBoardInfo FFS / “Module” As-Is”: I understand that I can modify the original cap bios, export AmiBoardInfo as body, make changes with hex editor, replace body in original cap bios, extract AmiBoardInfo as is 3- I miss the last step: if I replace (starting from the beginning by opening the original cap) the AmiBoardInfo as is, with uefitool 0.25.0 pad file is added, if I delete and add AmiBoardInfo in the same position pad file is added, if I delete all the content in the volume (before I extracted as is all 161 modules) and add one by one respecting the position (starting from the last module), at module CspLibDxe (if I remember well) pad file is added again (or maybe I should start from the beginning for proper alignement…(?))
My only way is to add that AmiBoardInfo at the end of the volume.
(…and q-code 06)
So if you do not have programmer, and nothing helps, you need to get programmer before you are sure which is failing - your edit, or the AFU /GAN flashing.
. I will make you BIOS for test without this, happening, please wait patiently.
