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! :)

@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.

Zitat von lordkag im Beitrag #645

---

@SoniX

Yes, it works. I have checked with all the Intel GOPs I have. But the intriguing part is that ---if ((check[2] == 0x2E) || (check[2] == 0x00) || (check[10] != 0x00))--- always evaluates to true, isn't it?
Wouldn't ---if (check[12] == 0x00)--- be the better option? No need to change drvver again, since it already works. I'm just wondering.

@Fernando

Am I the only one who finds this message intriguing? I do hope I will be wrong and embarrassed by finding that the tool will be for personal use only or totally something else than UBU, because the alternative is unsettling.

Sure, MMTool is available for anyone to use, it has a list of commands, nothing secret about that. But UBU is more than a wrapper for MMTool. It was developed by Sonix (and maybe others? Maybe Coderush?), it was supported by the community, it was refined by feedback, hints and ideas. In a sentence, developed by Sonix, powered by community.
How can anyone release a competing product and complete as UBU, without copying UBU? It will be pretty hard to state that no code was borrowed, behind a closed source. And again, why should anyone take an open source project as UBU and turn it into a separate one? This will only force Sonix to lock his UBU and possibly remove it from win-raid.

I do hope I'm wrong, because otherwise I would think twice about being part of a community that approves this kind of treatment. Either this is a project that gets backed up by the forum/community (most desirable), or it is each on its own with his own ideas (less desirable). I would be disappointed to see the author of UEFI Download Tool going down this path. I offer you my apologies, if I should be proven wrong in my assumptions.

---

@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.

Zitat von lordkag im Beitrag #656

---

@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.

---

@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.

Zitat von lordkag im Beitrag #659

---

@SoniX
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.

---

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.