Yesterday I acquired a Utech UT-W800 Windows 10 tablet with an Atom X5 Z 8350 CPU (64GB storage & 4GB RAM). All was working good until I went in the BIOS to check what was available as options. Machine was working fine until I did this and when I saved and exited the machine was dead and would not power on.
I have done some Googling and it seems that other people have reported the same and this BIOS’s in these Atom tablets are a bit flaky. I know the machine is running even if it appears dead as I took the back off and the CPU is warm to the touch. I dumped the original BIOS (attached) using an TL866 Plus. Figuring that the machine was OK until I went in the BIOS then I found another BIOS similar on a Chinese web forum, it wasn’t a Utech BIOS (they don’t seem to have a support page) and flashed that (after taking the backup as attached). So with that BIOS the machine starts (checked this a few times) up but there are artifacts on the display and there is also a boot OS choose of Android or Windows (my machine only has Windows 10). But anyway this proved to me that the BIOS is corrupted. I flashed the old BIOS (attached) back and the machine is dead again.
I checked around the net and this guy on the XDA forums says to search for this using UEFI Tool, MMTool and a Hex editor “StdDefaults proved to be a good marker for the BIOS configuration area (equivalent to the NVRAM in other / former motherboards)” so I am basically familiar with these tools as I did the Coffee Lake mod on a Z170 & Z270 Asus ROG board with 8700k and got those working fine. But I am not getting these instructions the guy is saying. From what I understand in the BIOS/SPI is an area which stores the NV ram settings and also there is a set of defaults and a backup which is created after a BIOS flash/update. From what I can understand certain parts of the BIOS (the NV Ram) need deleting and the defaults copying in their place.
Does anybody know what to do and can help me please, or give me some pointers and where to look and what to look for. Attached is the BIOS file which is the one which killed the machine, if what people say is correct then its only the NV ram part which needs setting to default values.
NVRAM is located in the 2 first volumes of the bios region
My first try would be leaving StdDefaults, MfgDefaults and GUID store untouched in both volumes, delete the things in between, and fill with FF so that next volume will have unchanged start- address (GUID store still at the end). Use HxD (or another hex editor) for deleteing/ filling and UEFItool 025 for changing the raw part ‘as is’. Only UEFItoolNE has the detailed look into NVRAM, in UEFItool 025 it’s a raw block, so be sure you extraxt and exchange at the same level.
Result could look like this, but again: that’s just an idea for trying…
Leave StdDefaults, MfgDefaults and GUID store untouched in both volumes, GUID store is built bottom up with last line corresponding to first GUID and always on fixed same position defining end of NVRAM volume. Delete the things in between, and fill with FF so that next volume will have unchanged start- address. GUID store still ending same address.
Since both NVRAM volumes have two entries with same GUID for each NVAR entry GUID store in both would have just one line which should be the last line before next volume or padding. 4599D26F-1A11-49B8-B91F-858745CFF824 <=> 6F D2 99 45 11 1A B8 49 B9 1F 85 87 45 CF F8 24
Only difference is that space between NVAR entries and GUID store is now empty and does not have old GUID store lines at the end.
Well, played a little with it in an Aptio IV bios. DOS and an older Linux don’t do anything to the NVRAM, Win10 1607 (legacy) writes tons of entries, but does create a new (second) NVRAM volume. Stock bios does just have 1x default for this board. So I replaced both NVRAM stores with a stock one with padding filled with old GUID store. Windows used now just one store (first one now), but added entries correctly to the GUIS store.
So I wouldn’t care too much… If you’re really concerned try dumping the bios with Intel MEtools, might be easier than programmer.
1) Normally AfuWin won’t overwrite NVRAM if you don’t check the corresponding boxes (if available) 2) Both files are identical (??) 3) It really doesn’t matter, this will be corrected automatically
What I meant: GUID store (for this type bios) should have just one line since both NVRAM has just 2 items which carry same GUID, the old entries should have been FFed for both NVRAM stores, meaning FF from 41FE10 to 41FFEF and from 43FE10 to 43FFEF
Result (on the left) should have ‘free space’ between NVRAM entries and store, not a ‘non-empty padding’.
But again: Don’t flash anything, this little error has alreadyl corrected itself!
Right I understood this time around. In the attached is the BIOS (UT-W800 Fixed NV Ram BIOS 3nd Try.bin) changed as per your last suggestion. Before I flashed it I dumped the BIOS (afuwin1.rom) using AFU as you can see quite a few NVAR entries are marked Invalid I then flashed the BIOS and rebooted and dumped it again (afuwin2.rom), most (not all) invalid items are marked properly now. My interpretation of what you are saying is that since that space is marked as padded the GUID cannot grow in size as it writes the NVAR entries, whereas if its marked as free space it can grow as it needs. Extracting the BIOS using AFU seems to create a 4mb images Vs 8mb using using the programmer. I think that is because AFU cannot read the ME, AFU seems to be able to program the 4mb portion of the 8mb image just fine but cannot program the ME region. Anyway thank you this seems to be much better and I have learning something today
Attached file is .7z you might need to change the file extension from .zip
No, that’s not correct. First NVRAM store wasn’t used and is unchanged from 1st try, second got a new GUID store starting writing from last (single correct) line up and non-empty padding got free space since all the old entries got overwritten, see picture. Bios itself doesn’t care what this area is named in UEFITool, it simply writes line after line up from last valif line of GUID store, it doesn’t care if there’s ‘FF’ or something else. Invalid entries in large amounts are quite usual in these stores.
OK great, I have looked at come other BIOS dumps (upgrade files) for other Atom X5 tablets, nearly the same spec as mine (Telcast X80), they usually have 1 NVRAM store, it seems that during flash update a second NVRAM store maybe be backed up, I think that’s why the original dump of mine showed 2 NVRAM stores.
Please can you confirm the attached is OK for use, I flashed it using AFUWin and it seems OK (what is attached is the dump I saved back out after the flash and reboot, it looks pretty close to the original.
Hey, I’m actually having a very similar issue, actually almost identical. I tried what you’ve outlined above, however get a black screen (with backlight on) and no post after replacing the two section with FFs and reflashing. I think I may be hitting code I’m not supposed to? USBs are back to working though with the edits.
