How to Enable TPM 2.0 on ODROID-H2

[joshgoes]

Hey folks,

I have successfully enabled the firmware TPM (fTPM) within the J4105 on my ODROID-H2 (rev. B), with my OS interacting with the TPM 2.0 pseudo-device. Although my use-cases are around remote attestation, given the recent Windows 11 announcement I expect there would be at least one other person wanting this functionality too so I figured I'd sit down and write this up with screenshots and all.

If any ODROID staff are reading: I have no idea how much control you have over hiding/revealing items in the AMI/Aptio BIOS UI, but if you can, can you please reveal the Advanced > Trusted Computing menu? It's the Security Device Support menu item within it that I changed from Disable to Enable to get this working -- no other changes were needed as the defaults for all other settings are already perfect. The menu contains other useful settings such as TPM clearing operations, hence the request for that menu specifically.

---------------------------------------------------------------------------------------------------------------------------

Right-o, here we go. I've broken this post up into two sections:

1. The first section contains steps on how to enable it (aka "just tell me how to do it already").
2. The second section is how I discovered what bits to flip in order to get it working. I've included the second section because I am, and any sane person should be, always wary whenever a stranger on the Internet tells them to flip raw, unlabelled bits in SPI FLASH using a tool they've never heard of before.

The BIOS UI itself has oodles of menu items hidden for a variety of reasons -- some options facilitate low-level kernel debugging and development which most folks don't need, some options brick boards in ways that a hardware BIOS flasher tool cannot fix (ie. electrical destruction). There are a few hidden menu items that affect TPM functionality, and almost all of them default to an enabled state... but there's one little sucker that isn't, and that's the one being mutated below.

To be clear, this approach doesn't mutate/mod the BIOS ROM, but instead mutates a byte within one of the UEFI Variables in NVRAM used to store the settings you see in the BIOS UI. This gives the best of both worlds: running a stock, signed, official BIOS ROM from the OEM, and having TPM 2.0 functionality enabled persistently (until the next BIOS upgrade or BIOS config is wiped). In other words, the BIOS UI would change the same byte in the same UEFI Variable to the same value had the menu item not been hidden.

There is one downside to all of this: since all TPM sections are needlessly hidden in the BIOS UI, toggling options such as issuing a TPM Clear operation or forcing TPM 1.2 mode are only possible using the same technique: discovering which byte offset in which UEFI Variable to toggle and to toggle it accordingly. You're very much on your own if you need to go down this path.

---------------------------------------------------------------------------------------------------------------------------

How to Enable TPM 2.0

Disclaimer: Changing BIOS settings in this way is very risky, and depends on your competence, board revision, BIOS version, and the angle of the sun when you look outside. I am not responsible for anything you do -- be it following instructions here or with life in general. These instructions are only for people who have done this before and know what they're doing, or for people that were planning on binning their ODROID-H2 anyway and are happy to try bricking it before doing so. Seriously, if you feel uncomfortable, concerned or anxious about changing BIOS settings in this way, you should instead wait for an official BIOS ROM containing TPM 2.0 support; don't let your impatience make life hard(er).

These instructions work on my ODROID-H2 Rev. B board running GLK-SF BIOS version 1.22. I have not tested this on any other board revisions or BIOS versions, including all GLK-ESF versions. If there's sufficient demand I'm happy to try out different GLK-SF BIOS versions on my Rev. B board. I'll also edit/update this post if anyone attempts this on their H2+ board (or with any GLK-ESF versions with H2 Net Card) as I don't own any.

For those with GLK-ESF ROMs, or those wanting to use a non-1.22 GLK-SF ROM, the process should be very similar with a potentially different byte offset in the same or different UEFI Variable in the NVRAM. Have a read through the second section below to discover this for yourself with your downloaded ROM. The steps below assume the ODROID-H2 board is a Rev. B model running GLK-SF BIOS version 1.22.

1. Follow the official ODROID BIOS update steps to prepare a USB thumb drive with GLK-SF BIOS version 1.22. The EFI Shell is what's actually needed here, not any BIOS ROMs, and since the ODROID folks provide it in their ROMs, it's just the safest and most convenient way to get it.
2. Download the RU 5.20.0328 tool from its official website, and copy the RU.EFI file onto the USB thumb drive in the root directory. James, the tool's creator, always posts each ZIP file's password alongside its URL at the bottom of every release/blog post, so just read the ending properly and you can't miss it.
3. Reboot into the BIOS UI, and note the BIOS type (GLK-SF or GLK-ESF) and the version number installed (eg. 1.22). Head over to the Save & Exit tab and Restore Defaults, then Save Changes and Reset.
4. Reboot back into the BIOS UI and head over to the Save & Exit tab, and force the next boot to be from the USB thumb drive using the Boot Override section at the bottom.
5. If you're not already on GLK-SF 1.22, now's the time to follow the official BIOS update steps to do so. Don't continue on until you've finished the BIOS update process to 1.22, including the power-cycle step at the end. Boot back into the USB thumb drive's EFI shell and continue on to the next step.
6. Run RU.EFI from the EFI shell. One note about RU: it sometimes hangs randomly. I've tested this walkthrough many times before posting, and about 50% of the time the RU binary hangs at random points. This isn't anything to fear since it doesn't write or mutate anything about your system until you tell it to. If it hangs, don't sweat and simply reboot back into the EFI shell and try again. For what it's worth, I've tried versions 5.28.0397 and 5.20.0328 and found that the latter was more reliable, hence why I'm recommending it. Your mileage may vary. I'd be interested to know if anyone noticed any differences with an Ethernet cable plugged/unplugged.
   
7. Within the RU tool, press ALT+C to open the Config menu at the top, and navigate to UEFI Variable. This was the most frequent place that RU hung for me.
   
8. Scroll down the laundry list of UEFI Variables until you find one called Setup whose GUID starts with EC87D643 and open it up. There are two called Setup - triple check you've selected the one with the right GUID.
   
9. Confirm that you've opened the right item -- at the top it should report the Size to be 0x0631 bytes.
   
10. The byte to change is at offset 0xE; that's the first row, second from the right. It should read 00. Type 01 and press ENTER to finish editing. Double check the surrounding bytes are unmodified, with only 0xE being changed from 00 to 01.
    
11. Press CTRL+W to save, and ensure the RU tool doesn't display any error messages.
12. You can now unplug the USB thumb drive and power cycle your machine. Allow it to boot up in whichever OS you have installed.
13. For Linux installations, run dmesg | grep -i tpm to confirm that Linux can now see the TPM. You can also run tpm2_getrandom 20 to have the TPM generate random bytes for you; this is the simplest way to make the TPM actually do something and thereby confirm that it works.
14. For Windows installations, I'll leave it to someone else to provide validation steps.

So that's that -- you've directly, manually modified the same UEFI Variables that are modified by the BIOS UI on a normal day. This TPM setting will persist until the next time you do a BIOS update, when the RTC battery gets disconnected, or when you Restore Factory Defaults in the BIOS UI.

---------------------------------------------------------------------------------------------------------------------------

Discovery and Repro Steps

The steps below reveal both hidden BIOS UI menu items and the NVRAM storage locations of their values as human-readable EFI bytecode.

1. Download the UEFITool from LongSoft's github repo. You can compile it yourself from source if you want, but the pre-built binaries contain GUID->Text mappings that makes life easier later on in the process.
2. Download the Universal-IFR-Extractor from LongSoft's github repo. For Windows folks, it'd be easier to grab a pre-built binary, but for Linux folks it's easier to build it from source with g++ -I. -o ifr-extractor main-cli.cpp UEFI.cpp EFI.cpp.
3. Download whichever of the official ODROID BIOS ROMs, and extract the bios.bin file within.
4. Open UEFITool and load the bios.bin file.
5. Within the tool, search for the 899407D7-99FE-43D8-9A21-79EC328CAC21 File, select the PE32 image section section within it, right-click and Extract body. The screenshot below is from the GLK-SF 1.22 bios.bin file.
   
6. Close UEFITool, and run the IFR extractor to generate the output file. (eg. ifr-extractor setup.bin setup.ifr or whatever the name of your IFR's executable is).
7. Grab a coffee or a beer, and get ready to sit down and do some light reading of translated-for-humans EFI bytecode.
8. Search through the IFR file for Security Device Support. You'll notice there's a Suppress If True statement before it: anyone familiar with coding will recognise this as the classic if (0) {...} trick. No matter what, this BIOS UI menu item, and many others above and below, will never see the light of day.
9. Observe the VarStore and VarOffset for the Security Device Support menu item. On the GLK-SF 1.22 version VarStore is 0x1, and VarOffset is 0xE. The EFI bytecode breakdown also shows that Disabled is the default option and has Value 0x00, whilst Enabled has value 0x01. The Size for this menu item is only one byte, so we don't need to worry about endianness.

   Code: Select all

   One Of: Security Device Support, VarStoreInfo (VarOffset/VarName): 0xE, VarStore: 0x1, QuestionId: 0x22, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 91 75 04 97 04 22 00 01 00 0E 00 10 10 00 01 00}
           One Of Option: Disable, Value (8 bit): 0x0 (default) {09 07 7D 04 30 00 00}
           One Of Option: Enable, Value (8 bit): 0x1 {09 07 7C 04 00 00 01}
   End One Of {29 02}
   

10. The VarStore value isn't enough on its own though; UEFI Variables are stored as GUIDs, not as integers. Scroll up towards the top of the IFR dump and look for the VarStore mapping for 1 and note down the GUID. On GLK-SF 1.22 the GUID is EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 and is 0x631 bytes in size.

    Code: Select all

    VarStore: VarStoreId: 0x1 [EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9], Size: 0x631, Name: Setup {24 1C 43 D6 87 EC A4 EB B5 4B A1 E5 3F 3E 36 
    B2 0D A9 01 00 31 06 53 65 74 75 70 00}
    

11. Now we have the UEFI Variable GUID (EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9), the byte offset (0x000E), and the value to change it to (0x01).
12. At this point you can now refer to the first section above: open up the RU tool, navigate to UEFI Variables, and be on the lookout for the GUID that corresponds to your VarStore, skip to the offset given in VarOffset and change it to the desired value.
13. I've been able to successfully flip some other hidden menu items in this way (such as TPM Clear), but am not going to write a walk-through for each and every hidden menu item; I'd rather the see the ODROID folks reveal these benign and safe menu items.

If there's enough demand, I'll try out some other BIOS versions with this technique and confirm whether this works on versions other than 1.22.

Edit #1: Fixed up some formatting and grammar to make life easier for non-English readers.

[odroid]

Amazing! Thank you for very detail instruction.
This great article is "STICKY" now.

[mad_ady]

Indeed! Great explanation for what you've accomplished!

[InsideJob]

I guess if it gets enabled by default in a future BIOS update and there's still no menu option, this thread would also be the way to disable it again. Just change the boolean bit from true to false.

[domih]

Hey folks,

I have successfully enabled the firmware TPM (fTPM) within the J4105 on my ODROID-H2 (rev. B)...

I'm definitely impressed!

[564]

Thanks joshgoes for figuring this out and the comprehensive write-up!

If any ODROID staff are reading: I have no idea how much control you have over hiding/revealing items in the AMI/Aptio BIOS UI, but if you can, can you please reveal the Advanced > Trusted Computing menu?

Yes, a BIOS update for the H2 with this option visible would be very much appreciated.

[nemi]

Yes, a BIOS update for the H2 with this option visible would be very much appreciated.

Another vote for that.

[puremind]

Bump!

[marcel151]

I'm on 1.23, does it work with that BIOS version? Would like to install Windows 11 but also like to meet it's requirements.

EDIT: I was feeling lucky and gave it a try. I saw that the values under "Setup" looked a little bit different, but "0E" was still on "00" so I changed it to "01". After reboot it worked just fine. You can find the TPM 2.0 in Device Manager or in Windows PC Health Check for checking if the PC is Windows 11 compliant. Looks great (it's in german but you'll get the idea):

TPM.JPG (95.8 KiB) Viewed 11097 times

I also wanted to take a screenshot of the different looking values in RU.efi, but after looking again the values looked exactly the same like above.
Now I'll install Windows 11. Thank you so much! And @ODROID, you definitely should implement that in BIOS settings.

EDIT2: No surprise, Windows 11 was installed successfully with the official installer from a running Windows 10.

Win11 ODROID.png (77.76 KiB) Viewed 11085 times

[tmihai20]

The little oDroid that keeps on giving! I would love to have a BIOS with that option available.

[odroid]

We can't supply BIOS update anymore since the custom BIOS build license was expired.
You have to modify the BIOS by yourself as OP described. Sorry about that.

We couldn't extend the expensive license because we were not sure if we could make/sell the H2 models or not.
viewtopic.php?f=171&t=43333

[tmihai20]

Would it then be ok for someone to modify the BIOS and post it here? I am ok with using hex editors, but editing BIOS is a different thing. If I flash a messed up BIOS, can I do something to recover from it? I used to patch BIOS files a very long time ago, but I just added some parts, I never modified it internally. I am using my H2 with OpenMediaVault and it does not boot with UEFI. Or I would love for someone that already patched it to somehow provide it to me and others.

[mad_ady]

As far as I know the changes above are in the nvram which is not a part of the actual bios. And to change the bios you'd need to recompile it.

[tmihai20]

Would it then be ok for someone to modify the BIOS and post it here? I am ok with using hex editors, but editing BIOS is a different thing. If I flash a messed up BIOS, can I do something to recover from it? I used to patch BIOS files a very long time ago, but I just added some parts, I never modified it internally. I am using my H2 with OpenMediaVault and it does not boot with UEFI. Or I would love for someone that already patched it to somehow provide it to me and others.

You can still recover the corrupted BIOS with a cheap(<$4) flash programmer.
https://wiki.odroid.com/odroid-h2/hardw ... programmer

[joshgoes]

Would it then be ok for someone to modify the BIOS and post it here? I am ok with using hex editors, but editing BIOS is a different thing.

I tried patching the BIOS ROM itself before finally settling on the approach I posted above. Patching the BIOS ROM wasn't a suitable path since, at every reboot, it opens up the BIOS UI Recovery section (even when DEL isn't pressed)... not exactly useful for a headless server. I'm relatively confident that this was because the original BIOS ROM was signed by the OEM, and my patch violated the signature. Having said that, there are a few other steps that I did not attempt which would've confirmed this (such as cutting a new ROM within Intel Flash Image Tool with the OEM Public Key zeroed out, and rolling a new RSA2048 key and supplying that as the SMIP key within the FIT when cutting a new ROM).

We can't supply BIOS update anymore since the custom BIOS build license was expired.

@odroid -- When I look at the BIOS v1.23 ROM, it says that you're using Intel Flash Image Tool version 4.0.30.1392 to build it. Do you still have the same SMIP Signing Key available? (The one under Platform Protection -> Platform Integirty whose OEM Public Key Hash is 34 03 83 FB D2 D9 2A C6 45 1D 2E 6A B4 12 B5 A5 FC C9 B4 76 BC 49 6A 86 84 5F 77 F2 0D AA 9C 76). I'd be happy to supply a patched BIOS Region.bin for you to build a new BIOS ROM in Intel FIT, but I'm presuming it'd need to be built and signed using the same SMIP key as the previous ROMs, since the FIT tool says the OEM Public Key Hash has been burned into a field programmable fuse (FPF) and would therefore be permanent.

[odroid]

We can't access the build tool any more. Sorry about that.

[joshgoes]

We can't access the build tool any more. Sorry about that.

That's a shame. This implies that there will never be any more BIOS updates for the ODROID-H2/H2+ whatsoever... is that correct?

I have access to the Intel tools and have confirmed that although the BIOS image is signed by the Odroid/Hardkernel folks, the signing keys aren't actually set in the fuses (the FPFs). I also discovered that the TXE was never given the "end of manufacturing" signal, so it's still fully configurable (thank you!)... hopefully this is the case for every ODROID-H2/H2+ that has been shipped.

I'll tinker around over the next week or so to see if I can get a custom BIOS ROM loaded and working on my ODROID-H2 with all the BIOS options revealed. Still, I'd prefer folks to follow the original instructions since they're far less riskier than loading a custom ROM anyway.

[tmihai20]

I am pretty new to this and I thought that the changes were done to the actual BIOS. Reading up a little bit cleared that up. I just do not want to brick my H2, it is working as NAS for me and it is vital that it stays on.

[arthur99]

We can't supply BIOS update anymore since the custom BIOS build license was expired.
You have to modify the BIOS by yourself as OP described. Sorry about that.

We couldn't extend the expensive license because we were not sure if we could make/sell the H2 models or not.
viewtopic.php?f=171&t=43333

Does that really mean that you don't provide a single update for a device which I bought less than a year ago?

At least for security reasons (if you decline functional issues) this is expected for 2 years which is the defects liability period in Germany, and security issues are defects.

So today there are 2 major reasons for updates:
1. Unveil the BIOS switch to enable the TPM 2.0 module required for WIndows 11 (patch procedure can't be done by everyone, one said that it is not feasible for him because risk to brick)
2. Continue to supply security fixes for the Intel CSME which is essential (also the TPM is part of it)

You should really reconsider responsibility for your products for the whole life cycle. Such costs for a BIOS build license must be calculated as a cost factor for the prices, otherwise the devices soon get limited use or even turn into waste, dependent on the use case.

So what could you provide here? If you really can't afford the license costs for the BIOS tool, what would be the amount for servicing if I want to pay for it?


Kind regards,
Arthur


Results from the Intel detection tool:

Code: Select all

# ./intel_csme_version_detection_tool 
Intel(R) CSME Version Detection Tool
Copyright(C) 2017-2020, Intel Corporation, All rights reserved.

Application Version: 5.1.0.0
Scan date: 2021-11-01 09:37:07 GMT

*** Host Computer Information ***
Name: strix
Manufacturer: HARDKERNEL
Model: ODROID-H2
Processor Name: Intel(R) Celeron(R) J4115 CPU @ 1.80GHz
OS Version: Debian GNU/Linux 11 (bullseye) (5.10.0-9-amd64)

*** Intel(R) ME Information ***
Engine: Intel(R) Trusted Execution Engine
Version: 4.0.30.1386

*** Risk Assessment ***
Based on the analysis performed by this tool: This system is vulnerable.
Explanation:
  The detected version of the Intel(R) Trusted Execution Engine firmware
  has a vulnerability listed in one or more of the public Security Advisories.
  Contact your system manufacturer for support and remediation of this system.

For more information refer to the Intel(R) CSME Version Detection Tool User Guide
or the related Intel Security Advisory list at:
https://www.intel.com/content/www/us/en ... ogies.html

[arthur99]

We can't supply BIOS update anymore since the custom BIOS build license was expired.
You have to modify the BIOS by yourself as OP described. Sorry about that.

We couldn't extend the expensive license because we were not sure if we could make/sell the H2 models or not.
viewtopic.php?f=171&t=43333

I asked at ami.com for you whether they can make a special price for hardkernel.com.

I see your situation that you won't make more money with Intel based devices as this was the only product in this area, so this distinguishies you from many other manufacturers with a big portfolio on Intel platforms.

But on the other hand it is ridiculous that support suddenly stops after the last device being sold. Countries/regions as the European Union are on the way to strengthen legislation that software support for devices must be guaranteed for several years, and not because they want to bother manufacturers, but avoiding electronical waste by technically perfectly operational devices, but outdated and insecure firmware.

Not kidding!

arthur99

[InsideJob]

I wonder if there's a way to install https://www.coreboot.org/ on an H2+? Seems like that would be the cheapest route and they say it works with ARM boards too.

[martin00]

Awesome, many thanks for this walk-through. I tested this on 1.22, worked perfectly. Interestingly enough on 1.23 I can move around in RU, look at bunch of stuff. But when I hit the alt= (or select the menu config->UEFI variable) it gets frozen every time. I've 100% failure on getting to that menu. Tried to reset the BIOS settings, copy it again, unplugged devices, nothing. Tried even the beta 5.31.0410 but still nothing.

[odroid]

Since this workaround has some limitations, consider looking into How to Bypass Windows 11 TPM the Official Microsoft Way section in the following link if you don't mind.
https://www.tomshardware.com/how-to/byp ... equirement

[martin00]

Thanks for posting the link, I think it will be useful for other people who stumble onto this thread.

I'm not aiming for windows 11 but I was rather interested in the way it was enabled and what other stuff I can do. From quick look at the Jame's web page about RU it could be a security issue/obfuscation maybe triggering? I'll try to google around but I was wondering if somebody else already hit this issue as some time passed since the last post.

edit:
For others who may try this: on 1.23 I had 0 success of getting the list of EFI vars with RU. The highest version of RU right now is 5.31.0410. I downgraded back to 1.22 where I had success before, nothing. Tried several times with different versions, nothing. I went back to 1.12 and now I can get the list back again. It froze one of 5 times I tried. That randomness is weird, I thought maybe RU is stepping outside of memory it can but that randomness is a bit weird.

[rpimonitrbtch]

So.......... H3 coming soon, eh? Is it too much to hope for that you guys might have re-acquired the license to build updated BIOS's and there's a possibility of an official new release with these settings un-hidden? And, to be blunt... considering that a power-user-oriented device should have never had these settings hidden in the first place...

Well, I guess this was asked and answered in another thread... You guys need a better BIOS vendor.

[mad_ady]

I have the following naive question: would the H3's BIOS work on the H2, seeing that they are similar boards? Would this violate the contract with the BIOS vendor?

[domih]

I have the following naive question: would the H3's BIOS work on the H2, seeing that they are similar boards? Would this violate the contract with the BIOS vendor?

I believe it is a moot point. As they stated in the announcement "...and other key components that we can purchase much more reliably..." the components on the boards are different so I'm pretty sure the BIOSes are different too. Plus in the wiki (https://wiki.odroid.com/odroid-h3/hardw ... ios_update) they clearly state not to mix the H2+ and H3/H3+ BIOSes.

[tmihai20]

Nobody should mess up BIOS from H3 with H2+, those having the closest hardware. I am tempted to buy H3+ to get a better board and maybe sell my H2+. H3/H3+ seem to have better BIOS from the start and I like that.

[arthur99]

Dear ODROID developers,

Someone outlined how to edit firmware blobs to replace/update the Intel Management Engine firmware. For version 4.x (TXE) this guide needs to be followed:

[Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization
https://winraid.level1techs.com/t/intel ... ools/30730

The flashing process most probably is under control by you, although it is mentioned in another article, that there is no fwupdate.exe tool for this specific version of the management engine:

Intel (Converged Security) Trusted Execution Engine: Drivers, Firmware and Tools
https://winraid.level1techs.com/t/intel ... ools/30730

Would it be possible to provide an update (based on your latest BIOS release) to the current version 4.0.45 (with security fixes by Intel) using this method as alternative to the BIOS tools, where your license expired?

This could also be an option for the H3+ for the later time, when you expect also to not have access to the tools from the BIOS vendor. (Note: If later ME major version for H3+, fwupdate tools could likely be used, which is quite convenient – did this today for ME series 11.8 where another vendor stopped providing security updates, but after 4 years).

arthur99

[arthur99]

[/list]

[Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization
https://winraid.level1techs.com/t/intel ... ools/30730

The whole process of updating the ME firmware (need file 4.0.45.1848_B_PRD_RGN.bin) in the BIOS image worked well. Tooling is also available for Linux
In addition to the description one can also update the CPU microcode in file 'uCode Patch 2.bin'.

intel_csme_version_detection_tool

Engine: Intel(R) TXE
Version: 4.0.45.1848
Status: DISCOVERY_NOT_VULNERABLE_PATCHED

Alternately one could disable the Management Engine:

1. clone https://review.coreboot.org/coreboot.git
2. cd to directory util/ifdtool and build with

   Code: Select all

   make

3. generate patched image with HAP=1

   Code: Select all

   ifdtool -M 1 -p glk bios.bin

4. flash as usual, or quicker by extracting the first 4096 bytes of the image (let's assume as "bios_fd.bin") and

   Code: Select all

   Fpt.efi -desc -f bios_fd.bin

Remaining problem:
With manufacturing mode still enabled, updating and disabling Management Engine is convenient, but leaves the system insecure. See https://malware.news/t/intel-me-manufac ... 4251/23214

Need to figure out the best settings to keep reasonable ways for updating.

@odroid: Any recommendation? Did you ever try ending manufacturing mode and updating BIOS?

[3dfx]

Just wanted to let you know that I successful enabled TPM on BIOS 1.23 using RU version 5.28.0397.

[nelson77]

I successfully extracted the setup.ifr file and read the information very clearly, but I don't know how to edit the setup.bin file (specifically, I want to disable TPM). Can anyone help me understand more about this issue? I appreciate it!

[nelson77]

When I change the value to 01, an error occurs during startup.