How exactly? What has been reset? Something that could still be added by end-users to a text file (which has the audacity of being called a DB - MEA.dat) via the -pdb parameter? Something which is a meaningless string of characters, without something to back it up? Here, this is new, let’s add it to the text file:
19.66.32.1999_SUPER_LP_H_UFS_PRE_EXTR_B5CB45BA2149E38D8824C997F38F295986D495CAA490A7B9446DAF6DF19E626C
It’s fake, of course, but most importantly, useless. It doesn’t mean anything, unless it can be backed up by some repository, some RE on how it can be parsed, how it can be updated, what makes it different that others, which fields are important etc. Collecting a blob is good, it is needed, but it’s 1% of the work that goes into building something like MEA or UEFITool.
You don’t lose anything by not seeing an assortment of strings in a text file. You lose everything when there is no longer a process to determine how to generate that vastly simplified representation of something much more complex. You lose everything when there is a single point of failure in an entire project. There could be 1000 people collecting stuff, and that’s admirable, that’s awesome. But if the other 99% is in the hands of one person, well, the writing is on the wall. To be clear, this is not a complaint. That is the way of certain things, understandable. But doing a 360 and accusing the one person doing 99% of the work that they’re blocking others, is not cool. I’ll be frank, if someone really wanted to contribute (in the parts which matter the most), it would have been done in the last 8 years. By creating guides, by doing research on the firmware files itself, by investigating how to use FIT to build images for people to update, by properly organizing firmware in repos with pre-defined semantics, by <insert 100 other things here >.
lfb6 caught on to something in his reply. Something correct. By deprecating ADP, indeed I don’t have to add a few lines of characters into a text file, occasionally. That means nothing really, it is just a line of text. You could add a poem there and MEA would happily work. Adding new lines, without doing the rest of the work, is meaningless. It just wastes time without offering something in return.
I’ve also noticed some confusion on what “unsupported” means. As I said, the exact same processes that MEA used before to detect ADP, they are still there. The only thing that changed on that regard is that it will no longer show the “not in DB” message. It will simply not check. But, if you want that, it that adds some value to you, by all means, remove that single “not is_unsupported” statement and you’re golden:
You’d be surprised to see what goes behind the scenes to show at a pretty table the simple lines “SKU: Consumer LP” or “Chipset: ICP-LP D”. You would need to parse different partitions (FTPR or RBEP, MFS, FITC), analyze them (basically “unpack” them but without output), process embedded files (MFS) or metadata (FTPR), combine fields from multiple CSE Extensions (one to get CON, COR, SLM - another for H, LP - another for ICP-LP - another for stepping D via the MFS) etc etc. Just for the simple “Consumer”, “Corporate” etc, Intel must have changed the extension which produces that result at least 5 times since CSME 11. Every time I had to figure out, which of the conflicting extension do I trust for this or that specific generation? It looks simple when someone runs MEA, and that was the intention of course, but not reality.
Something as simple as the firmware version requires prior parsing on a full partition, its manifest and its metadata extensions. A single extension may be altered by Intel, a field is now a dword instead of word, the modules are now shorter etc and MEA may end up crashing due to unexpected input. Not because of bad practices, mainly because you’re constantly reacting to the changes that an entire company is making to a very complex and varied piece of HW/FW combo. And whenever something changes, you need to do research and mostly reverse engineering to figure out what changed, why, how does it impact new/old stuff, how can it be automated, which value to trust etc.
For ADP, that was exactly the case. There are comments in MEA which say “TODO: Parse that for ADP” or “TODO: This needs to be taken from RBEP and not FTPR for this generation”. Some basic support was added, but then never continued. You can see this at the ADP H firmware, the Chipset is “Unknown”. Why? Intel removed the MFS > 6 > mphytbl file I was using for that for years, no idea where that info went. Never looked further.
Anyway, I believe that by keeping the existing code for ADP, the “hybrid” approach is there already. It simply does not nag me/us to add something to the DB anymore. And as I explained above, someone interested enough, can modify that behavior very easily and also keep adding stuff to the database, if they desire. That is not a problem for me. And besides, it’s not like MEA gets trully updated anymore. The last update was 1y ago or something and this one was primarily to fix the broken json output and clearly define what is supported and what’s not.
, which re-writes the ugly and (most importantly) broken JSON output it had before. As I had promised, I will maintain supported features and JSON was supported but, honestly, completely broken.
