@Phoenix48 ,
The interesting thing is his microcodes exist as separate files according to UefiTool NE47, but using UefiTool 22.4 and Phoenix Tool they exist inside a PAD file. Then theres the problem that there is no FIT table. I read that isn’t always that important as long as the microcode is aligned properly in the last 2mb of the bios file. The problem is this PAD file also has other stuff trailing the microcodes. So you could extend the length of the PAD file and use Phoenixtool Structure option to replace that PAD_1881 file. Can’t say if it would work safely but PhoenixTool is the only tool that doesn’t say ‘Unknown File Structure’ like UefiTool does. Personally I would wait for @CodeRush to comment. Please forgive me for calling out the master but we do not want to see Dexter holding a brick in his hand!
Edit:
These are the exact errors UefiTool is complaining about:
parseVolume: unknown file system FFF12B8D-7696-4C8B-A985-2747075B4F50
parseVolume: unknown file system 00504624-8A59-4EEB-BD0F-6B36E96128E0
parseBios: volume size stored in header 20000h differs from calculated using block map 196608h
parseBios: one of volumes inside overlaps the end of data
The unknown filesystem doesn’t bother me as much as the volume size issue and overlapping issue.
I Worked and studied hard, may you have a look inside?
Thank you! Hope is ok
Bioses.zip (3.73 MB)
Microcodes.zip (84.7 KB)
Maybe, that Dexter insert the new one, but not overwrite it exactly.
One the other hand I see big problem in his pictures.
Dexter, you maybe insert the wrong MC. The old one has platform 23, the new platform 29.
This could be a vrey big problem …
no 23 is the patch level…29 is the updated one, must be different the only difference is the size:
old: 0x2400
new: 0x2800
Fine, thank you.
Now, there is still the question, how do you compensated the oversize.
I would had watched for 400h space, that could be dangerless to delete (maybe 00s or FFs).
Then you have to actualize the checksum in that way.
Best regards & good night!
Theres another way. He only updates his microcode over writing the next one in the Pad file preferably the last one and blanking out the leftover bytes with 'FF’s keeping the file size the same. Only draw back is it would be one microcode short but I think its the safest way.
I proceeded like this:
- I have established that in the original bios the old microcodes starts from 3500F8 and ends in 35ACF7
- From 35ACF8 to 36130B the values are all setted to FF.
- The new microcodes are longer than the old ones, I have selected them all and copied them in the bios patched from 3500F8 to 35B0F7 overwriting the old microcodes, so the excess length from 35ACF8 to 35B0F7 has not overwritten useful sectors but only sectors setted to FF, so in theory I should not have done any damage
The only thing that leaves me baffled and that UEFITOOL with the bios patched gives checksum error "parseFile: invalid data checksum A6H, should be 14H, how can I correct the checksum in 14h?
and how do I do the rebuild with uefitool precisely? Explain it to a beginner! What is a padfile?
Thank you!
I checked a modded bios with updated microcodes and are as long as those of the original bios !!! How is it possible that I can get longer?
I would use Phoenixtool. Your microcode files exist as a pad file that Phoenixtool dumps out in its DUMP folder. Make it longer and see what happens if you want. Just use the Structure option to do the replacing of the module.
@Dexter1983
To fix this, double click on the error at the bottom. UEFITool will automaticly select the GUID of the error. All you have to do after that is to right click on the GUID and click "Rebuild". then save your file. When you open it again, you will see that the error is gone.
I tried, believe me, you want to try it too so maybe you know what am I wrong?
A19PATCHED.zip (1.87 MB)
You are right. I tried to rebuild the bios and it didn’t worked, it produce this error:
reconstructRegion: reconstructed region size 3D1C45h (4004933) is smaller then original 421000h (4329472)
UEFITool don’t even want to save the file.
I am sure it is a good idea and i am pretty sure it should have a good chance of working but i downloaded the latest Phoenixtool 2.73 and quickly realised that i would need some practice in using it before being sure to use it the right way without error. I am just not comfortable to make modifications in the bios with this tool that will be used in the PC of an other person without more comprehension of how this tool work exactly. There are already enough errors in this bios without me creating an other without me realising it.
v2.67
ADD: SLIC 2.4 recognition
FIX: Failed to identify correct Dell header type
FIX: Some Dell headers have invalid size
v2.70
ADD: Support for DELL PFS headers
ADD: High DPI support (requires .NET 4.7)
FIX: Header parsing bug
FIX: Some improvements to dynamic resizing code (to make changed modules same size)
FIX: Updated 7zip components
v2.71
FIX: Fixed window scaling
FIX: Further changes to dynamic resizing code
v2.72
FIX: Parse RW reports that don’t contain an RSDT table
FIX: New key.txt for new module mods (from https://forums.mydigitallife.net/threads…04#post-1001236)
FIX: Scroll bars in very small resolution screens
FIX: Default header checksum changed from AAh for all to 5Ah for v1 FV.
v2.73
ADD: Support for old Dell BIOSes that don’t have any header structure, just modules.
FIX: Header scanning bug that led to ‘beyond end of FV’ and ‘additional data’ errors in the log
FIX: Couple of label adjustments in GUI since main form made smaller
Hey guys,
I found CBROM ver 399 if anyone wants a copy: http://www.mediafire.com/file/fmyc6b783006774/CBROM399.7z
Didn’t think it went that high in version number levels!
Hey david,
it’s CBROM v1.99 from 2010 inside - a special patched Version of CBROM v1.98.
Maybe from SoniX or another BIOS Tech.
But it’s not the same size & different checksum.
Original: 217.088 Bytes | CRC32: 11F807A4
Yourfile: 77.312 Bytes | CRC32: F89BC0D8
Keep away & be aware, it would be better to use the CBROM199 from this forum here or another serious source.
regards, MiMo
actually the error that worries me is that of the checksum because even the original bios returns some errors, so I do not care. The problem is that the microcodes for my cpu (core i7 2820qm) are longer than the old ones and creates a mismatch of checksum calculation, I should correct this calculation to the right value but I do not know how to do, if the new codes had the same length to the old ones now I would have already finished …
As soon as I resolve I write a detailed guide for all those with my same issues.
Hello Phoenix48, can give me the link to the new Phoenixtool 2.73, please.
I have it. 
regards, MiMo
I think you have a good idea to do a guide for Dell bios because it seems to be one of the rare things that is still missing in this forum.