With the 2600X it doesn’t work, no ReBar setting in bios and with Above 4G enabled ReBarState still doesn’t work. Only the modded bios made it work, so there are some limitations for Ryzen 2000 CPUs.
With the 2600X there’s nothing 
Partial success.
“Flashed successfully and powered on. It turned off / back on by itself after 10-15 seconds, then 8 beep codes/red flashing LED.”
This non-standard HP UEFI is such a nuisance …
Hey any idea why the saved bios file on my pc and your link are not working anymore eveytime i try to use them i just get the message that the bios file is corrupt and it does not look like a bios file i had it saved on my pc and i tried the download link again because of a power issue at home and my computer would not restart so i was going to reflash the bios and now i cannot?
i figured it out you still have to use asus bios renammer
it is asus iy is working im talking to you on it now
i guess when you use the renammer from asus it changes something in the name file and it makes it just fine
There was a safety measure, I think, on AGESA 1.2.0.0(?).
I know the result, you posted the related link before.
What does this code mean?
Maybe the bios checks for the drivers presence? I had to delete Mtftp6Dxe network driver in order to fit ReBar dxe. There is no space to insert the dxe normally. In fact uefitool shows the potential free space at the end of lzma-compressed section, and not real.
If you try to manually compress (using LzmaCompress.exe) the uncompressed section body with only ReBar inserted, the output file will be hundreds of bytes bigger than the original section.
But there’s around 4 bytes of the free space between the section. If it’s not enough, uefitool shifts the section by shrinking another free space.
I can try to fit ReBar dxe without deleting any driver, but I’ll still have to alter some to get more space.
1 Like
Invalid rom image / corrupt ROM. From the maintenance manual:
Red Power LED blinks eight
times, once every second,
then stops blinking.
Entering FailSafe
(BootBlock) Recovery
Mode
Either FailSafe detected a corrupted ROM, or the user pressed Esc
before powering on. The BIOS does not halt at this point, but attempts
to boot to a ROMPaq floppy or CD-ROM (USB devices are not
supported).
1 Like
So, I think this is connected with encryption of DXE volume. The bios doesn’t get corrupted by someone’s changes, but detects it’s been altered and halts on startup.
Don’t know why @bibikalka pointed our other sections being shifted after the module insertion as the culript.
Structurally, the volume condition was still fine.
2 Likes
So we tried replacing the microcode section, and that worked fine as long as the current cpu microcode is present.
So the bios modifications might be checked only for specific areas? Is there a way to disable that?
There is an older v1.62 version that’s out there - link
There was something in those older versions that HP fully deleted them from their ftp site while leaving a few other non-recent versions available. For example, the older versions would boot with a missing microcode, but the latest is no-go. I guess that’s also a function that checks for this now.
With enough ethusiasm the owner could determine which volumes are protected. There’s no ready-made solution I know.
At first the check was just one function, but then the vulnerability was fixed and I stopped monitoring updates on this.
Down below is a list of modules which are present in the new version, but not in 1.62.
29 in total
AmtGbeChecksum
PlatformHardwareHarden
S3SupportSmm
PchSmiRegister
TcgMorLockSmm
TrEEDxe
TrEESmm
TrEEPlatformDxe
HpPwdPresentModule
LoadEFiNetworkStack
MeFirmwareRevisonCheck
SmmCommBuffer
16642314-
c6ebac6-
866e407c-
e3982c12
HpEsrtDxe
AcpiDebugSmm
dab2542b-
HpLibArchiveWorker
HpLibArchiveDriver
HpRemoteDiagnosticsDriver
c3aa909b-
HpCertificateManagerDriver
b9b31089-
83b1d167-
PiSmmCommunicationPei
TrEEConfigPei
TrEEPei
A lot more modules have diferences in size, sometimes very drastic.
Not a complete list, could not handle comparing all of the modules
342395AD-66A2-403C-9985-E82218625715 386 -> 1335
B5B0F67F-50BD-4650-867D-EA27CBDF1BBE 4 -> 401
E6AF66A5-9A57-4E82-BD92-301282A0DC33 1 -> 391
6D33944A-EC75-4855-A54D-809C75241F6C 1 -> 215
and etc.
Im keen, though I’d need some initial guidance to get started
@Planky
You could edit a driver in each volume one by one and see which gets the bios to corruption. If you don’t know how to make edits while leaving a module in valid state, replace modules from the older 1.62 version.
If it turns out that the PEI volume is not protected, try replacing the whole volume from 1.62 bios as there’s a chance the protection code sits just there, provided that 1.62 bios is really unprotected.
I was able to flash it, but I cannot access the “Peripheral” section coz it locks up, everything else works
So the approach could be workable, but one needs to establish that 1.62 really did not have those protections!
@Planky - you may want to downgrade to v1.62 using that jumper approach and the official bios package, and then dump the full 16MB of v1.62 bios using the clip. Then you could try to add ReBar to v1.62, and see if that boots.
Once v1.62 is verified to accept modifications, one could try to move the functions from that bios to the latest one.
If v1.62 with ReBar module is still no go, then we’ll need to rethink the approach.
1 Like