[ARCHIVE] Outdated UBU Tool related Questions, Reports and Suggestions

@lfb6
In general, it is necessary to make some changes in the UEFIIExtract, but so far there is no time for this, as it is necessary to deal with UEFITool NE.
With the update of all file EFI and OROM, too, will not work, since there is no free space in the BIOS.

Thansk a lot! I was just surprised that Fujitsu delivered a new bios for this board with latest microcode and ME and wanted to check the other versions (Efi/orom), too. I don’t use this board at the moment. Decided to mention it since I wasn’t sure if this error was correlated to this special bios or might be of interest for others, too.

Each manufacturer makes its BIOS as it sees fit.
Over time, it will be possible to solve this situation.

@SoniX
it can’t delete from mmtool because is efi bios and it’s located in csmcore

@pipes80
Check it out. Replaced VBIOS, LAN Marvell-Yukon and SATA Marvell. Removed LAN Intel.
Mod without IRST and Microcodes/

Edit:
Attach removed

@SoniX thanks for help, maybe if you learn how have u delete intel lan orom?
I have add irst rom 12.9.0.2006 and work fine, have create a rqaid with 2 ssd (kingston and viperteq disks)
thx a lot for ur support


So is there a possibility to delete it even if it is not read in the list, just selecting the PCI dev?
U have use 4.50 mmtool version?

I have already deleted this OROM.
MMT 5.0.0.7

Why don’t work that version?

@SoniX
I have tried last UBU v1.70 RC14 on ASUS Sabertooth X99, and do report this abnomaly when select Realtek EFI UNDI from v2.045 to v2.046 update (Option 2 selected):

Realtek_EFI_problem.PNG


A message said ‘File Replaced’, however the version does remain to v2.045
Is it normal ?

Ehe…

@100PIER ,
Got the same bug on v1.70 RC14, but with the Intel OROM modules v1.5.86 that stays at v1.5.62 (I’m still using MMTool v5.0.0.7). I noticed that it says v1.5.86 but I see in folder v1.5.62.

Capture.JPG



and inside folder:

Capture0.JPG



PS: no prob for me with Realtek

@100PIER
I do not know why you have it. I checked and everything is fine with me.

scr1.jpg



@N6O7
This is not a bug. Installed version compatible with Devuce ID 0x1502. And you installed a version that does not support this Device ID.

@SoniX ,

Thank you for clarifying it to me, wasn’t sure what it said.

@N6O7

You can even delete this OROM. He is not needed, only takes place.

@Sonix
I do observe you tested on the same BIOS v3902 on your Sabertooth X99 machine like me.
I don’t understand why RTK update is not working.
So, do you use like me MMTool v5.2.0.24 or another version ?


MMTool is used only to replace microcodes with Aptio4/5 and OROM with Aptio4, The rest of the console versions UEFITool work.

Most likely, my opinion, at some point, the "\TMPR" temporary folder was not deleted. Because of this, UEFIExtract could not extract the updated file.
Try again.

@SoniX
Thanks for the explanation.

I do see a “\TMPR” temporary subfolder is created under UBU folder, just after UBU Tool is started.

I have replayed UBU tool a second time using the previous ‘modded’ BIOS file where the abnomaly was detected, and mysteriously the reported ‘no’ modification was in fact ‘done’ in the first try:

Realtek_EFI_problem_solved_after_twice_UBU_start.PNG



So, it does seem a bug somewhere because I don’t see any reason to run twice UBU Tool to get modded items properly displayed.

@100PIER

Thank you…

In the main menu there is an option:
RS - Re-Scanning
which allows you to rescan the file BIOS and clear the temporary folder without restarting UBU.

Your case will need to be watched, but I will add the control of the “TMPR” temporary folder. I’m sure the problem was due to her.
Because UEFIExtract can not extract to a file in a specific folder if it already exists.

@SoniX

Thanks for your help.

I have replayed the "Network, Realtek" scenario but using one old modded BIOS version (this one is currently running well into my PC).
This modded BIOS was build in July 2018 (so, the current UBU Tool v1.70 RC14 was not used at this periode of time).

Here are the steps:
Step_1:

Capture1.PNG

Step_2:

Capture2.PNG



Step_3:

Capture3.PNG

Step_4:

Capture4.PNG



Final Step:

Capture5.PNG



So, it does appear the Realtek modding is OK and this new modded BIOS is fine to be flashed.

I have no logical explanation why in a previous scenario the ‘non updated’ Realtek EFI display problem did occur.
Is there somewhere a programming initialisation problem that does explain sometimes ‘a pure display problem’ does occur, and sometimes does not ?

I do suspect only a ‘pure display’ minor problem because the modding was effectively done, but displayed incorrectly as ‘not done’ as reported in scenario of my Post#4431.

By the way the “TMPR” sub folder does not exist, it is named “TMP” instead of “TMPR”.
Is it OK ?