No, if the mainboard shouldn’t be able to boot off a special PCIe connected SSD by using the latest original BIOS. The UBU tool can only update already existing BIOS modules, but not insert missing ones. Regarding the procedure how to get a natively not supported PCIe or M.2 connected SSD bootable, please have a look into >this< resp. >this< thread. Good luck! Dieter (alias Fernando)
P.S.: I have moved your post into the correct UBU discussion thread (the other one is reserved just for the guide and the announcements of new/updated UBU versions).
UBU GUI 2.0.0.440 - Extract and display all EFI and OROM Intel/AMD SATA and Video (LAN and OROM Intel VBIOS is in development) - In Tab "CPU mCode" added mini hex calculator - Fixed a bunch of bugs on the GUID and DevID display. Test.
Edit: If anyone has a BIOS on the platform AMI Aptio 5 for AMD chipsets, please send the link.
@SoniX Just had an idea for the cli script version of UBU!! (Might even be possible with the GUI version in a slightly changed format.) Don’t know if it has been suggested before, so bare with me.
As i just had to find some specific info, for example, had to mod the script to get output logging. Also, sometimes i need additional possibilities or scripts i always have to run, after the bios is created. So i just got an idea! It might be a great addition to your already great tool.
Why not make the script “pluggable”. As in, have a designated folder available, e.g. plugs/scripts/addons/etc, where people can add scripts to.
Possible additional features could be;
- when scripts are found, there could be a new menu item, which shows the name of the script (without file-type) and a number to choose one.When one is chosen, show a description the user has added, which could be a separate file with the same name, e.g. migrate.bat(script) and an additional migrate.desc/.md/.nfo
- when scripts are found, you can choose one, like i suggested above. But instead of only being able to run it, users could be able to upload/submit/commit that specific script to a remote destination/repository.
- make a default set of pre-configured variables available (from within UBU), about the bios that is currently being worked on. But the variables could also contain pre-configured command syntax’s for the already bundled tools, maybe even being able to call them with additional arguments.
- have UBU listening for certain exit codes, as to how to react when the user-script has ended (reload, save&exit, scan for errors, etc)
- scripts starting with a number (have to be 2 digits, followed by an underscore e.g. 05_unzip.bat, 10_decrypt.bat, 20_choosebiosfromzip.bat). Those are auto-run at the start (and are not included in the menu), the order of processing would be based on the value of that number. The lower the numbers, the more preference it has over higher numbers.
- the UBU download zip might contain some templates, e.g. basic, advanced, expert. Or maybe just a header and a footer to have an easy start when creating a new script, but it makes “sure” the integration into UBU is proper and neat.
Probably a lot more possibilities, but these are the one i came up with and thought would have a big impact and be massively convenient. Most of the features would not even have to be added straight away. But this way all kind of idea’s users have, see the daylight (which we might have never thought about) and the tool grows with more (possible)functionality and thus grows in popularity. It also attracts more modders/developers which might speed up problem solving or difficulties that exist or might turn up with new bios’s in the future.
Anyways, thought it would be an awesome addition to the tool, while not being that difficult/extreme to implement, but it all depends on how you think about it! Hope you like the idea!
Very interesting addition! Thank you. Now we can compare BIOS releases to quickly detect where the changes occurred. Quickly tested by slightly altering the Intel FD:
@plutomaniac My pleasure. It was planned looong ago and was so easy to implement, that I just kept postponing it. Now the goal is to get rid of Qt for all console-based tools starting with UEFIExtract, as I only use ~10 classes from all the library, and it will really spare me a megabyte of EXE size and enable others to use UE in non-GPL environments.
I’m not sure if this is new. I remember some months/years ago of a firmware in which the 0.1 in the middle was a typo so maybe this is 1.0.0.0025 which is older in such case.
