I chose BSD as license for my software because I wish that it becomes a base to other community members work, even if the derivative is chosen to be closed source. I have already seen some interesting forks like this (added ME region parsing) or this (Osmozis-related UEFI patcher).
Now I have an NDA with American Megatrends, Intel, AMD and other companies due to my new job, that is why I can’t write any AMI-specific things like OROM replacer, uCode editor and so on, but other community members aren’t bound by such NDAs and if someone could extend UEFITool to fully replace MMTool in UBU, or just writes completely new tool (no matter if it be closed source) to do it - I will be pleased.
What pleases me not is that instead of asking UBU developers about where they really need help and what things can be improved by skilled programmer, some people just say “I will write my own better solution (with blackjack and hookers, of course)”. We call this the NIH syndrome and it sometimes stings almost every software developer on this planet.
Anyway, all of you (or anyone else) are free to use my tools in any way you want (if your way of using them is compatible with BSD 
).
Code UBU this openness and simplicity, so everyone can see how it works and add something of their own. Support Utilities also open on GitHub.
What will come of this for another project, I do not know. But if people want to write, what is his, I do not mind. The main thing that it did not look complete plagiarism.
The only thing I would suggest, for starters, to organize support for AMD platforms.
I will continue to support UBU is open form in which it is now.
Good luck to everyone and do not swear! 
Off topic:
I personally cannot do it, because I never owned an AMD chipset mainboard and I don’t want to write about something without having any own experience.
@Fernando
Thank you for your position and statement. There should be no compromise when it comes to principles.
@SoniX
@CodeRush
While we are at this point, I hope you guys don’t feel the same about me uploading Extractor to this thread. I thought about adding a line like “Credits goes to Sonix and CodeRush for providing the largest and best part of the code”, but I never meant to release this as an official and standalone tool. It is just a helper tool, to find new modules quickly, in seconds, without doing everything manually. I’m not a programmer and I would hate that someone would associate my clumsiness with your names. By adding credits it would feel too official and separate from UBU, but if you feel uncomfortable with the current situation, it would be my pleasure to put your names in there. Like I said, this is just for helping you guys, not an actual tool.
About the AMD part, it will always be incomplete, because the way AMD was inserted the components. You can’t update their AGESA (MEI counterpart, I think), because it is compiled in source. You can’t update the microcodes with MMTool because they are part of AmdProcessorInitPeim.ffs. The RAID part is complicated because of MISC.BIN, which doesn’t always follows the rule <oldest in …-FC GUID and newest in …-FD GUID> and it is not easy to tell them apart. Then there are two EFI RAID drivers, RAIDx64 and RAID Utility, plus two more for FM2+ boards. The VBIOS and GOP part would feel easier to implement, but like you, I don’t have a newer UEFI compatible board. And I’m not a good coder, like I said.
@lordkag , no additional credits needed, we are all in the same boat here.
My opinion for this: do what you want and develop what you want, if it’s helpful - we will use it.
I’ve developed UBU helper utilities as a quick and dirty crap that just works. If someone is eager to replace them with a better solution - great, it means less maintenance work for me.
The only thing I wish that if you have a replacement for any part of UBU or the whole UBU at once - please explain why is it better then current one, nothing more.
I, for one, don’t see any need to replace UBU with something, even if it comes with a GUI. Not that I would know how to do it, but the current UBU is easy to inspect, easy to fix, easy to contribute. What I do is more of sharing the findings than actually coding. I’m actually more in the game of chasing those dirty sneaky bytes that build the structure and hide its secret, than actually writing anything worthy.
But back on track or not, since UEFITool is added in UBU, should bugs report be submitted here or by PM? I will use the PM this time, but it is better to know.
I completely understand what you are saying, i had no intention to delete or compete with other tool, all i wanted was a GUI interface that let you BIOS mod, MMTool was the source of all the operations, code was done in c# and not batch, code coping wouldn’t be easy because i had to make my own Functions to perform operations in different commands than batch has.
A GUI interface that show you all OROM versions installed and check for updates for them i thought would be really nice. It would automate the process and would allow for no Updates inside the code when we find new OROMs because they would be fetched from a server.
Again i am not trying to steal anything or destroy anything i just thought of a cool idea.
I would like to see this happen but i would not want to dem UBU as no purpose either.
I will stop development if i am doing something wrong.
All i want is to see is this idea expanded.
Edit: only reason i asked about MMTool is the command prompt and was even doing that way was because the c# library called the Processor class wouldn’t hide the MMTool window and redirect output to see error, it opens in a new window. CMD way it would open minimized instead. So what i did was use the c# processor class to open CMD with args to open mmtool minimized.
@SoniX
Realtek update.
LAN OROM v2.60
UEFI UNDI Driver v2.028
http://www.realtek.com.tw/downloads/down…3&GetDown=false
@GlitchyHack
You had a cool idea indeed, at least in theory. But in practice you would run into liability, usability, safety. For liability you would had needed to contact Sonix before starting the project. I know I heavily borrowed from Sonix and CodeRush, but I never planned to release a similar tool, in fact I never planned to release it at all. It was just a token of thanks for their work, something to help finding new modules. For usability you have the easiness of current UBU, where anyone can inspect, fix, without actually knowing the code or reading thousand of lines. And for safety you have the direct link between UBU and MMTool, without an exe interfering. That’s why I think that while a GUI is a nice thing, this is one of those cases where simplicity wins over complexity.
@SoniX
Marvell is working hard on complicating things. If you look at the BIOS 2.30 of Asrock Z77 OC Formula, you will see something peculiar. The 1B4B-9192 OROM is actually splitted and the MVRD part is moved into 392BAFCF-ED17-42E9-9EF0-B9F0F23A44DF, while MVUI is moved into 32516D49-D216-4A89-A6BD-0C388F936A79. I say this is Marvell doing it, because I saw the same thing in an Asus BIOS (can’t find it, unfortunately), where MVRD is in 1179BB2B-0DD4-4E1E-832A-7CF45E376ED3 and 697BD5DF-F5BA-4088-B910-02360C2B4C2E, while MVUI is in 3DEE2CE9-742F-4700-A645-0AEE7F899DBF and 977BE327-2B9F-419F-9382-4B21323A1267.
This only happens with 1.0.0.0026 version of 9192, the rest seem to be in one piece. There are two ways to fix this: either just update to newest 1.0.00034 OROM, which gets loaded with MVRD and MVUI and the rest gets ignored - current situation, nothing to change; or you add those GUID to the list of updates, by taking MVRD and MVUI from latest 1.0.0.0034. Since Z77 OC Formula has 9172 controller, I would say to hold until you find more examples.
In order to check this, just search MVUI or MVRD outside CSMCORE.
@lordkag
Yeah, I noticed.
Strangely, nobody has complained about the non-working result updates OROM 9192/91a2
Edit:
Ooos! Sorry. Not properly caught on.
Now look again and realized you’re talking about. Originally OROM module 9192 is as MVUI without MVRD. A updated MVUI + MVRD. Were still in my same version, not only 1.0.0.0026, without MVRD.
I agree, I’ll pursue with my own project I’ve been doing the whole time which is checking for new uefi updates with my UEFI Download Tool I created. If I wish to do someethingg more with BIOS modding I would help Sonix with his tool. Every ones idea deservers to rremmain there and not have it replaced. My only intention throughout the whole idea was to make it easier for people using my tool who bios mod so they directly download a update and it gets automatically modded for them if they chose to. Never to take away something from anyone. We’ll all code our project idea we do best, if anyone wants anythhingg better they can request it or maybe help with it, instead off saying we could do it our own way.
But if Sonix would allow me to use his work in my program to auto mod in the background I would give thanks in the about and be grateful.
But for that to work I would need Sonix to make a auto function that updates all ROMs inside file.
It would bee awesome and we can help reach other makes things better.
@SoniX
Actually, that’s a different thing. You see, this is one of those cases where one OROM is duplicated, in the sense that it has the same PCIR and the same link for MMTool. In this case, all three Marvell OROMs have a duplicated part, totaling to 6 Marvell OROMs and only 3 usable and updatable. Since they are the same in PCIR, Link, version (I have seen cases where Intel Lan PXE is doubled, but with a different version), this is most likely a bug. The user should just remove one OROM of each link, because MMTool will always replace the first finding, leaving the duplicate alone.
The other case I was mentioning is that this 1.0.0.0026 OROM is splitted. The normal 9192 OROM is comprised of RAID + MVRD + MVUI. Version newer than 1.0.0.0026 have all three parts, each with its checksum. This 1.0.0.0026 version is splitted as - RAID in CSMCORE, MVRD and MVUI in ffs-GUID. But since this is just the second or third case I am seeing this and the board actually has a 9172 controller, we are just at the talking table.
If you want to be totally safe, you can add the GUIDs I mentioned earlier to the update list with latest MVRD/MVUI 1.0.0.0034, I can prepare them if you want. But without an user confirming it it works, if it is needed or not, this is not an urgent task.
@lordkag
Ahh … Now understand.
Another question. For tests where the user take appropriate motherboard is?? Wishing recently test same or different modules, hard to find.
I think if the user is ready for tests, then it is possible to assemble modules.
Hello lordkag! Here i am ready to test things for you and SoniX… 
As said before i’m an IT technician and i work in a lab that repair/refurb HW and one of my PCs is based on the ASRock Z77 OC Formula.
Cheers,
KK
Edit: OK, as wrote by lordkag in the post at the bottom of mine, i can’t help in testing Marvell controller… 
It might not be easy to test this. By reading the specs, ASRock Z77 OC Formula has a 9172 controller, which is not affected by this. To proper test this, two things are required:
1. User has a board with 9192 or 91A2 controller.
2. BIOS has MVRD and MVUI separated from main OROM and located in ffs.
2b. User should have spare HDD/SSD to test RAID on Marvell ports.
With the current UBU, OROM 9192 has RAID + MVRD + MVUI, so it could be a problem of incompatibility (or might not) when old MVRD/MVUI is separated from CSMCORE.
For start, we should gather a list of boards that have 9192/91A2 controller and check where MVRD+MVUI is located.
Hello guys
I currently have this mobo @ http://www.asus.com/vn/Motherboards/P8H6…S/HelpDesk_CPU/
Asus P8H61M-PLUS which doesn’t support Ivy CPU(such as G2030…etc),i’m running I3 2120 (Sandy CPU) on this mobo now.I wanna run G2030 and the other Ivy CPUs on this mobo (Ofcourse there is no new bios that supports Ivy CPU on Asus website 
)
I found this topic on google and following your guide,but i stuck at this step
Please help me,thank you so much !
By the way,when i open CPU Patch in MMTool,it keeps crashing like this
@ ronaldinho_07:
Welcome at Win-RAID Forum and thanks for your report!
I hope, that someone is able to help you.
Regards
Fernando
thank Fer 
When i choose option 2 (Update cpu microcode…for Sandy Overclocker)…the tool works
But when i put G2030 cpu on the motherboard,it still can not run 
what should i do next ? I’ve flashed the modified bios into the motherboard
@ ronaldinho_07
Installation microcode does not solve the problem. Your motherboard is not initially supported processors Ivy Bridge.
what will happen when i insert a new ROM (from an other mobo that supports Ivy) into this mobo ?