[SOLVED] How to unlock BIOS options of rebranded TONGFANG chassis systems?

BIOS/UEFI Modding BIOS Modding Guides and Problems
81




It was a question sorry about that, I wonder if I can test with an Ubuntu Live USB flash drive. The way it is setup now it iwll boot to black screen because of the switching graphics?


Interesting, let me try with iGPU force enabled instead … and force dGPU off. I just want to see whether or not this is actually doing something or if the hardware less (muxless) set up overrides all this stuff and these options do not actually do anything. Give me 5-10 mins.

Well good news, that actually did force dGFX off … the acpi_call to force it off that I usually use in Linux to preserve battery failed because it no longer sees the PCIe port it’s supposed to be on (as I forced it off). Even using prime-select to force it to use the nvidia driver doesn’t do anything … when you run hwinfo --gfxcard it shows i915 (built in iGFX) driver in use. tlp-stat -b also shows the correct battery drain with dGFX off (with it on it’s usually 1500+ mA, off is usually < 1000 mA).

I will retry with dGFX on, but I fear I will run into the same problem as you which is booting to a black screen, which will force me to use my programmer.

82




It was a question sorry about that, I wonder if I can test with an Ubuntu Live USB flash drive. The way it is setup now it iwll boot to black screen because of the switching graphics?


Interesting, let me try with iGPU force enabled instead … and force dGPU off. I just want to see whether or not this is actually doing something or if the hardware less (muxless) set up overrides all this stuff and these options do not actually do anything. Give me 5-10 mins.

Well good news, that actually did force dGFX off … the acpi_call to force it off that I usually use in Linux to preserve battery failed because it no longer sees the PCIe port it’s supposed to be on (as I forced it off). Even using prime-select to force it to use the nvidia driver doesn’t do anything … when you run hwinfo --gfxcard it shows i915 (built in iGFX) driver in use. tlp-stat -b also shows the correct battery drain with dGFX off (with it on it’s usually 1500+ mA, off is usually < 1000 mA).

I will retry with dGFX on, but I fear I will run into the same problem as you which is booting to a black screen, which will force me to use my programmer.


That is great news, for me I would need dGPU only enabled for MacOS although right now I am running with iGPU and nVidia disabled with an ACPI SSDT patch. I prefer to use Nvidia obviously in MacOS. so adjusting those settings I highlighted is all you needed to change, I am lost as to why its replicated three times in AMIBCP? Did you load optimal settings for this to work? I also wonder how this will work in windows if disabling iGPU then dGPU will still boot without black screen, or will the windows drivers ignore the bios settings.

83

@pcfr33k I am testing it now … I just hope I can go into the BIOS if iGFX is off. Otherwise it’s back to taking my backup laptop out and using the programmer. In addition to what you did, yes, I F3’d for optimal settings but I also set “Select PCIE Card” entries (Elk Creek 4 for setting DGPU to activelow or PEG Eval to set it to activehigh). In the case of iGPU, I also set skip scanning of external gfx to on which forcefully skipped the scan for it.

EDIT: Bad news, black screen for me too … don’t even see the OP logo come up now. Doesn’t look like it likes dGFX only on boot up. I’ll get it back up and running again later. It definitely posted though, because it’s not really frozen, just no display (e.g. ctrl+alt+del works to reboot it).

84



Give it a few minutes before turning it off to see if it does boot, or turn off and boot again and wait. I saw this before and it finally boots. I think there was a setting for initial iGPU boot and not one for dGPU possibly? Also maybe don’t disable primary gpu and only change SG to PEG and the other setting you changed.

85

@pcfr33k… Nop definitely doesn’t come up. It’ll need to be reflashed via programmer. Also I’m not sure that option would help but I can try it later. These bioses are basically generic to support a myriad of laptops but the hardware needs to support what you are trying to do. For example this is letting me set iGFX as secondary display but on the TONGFANG I am almost positive the video outputs are wired to the dGFX. Same with the Optimus settings. Switchable stuff would work if there was a hardware mux to control it which is what the BIOS edits are trying to do. So I think we will have to continue to use software hacks to turn it off.

86

@nimaim - yes, changing hidden settings still get applied even though you cannot see them
Yes, Muxless was only option I found, other settings for that are missing even in the IFR, however it could be in another section and I missed it or overlooked while trying to browse around too quickly. If muxed is needed, and it’s not there, then no go.
Looking at the IFR, I think they simply removed the other three options, since Muxless = 0x2, let me see if I can add them back for you guys or not, if not I will see about changing default muxless to muxed as the only option.
No luck, changing the ID’s only changes setting option to other missing settings such as PowerXpress, PX Fixed Mode Switch etc. and not an actual setting value. I went up and down in ID’s, and none are the remaining 0x0, 0x1, 0x3 that should be there for this setting.
Someone check all the other BIOS setup IFR’s and see if you can find one that contains all 4 settings for SG mode, if you can, then we can use it instead.

Example -
09 07 60 15 30 00 02 << Default, this is there, should be remaining others like below
09 07 58 15 00 00 00
09 07 59 15 00 00 01
09 07 61 15 00 00 03 etc, but adding these or changing the original to one of these, does not have the expected outcome, so these others have been removed from the assembled coding, not there at all anymore.

Sorry @pcfr33k I forgot to mention, there is often many duplicates of settings in AMIBCP, depending on hardware, suppressed settings, gray out settings etc only one is usually visible so one used at a time. You can however set them all to same behind the scenes in AMIBCP

87

@Lost_N_BIOS my point is isn’t it useless to add those settings back if the hardware does not support it? So is it even worth looking at?

I think all BIOS variants of this chassis are set up the same way.

EDIT: Back up and running now … flashrom and this cheapo CH341A programmer have been solid thus far :knock on wood:

88

Yes, that would be true, if you are sure the hardware doesn’t support it? Keep the back off your system if you can, plan to send you some files today or tonight that you may need programmer recovery from too

* Edit - NO ONE FLASH/PROGRAM/USE these BIOS - unless you are prepared for hardware flash programmer recovery and already have valid and verified backups created. .
This is a default NVRAM edit test package, anyone using will have their serial, UUID any system specifics erased. The first one minimal damage/change is being tested (4-6 bytes changed), the second test BIOS may be most destructive (Setup values in NVRAM entirely FF’d)
Reasoning for these tests are to see if NVRAM in any way is controlling visible menu’s
http://s000.tinyupload.com/index.php?fil…714547186934963

@nimaim - thanks for your continued testing >> from everyone else!

Side-note to all/anyone editing, I just noticed in this BIOS example, access level changes in AMIBCP changes are applied to AMITSE-SetupData module, not NVRAM which is the usual in many instances
If changing access and settings, then NVRAM is also edited (If only settings changes, then only NVRAM is changed)

89

Give me a few hours to test the last few … I’m out at the moment. Thanks.

90

@nimain Could you try connecting the laptop with an external monitor/tv while only enabling dGPU? If the external display works (even though the internal one doesn’t), it’s very likely the dGPU can be driven in macOS. Then we can use the laptop as a Mac mini, only it’s faster (although more noisy) than the latest i7 Mac mini.

91

@Lost_N_BIOS No change after flashing Edit1, does it make sense to still flash Edit2? I’m guessing I should see something with Edit1 if NVRAM modification has any affect, correct? If it doesn’t even post after Edit2, there’s not much I’d be able to tell you anyway.

@Johnazz I’ve already tried to fully disable iGFX and use dGFX, it does NOT work. Optimus keeps iGFX on until it needs the dGFX (and for external outputs as it’s wired to that). I don’t think we will see much headway with hackintosh in that regard. It’s up to the software/OS to control the GPU with muxless setups.

92

@nimaim - yes, please always test all BIOS I send, thanks. And for that particular set, VERY different edits (#2 has entire “Setup” part of NVRAM erased) Yes, if no post that doesn’t help, but it does let us know don’t do that again
And no, edit 1 was just a guess edit, I changed a few bytes I thought maybe would be menu tabs vs other things I knew was not.
I should have mentioned before too, for these clear CMOS after flash then (always) load optimized and reboot to check, if you can get into BIOS, sorry I forgot about this but it’s important for this particular test set.
No need to redo test one, it’s OK, check test 2, clear CMOS then load optimal and look in BIOS after reboot.

93

@Lost_N_BIOS Sorry, as it’s weekdays, been busy with work … I should have some time to test this after work tomorrow.

94

@nimaim no problem! Nimaim and anyone else with a flash programmer, I have high hopes for some in this new set here, I think I found it now in AMITSE and no assembly work required!
I plan to test similar method on some random board I have here now, just need to find one with similar BIOS layout (Asus or Gigabyte Z170 probably)
But yes, please also let me know outcome of the #2 on NVRAM set when you have time, just in case, plus will be good to know what happens when you do that to an entire NVRAM entry
http://s000.tinyupload.com/index.php?fil…521905574413651 << 160MB unpacked / 16x BIOS

Please first test all four in “Highest Hopes” folder, then +BCP, then others in less faith last

Also, here is my notes on my findings within AMITSE, in case this helps anyone else looking into this or tinkering around
From Setup >>
Visible
Form: Main, FormId: 0x2711 {01 86 11 27 51 17}
Form: Advanced, FormId: 0x2712 {01 86 12 27 52 17}
Form: Security, FormId: 0x2713 {01 86 13 27 53 17}
Form: Boot, FormId: 0x2714 {01 86 14 27 54 17}
Form: Exit, FormId: 0x2715 {01 86 15 27 55 17}
Form: Tablet, FormId: 0x2716 {01 86 16 27 56 17} Not visible (not in AMITSE tables either, may explain “17” yet still hidden, unsure - this “17” throws me for a loop)

Not Visible/hidden
Form: Main, FormId: 0x2717 {01 86 17 27 09 00}
Form: Advanced, FormId: 0x2718 {01 86 18 27 1E 00}
Form: Chipset, FormId: 0x2719 {01 86 19 27 1F 00}
Form: Security, FormId: 0x271A {01 86 1A 27 3A 00}
Form: Boot, FormId: 0x271B {01 86 1B 27 20 00}
Form: Save & Exit, FormId: 0x271C {01 86 1C 27 4E 00}

Note missing 5X “17” at end on hidden forms = add “17” as test & 5x 17 as second test (Both ways fail, changes menu to other items, still may need to be investigated further)

* Please Note - All addresses/offsets below are off by a few bytes, gathered this info on a file I removed bytes from beginning of (Up to 4d 5a) to open file in IDA properly.

From AMITSE/PE32 >>

@ >> 00055c64 (“ALL” Main Menu Entries, swap locations possibly, probably not needed)
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 17 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 18 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 19 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 1a 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 1b 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 1c 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 11 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 12 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 13 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 14 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 15 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00

@ >> 00055e84 (Looks like block of only hidden) = swap (After figure out & get both enabled) or FF/00?
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 17 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 18 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 19 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 1a 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 1b 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 1c 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00

& @ >> 000534c4 (only non-visible entries, except Setup) = swap (After figure out, to hide duplicate) or FF/00? May need multi/combo test, swap above + FF/00 here or FF/00 here nothing above + “17” change at setup etc
10 27 17 27 19 27 18 27 1a 27 1b 27 1c 27

10 27 = Setup (Main Setup Entry, also hidden as a general default in most all BIOS I suppose)
17 27 ^ Is above ^ (Hidden Main)
19 27 ^ Is above ^ (Hidden Chipset)
18 27 ^ Is above ^ (Hidden Advanced)
1a 27 ^ Is above ^ (Hidden Security)
1b 27 ^ Is above ^ (Hidden Boot)
1c 27 ^ Is above ^ (Hidden Save & Exit)

* General concepts/thoughts used above confirmed and working on Z170N-Gaming5 ***
However, since that board is a UEFI with heavily graphical BIOS, the name for the tab does not show nor it’s “name section”.
Only original tabs are there, but scrolling to where it should be it’s replaced the last menu and then the actual last is past the new one but off screen.
So, even if you do not see it, in case this happens on this board, scroll right to left past the first/last sections visible to make sure if it’s there or not and just not visible (hope you get what I mean)
If it also happens on these systems we’ll have to figure that out next, but I’m betting this is only due to this boards UEFI/GUI BIOS layout and predefined graphics for the tabs and tab area

Now I have super high hopes and am sure we’ll get there for this board if one of the above BIOS do not do it already!!
The Gigabyte BIOS was a bit different, had two top and bottom sections like you see above, with one missing entry on top, so I added in.
There was no third section (000534c4) in this BIOS AMITSE, where I think are the hidden entry list above, since they aren’t trying to hide things in that BIOS, so it’s a little different, but similar concept and most importantly… Success!!!

95



Lets take the first one {01 86 11 27 51 17} and break it down.

Offset 0 - Byte 0x01 is the Opcode, 0x01 means "Form"
Offset 1 - Byte 0x86 is the length but also has an extension bit (bit 7) so 0x86 -> 0x06, means 6 bytes long.
Offset 2 - Word 0x2711 becomes the "Form ID" 0x2711
Offset 4 - Word 0x1751 becomes the text number for the "Form Title", in this case "Main"

Hope this helps.

I guess I’m going to have to have a closer look at the AMITSE to be of any help.

@nimaim did you try changing cmos offset 0x7A? It should cause a different path to be taken for the menu’s in AMITSE but possibly the routine isn’t even called. If you would like to try it then it can be done by running RU.EFI and selecting Alt + 3 then moving cursor to offset 0x7A and entering 0x01. Restart and check if setting sticks and if so then check setup to see if any different. If you would rather not test that is fine too.

96

Thanks all, I will try all these suggestions tonight! Looks like you made a lot of head way @Lost_N_BIOS. Let’s see what happens!

97

@CPL0 Thanks for the info. that helps explain the “17” and why trying to use it and or other 5x with it fail (even when not used in other settings). So on one of the hidden (Main) does that mean it’s Form Title 0x0090 = Main (Second, something, hidden etc)
I think I may have figured it out, at least I have and confirmed it for similar BIOS. Which AMITSE SubRoutine would that 0x7A be in, I can let you know if I’ve already sent him an edited file with that change.
I think I included a bunch of AMITSE edited routines this time around, but most of those were before I found these menu strings. So they might work, but I have more hope in the later edits where I edited the strings above rather than changing path directions.
Changing paths and skipping jumps was my first main goal in setup and AMITSE, but I was trying blind without knowing how to ID to tabs in any of the coding.

@nimaim - yes, I think I got it! I planned to confirm similar changes on my end first, but got excited and sent before testing on my end. Then after posting I finally took the time to setup a board and create a test BIOS here.
I forgot to mention above, the changes did not matter until I tried BCP post-edit to user, so probably same may apply to your BIOS too, especially since yours is specifically trying to hide/skip and mine wasn’t but still needed that change post-main-edit.
So you should first test “Highest Hopes +BCP” folder BIOS first. If success, for now you will have duplicate ADV, I left in place all old menu entries until we figure out the unlock/unhide, then I will clean it all up once we’ve got it sorted out.

98

@Lost_N_BIOS seems you absolutely did get it! Many, many thanks to your hard work and time put in.

Here are the results:

Highest Hopes + BCP:

Hidremx2U.rom: No change
Hidremx2CuA4U.rom: On bootup, got error saying “SystemBootOrder not found … Reset System” and it boot loops, cannot go into BIOS or anywhere else, had to use programmer to recover
Hidremx2L00U.rom & Hidremx2LFFU.rom: BOTH WORKED! Fully unlocked second Advanced and Chipset menus after the stock Exit menu! See attached.

I guess we can also clean it up now, although it’s totally not necessary, just a nice to have. I guess it’s also worth unlocking the other menus like the second hidden Main which provides additional system details. If I understood how you did this, I can do the rest myself :slight_smile:

Would it be possible to provide some crude instructions? I’m hoping to turn it into a guide as MANY other bioses seem to be this way.

EDIT: Looks like you did explain it above, I will read it more carefully tomorrow and try to figure it out.

20190116_185828.jpg

20190116_185809.jpg

99

@nimaim - Awesome news, thank you for all the testing too!
Thanks for the images, I mentioned in PM I’d need to see all subsections within but wow that is a lot on the ADV. Can you, when time permits, look through (or image) so you can see on your end, if everything is there in each one vs what you see in AMIBCP.

And yes, I always planned to clean up, once we figured out method. I planned to enable all the best menu’s, and hide the other limited menu’s. And I’m pretty sure I can rearrange them as well.

Thanks for testing results on those 4 above. I thought 00/FF would work, just wasn’t sure if one was better than the other so made both ways to see if results were same or not.

Yes, please see above notes for most info. For the 00/FF edit I will “try” to explain briefly what to do below

Open BIOS in UEFITool, extract Setup’s PE32 module as-is, then use Universal IFR extractor to get IFR for the file, this will give you your main menu Form ID’s. Then also extract AMITSE’s PE32 module as-is, this is what you edit to unlock the menus (+BCP)
At the very top of the Setup IFR, you will find each BIOS main Form Set ID, this is used to search in AMITSE to find all you see below easier. This may differ for some BIOS in these related models, so adding this as update, the highlighted portion is what you need.

FormSetID.png


@ >> 000534c4 (around there) find the list as I showed above, it’s short and only has the “hidden” menu Form ID’s backwards. There FF or 00 the menu’s you want to remove from the block list, this is what you tested in the two FF/00 BIOS (only this line was FF or 00, rest was 00)

AMITSE-Edit1.png


@ second location >> 00055e84 (Around), you’ll see the second block I posted above, these are the full menu ID’s that are hidden. Remove the ones you want to have enabled via 00, this means cut entire menu ID and replace directly below that with your filler 00

AMITSE-Edit2.png



Always be sure when you cut/delete to add back (insert) same amount after that, example below.

If you cut the following (32 bytes, 20h)
4a 10 59 7b 0d c0 58 41 87 ff f0 4d 63 96 a9 15 19 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00

You must add back the following (32 bytes 20h) either in it’s place, or below as see in the image (optical illusion, it’s same length
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Then once done, enable your menus to User Access Level in BCP (This can also be done via AMITSE SetupData module hex edit too, but it’s easier to edit with BCP)
And while in AMIBCP change your hidden menu names to be whatever you want, at the root level make these changes (ie directly at top of setup). Make sure you are changing the hidden menu names!

So now, we need to clean this mod up!! I’ll look through AMIBCP tonight and see which menu’s are best for each item, and enable only those, removing the limited ones.
I assume that’s removing all the stock and enabling only the hidden ones. I wonder why they do this to people!? Probably to dumb it down for some I suppose, but they should at least offer choice or simple/advanced menu for those that want some control.

100

Congrats guys, a well deserved result.


Well yes but I think you meant to say 0x0009 :slight_smile: