With the help of AI, I was able to recover, modify and make functional the hidden Jumperfree FSB settings for ASUS P2B-B board. The resoldering of JEN wire jumper is not needed.
The package contain also documentation of the modifications. That may be helpful if someone would like to make the same or similar changes to the BIOS of one of the many revisions and variants of the P2B boards. The most suitable would be P2B rev 1.10, becuase of the same PLL clock generator chip.
The attachment bios1.jpg is no longer available
The attachment bios2.jpg is no longer available
The attachment P2B-B_BETA004-JumperFree-mod.zip is no longer available
Thank you for uploading whole thing instead of just the patch, a lot of learning opportunities inside. I love DEAD_ENDS_AND_LESSONS.md.
Which LLM did you use and how much was it total? How hard did you have to herd the cats? Judging by
gems like "A decompressed offset is not a stable compressed-ROM offset. Recompression changes much of the packed stream." it wasnt all smooth sailing ๐
Was it instrumented by disassembler/ghirda/radare2 or did it burn tokens disassembling everything on its own?
From retroweb description https://theretroweb.com/motherboards/s/asus-p2b-b
"Unlike its P2B ATX sibling, this board ships with the JEN jumber hardwired for manual CPU multiplier and bus frequency. By desoldering the wire and replacing it with a normal jumper, it's possible to re-enable the missing "CPU PnP" feature, with multiplier and clock auto-detection and manual adjustment from BIOS. Latest BIOS is recommended for this feature to work correctly."
sounds like this functionality was already there with bios somehow detecting state of JEN jumper? and your patch swaps that for a check of added CMOS setting? Im browsing the files and looking at BIOS code but cant find where the BIOS was originally reading JEN value ๐
those look backwards/reversed?
original_stn_decompressed.bin looks patched, jump inserted to additional function
1248A mov eax, 1 22490 cpuid 32492 jmp loc_E0F5DC 42495 db 6 52496 db 0 62497 db 0 72498 loc_E02498: 82498 jnz short loc_E024AA 9249A mov ecx, 33h ; '3' 1024A0 rdmsr 1124A2 or eax, 40000000h 1224A8 wrmsr 13 14patched in function in original bios: 15F5DC cmp ax, 611h 16F5DF jnz short loc_E0F5F4 17F5E1 mov ecx, 1E0h 18F5E7 rdmsr 19F5E9 and eax, 2 20F5ED or al, 4 21F5EF wrmsr 22F5F1 jmp loc_E024AA 23F5F4 loc_E0F5F4: 24F5F4 cmp ax, 619h 25F5F7 jmp loc_E02498
this patched in function in Original ASUS bios is optionally setting MSR ROB_CR_BKUPTMPDR6 bit 2 which some googling returns as some special sauce optimization https://martin.hinner.info/p6microcode/wiki/microcode "Fast Strings Enable bit.". This particular optimization is only active for the earliest stepping of Pentium Pro so not a big deal, havent looked at others tho.
while your patched final_full_post_hook_stn_decompressed.bin
had the clearly patched in jump removed and code reverted to pre special sauce patch aka deoptimized? did you orchestrate that or did LLM just derp on its own?
---------------------------------
I like all the LLMisms, like how it manually reads cmos when there is dedicated function for it it knows about, but then saves bx on the stack to call that dedicated cmos save just making the code longer for no reason. Its like 2 people who dont speak to each other wrote this 30 line function ๐
llm
1.code16 2.global _start 3_start: 4 pushw %bx 5 6 # Clock source selector: CMOS 0x42 bit 7. 0=BIOS, 1=Jumpers. 7 # Erased CMOS (0xFF) must also skip the multiplier write. 8 movb $0x42, %al 9 outb %al, $0x70 10 jcxz 1f 111: 12 inb $0x71, %al 13 cmpb $0xff, %al 14 je done 15 testb $0x80, %al 16 jnz done 17 18bios_mode: 19 movb $0x4f, %al 20 outb %al, $0x70 21 jcxz 2f 222: 23 inb $0x71, %al 24 cmpb $0xff, %al 25 jne 3f 26 xorb %al, %al 273: 28 andb $0x0f, %al 29 movb %al, %bl 30 31 movb $0x3a, %al 32 call 0xea89 33 andb $0xf0, %al 34 orb %bl, %al 35 movb %al, %ah 36 movb $0x3a, %al 37 call 0xea92 38 39done: 40 popw %bx 41 ret 42 43sub_E0EA89 proc near 44 out 72h, al 45 jcxz short $+2 46loc_E0EA8D: 47 in al, 73h 48 jcxz short $+2 49locret_E0EA91: 50 retn 51sub_E0EA89 endp 52 53sub_E0EA92 proc near 54 out 72h, al 55 jcxz short $+2 56loc_E0EA96: 57 xchg al, ah 58 out 73h, al 59 jcxz short $+2 60locret_E0EA9C:
Im no expert, You could probably make it more optimized.
My knowledge of disassemble ended at university by programming Z80 15 years ago and some decompilation work for cybersecurity competition last 2 years, so to do the changes manually, is over my league.
2 years ago:
To unlock the menu the JEN jumper had to be resoldered and if I did it I was stuck in a loop:
At post screen I got an error , it threw me into the BIOS with message CHECK CPU CORE.
It probably except me to set th eproper multiplier and FSB.
But because the BIOS didnt have the fuctionality to really apply these values, at next boot, I was again thrown into BIOS with error message.
I asked one guy if he could re-enable the functionality of the hidden menu and he realized that the menu is there, but the values are never applied.
few months ago:
I saw another guy modifiying VGA Bioses with help of AI
A month ago:
I gave AI a chance too and Im glad I did.
It was all done by a ChatGPT 5.5 High effort.
I decide to ignore the JEN jumper and made a "BIOS" jumper.
And the whole process wasnt smooth sailing, but when I can chose either "nothing" or "poorly optimized, but working BIOS" modified by LLM, the choice is clear, at least for me.
The strangest thing was that the LLM at first tried for some reason to make its own menu and not use the one alreday there, it worked conceptually, but messed with other things. I one of the fresh chat session, where I carried over the history of the previous sessions, it realized how to make the menu visible without the need of JEN jumper nad from then it was quite good. I had to try several empty spaces where to store the new code and data, but that was expected.
At first I verified the BIOSes in AWARD BIOS edotor, until the LLM get the decompresion and compresion right with all the CRC checks and I also verified it with 86Box emulator. After that I tried on real HW.
I do not have the complete history, but it took like 10 chat sessions used to its length limit to produce it. For one particular bug I used Claude Opus 4.8, because ChatGPS wasnt able to solve it, but that was like 3 messages.
The whole process could take like one week, If i did it at once.
Maybe next time I should ask AI to optimize it as well, but I was happy that it worked, so I didnt tempt my luck ๐
Maybe next time I should ask AI to optimize it as well, but I was happy that it worked, so I didnt tempt my luck ๐
its not that the code it wrote is not optimal, well it is but thats not a big deal just fun to read, but it legit removed real ASUS CPU initialization that was in original BIOS. It somehow found ASUS patches at 21C7 239D 2492, recognized those are special CPU MSR patches, and ripped them out ๐ฎ seemingly for no reason. I was curious if you had a hand in that or if LLM did that on its own.
Thaks for investigation.
I confronted the LLM with your feedback. It deleted that for no obvious reason, also with 3 more additional patches. ๐ It put them back. I will test it in approx. 2 weeks, when I will have access to the motherboard again. I ordered a muliplier unlocked early Celeron 266, to test also if the multiplier changing works.
I will update this thread after the tests.