Weird Bios won't update any more

Posts: 67
Joined: Wed Aug 29, 2012 12:18 am

Re: Weird Bios won't update any more

Post by emurach »

So want is needed is a UEFI shell tool that flags the UEFI to do the reclaim function now on the EFI Variable Storage area.

Now the "BIOS Engineer" should be call PHOENIX on the phone for the special little EFI application here. After all Compulab is the ODM/OEM .
They will not talk to the end customer. Only the ODM/OEM.

This web page is 100% relevant in my view to the EVSA exhaust issue. ... 9563175323

Wow he's even in Taiwan.

In this write-up "ToolB.efi" was used to force the reclaim function to engage using Fault Tolerant Write Protocol. Thus, writing the only most Current version variables to the backup area. Then setting the Primary EVSA area to all 1's then coping only the current version variables back to the primary area. They then occupy a minimum amount of space. Housekeeping.

And bingo the the EVSA area would be cleaned up. Thus ESVA error should be gone and the Firmware updating would then go thru.

Only issue with the article is that it does not tell where he got the "ToolB.efi" app from? Now I'm looking all over the net for it with no luck so far trying to find it.

Again it be way simpler for the BIOS ENGINEER to contact PHONENIX for such an APP and FIT-PC to post it on the website. Hell maybe PHOENIX is the source of the "ToolB.EFI" app in first place.

It just simple tool you run from shell64.

Posts: 67
Joined: Wed Aug 29, 2012 12:18 am

Re: Weird Bios won't update any more

Post by emurach »

Seems Fit-PCs, "UEFI Engineer" still hasn't contacted "Phoenix Engineer" for me. That small app to directly perform or directly engage the builtin variable reclaim function from the command shell prompt would really be the ticket here.

I've still not be able to find "ToolB.efi" on the www that "Count Chu" was using in 2014 that did this.

I did notice Insyde had "H20ITB" in 2014. That Toolbox was documented to test the reclaim function. I think that would do it. But I haven't found a copy of that on web either.

Now Matthew Garrett talked about the reclaim function on the www. He did not write a app but said Linux should now do that on boot and another reference state that function should have made in to the 3.9.7 Kernel. I tried the latest Ubuntu 18.04 daily build. That was a no go. But was that a 3.9.7 kernel? Or does it even try a reclaim operation if running it from LiveCD?

I really don't what to do an RMA here. That is a shipping cost both ways, taxes (?Vat), plus $80 and month without the pc. Not to mention in your policy, You might scrap it to without returning it to me too. Which is a wrong policy in my book. I own it after all.

I really do need the simple software tool that engages the reclaim function to get out of this funk and avoid all that.

I do wish I could talk directly to Phoenix here. This should have been a shell command line option from the start. There should have been a reclaim command. Plus, I see big flaw in this whole capsule loading process. The /cvar option is never going to engage if the capsule doesn't load in the first place. The flow charts I saw on the web clearly show that.

Now you can do a "/patch /cvar" that does in engage. You see the progress bar progress as it writes 750 bytes. But the EVSA is still out of space at the end of that. Leading me to believe /cvar clears the variables (It did do that.) but it did nothing to reclaim deleted space.

Again, DosFlash and ShellFlash64.efi are just plain stupid in a basic sense. Because, it does not have a "DosFlash.exe /reclaim" or "Shellflash64.efi /reclaim" option that runs all by itself to fix this issue should it be encountered. Yet it can detect and give an error that your EVSA out of space. Just Stupid.

If I'm learning anything here, Phoenix Tiano SecureCore 2.2 is flawed.
Clearly, I should spec some other vendors Bios on my next purchase.

Seems now, I be reluctant to purchase any machine that
1/ soldered the bios chip to the board without a socket.
(What was done here) (With a socket you sale and ship them to
me on postage stamp)
2/ Place the bios chip where the customer could not get to it.
(That was done here. Between to chassis and top of the board???)
3/ Place a WinBond SPI flash chip on the board without a header for external SPI flashing. (Come on. An SPI programmer like $40)
4/ I would have to mandate that an external flashing method be present for customer if the all else fails. UEFI Tiano Core clearly does not have that. If it does, I haven't found a reference to it. It wants to load the capsule in, That's not the same thing as external flash.

A Mini USB port with IFTP binary push ability would have been nice. Use any other pc to push the full firmware back in to the chip should all else fail.

Post Reply

Return to “Intense PC BIOS”