Firstly, in the PDF I was converting every little endian values to big endian. So,
parent[01 00] and destination[3B 00]
to [00 01] and [00 3B].
That’s where 00 01 00 3B came from.
Secondly, you allowed to not alter the parent id. This wasn’t said in the pdf and it sucks in this term.
What bytes are we interested in, then? In your fork, the gap between byteArray[7] and byteArray[4] is 16 bytes, while it should be 18 bytes.
Ayoo, I even started thinking that ChatGPT wrote the code for you. 
Yes.
I’m just living up to my name with some brain farts 
. I don’t use ChatGPT for this, I don’t trust it.
Anyway, I’m going to try to get confirmation from volunteers that this works as intended next week and then implement it in the main branch. Thanks.
So it really is that bad… 
Thanks for the fast reply.
Hi! I was wondering how much luck you’ve had with the unlocked options. I have the 12800H erying motherboard and managed to get the options to show up following your instructions.
However, it seems like the options I was most interested in (BCLK and ICCmax) don’t actually have any effect, despite me now being able to change them in the bios.
Is this something you’ve managed to tackle?
BTW, where does this info come from? Is there official documentation somewhere?
Don’t know if there’s a documentation. I just copypasted the info from some russian forum.
I left a hyperlink on the first page of the pdf.
Actually, I have something that can be called documentation. But I’m not sure if it’s okay to publish it.
#define CONTROL_TYPE_NULL 0x0000
#define CONTROL_TYPE_SUBMENU 0x0001
#define CONTROL_TYPE_LABEL 0x0002
#define CONTROL_TYPE_TEXT 0x0003
#define CONTROL_TYPE_DATE 0x0004
#define CONTROL_TYPE_TIME 0x0005
#define CONTROL_TYPE_POPUPSEL 0x0006
#define CONTROL_TYPE_MEMO 0x0008
#define CONTROL_TYPE_MSGBOX 0x0009
#define CONTROL_TYPE_CHECKBOX 0x000A
#define CONTROL_TYPE_NUMERIC 0x000B
#define CONTROL_TYPE_EDIT 0x000C
#define CONTROL_TYPE_PASSWORD 0x000D
#define CONTROL_TYPE_MENU 0x000E
#define CONTROL_TYPE_ORDERED_LIST 0x000F
#define CONTROL_TYPE_POPUPEDIT 0x0010
#define CONTROL_TYPE_VARSTORE_SELECT 0x0011
#define CONTROL_TYPE_VARSTORE_SELECT_PAIR 0x0012
#define CONTROL_TYPE_POPUP_STRING 0x0013
#define CONTROL_TYPE_VARSTORE 0x0014
#define INCONSISTENT_IF 0x0015
#define NO_SUBMIT_IF 0x0016
#define DISABLE_IF 0x0017
#define CONTROL_TYPE_VARSTORE_NAME_VALUE 0x0018
#define CONTROL_TYPE_VARSTORE_EFI 0x0019
#define CONTROL_TYPE_VARSTORE_DEVICE 0x001A
#define CONTROL_TYPE_ACTION 0x001B
#define CONTROL_TYPE_RESET 0x001C
#define CONTROL_TYPE_RULE 0x001D
Can share the file in private if needed.
I’ve had a volunteer test this method on an X670 Taichi, and it didn’t work for him. What boards did you test this with and confirmed it works?
Haven’t touched those settings. So do not know.
I have only played around with pcie settings and aspm. Those seems to work as intended.
(Apart from that hardware is buggy)
Hello, am about to play around with an Asus BIOS and had a look here again and saw this post. What’s the problem with Asus bios’s, changing references behind the F7(Advanced menu button)?
Can give a detailed example.
Better see yourself. Open the bios files in the editor, some names on the top from Advanced mode might not match what displayed in the editor.
Sorry. I’ve missed your message. Didn’t get a notification somehow.
The tested boards were Gigabyte Z270X DESIGNARE, Gigabyte B550M and another one gbyte board. So, they all from gigabyte.
Page ID only affect Ref Prompts. You expected changes to top references menu?
I only changed Ref Prompts.
Can you share the log or edited files if still have them?
Original: https://download.asrock.com/BIOS/AM5/X670E%20Taichi(2.02)ROM.zip
Modified: creative
Replaced NVME Sanitization Tool Ref page id with Advanced Ref page id.
There’s two elements of NVME Santization Tool in the bios. One with question id 6E in Advanced and another in Tool with question id 24. Perhaps, you replaced the wrong one, which is 6E?
I had the same result trying to replace PC Health in B550M bios. It has two PC Health pages.