Please find enclosed the files in .ffs.
H11DSi_BIOS.zip (339 KB)
Thanks, I will check. Did you already start looking in them? If yes, did you see anything promising yet?
Yes I tried to have a look at them but honestly I think I have reached my limits of competence. I have never done that before… I actually do not know what to look for. To me this error is very strange because the BIOS works fine, it is only AMIBCP that has problems reading it.
**** EDIT
So I have maybe something to start with.
I removed all the faulty files from the BIOS exept "HddSmart", the error was thus still there but only due to one file. Then, I erased different parts of "HddSmart" and replaced it in the modified BIOS until the error disappeared. It turns out that deleting the line at the offset 000053E0 solves the problem. Is this somehow helpfull?
Second EDIT ****
It seems that all the faulty files (except AMITSE) contain this series of bytes "00 48 00 49 00 49 00", which is not present in some "working" files that I have randomly picked.
Finally I also found the faulty sequence in AMITSE, it is located at the offset 0002A0B0, the sequence is :"F2 BC 65 CA E9 F9 BE 86 9E 1D 1C 61 91 FC 6F 09 A1 98 83 9E".
Replacing all the faulty sequences by 00 allows to open the BIOS without error. However doing so leaves "setup configuration" totally empty…
I thought you said it was above your pay grade? 
So, you got it figure out, somewhat? AMITSE is the setup menu text file, well some of it, I would not modify this one until you’re sure you’ve found the problem in some other file first.
It would be great if we could get an IFR output from Amitse, but no dice. Universal IFR extractor might help you figure this out.
All your looking for here is a language name, which I assume would be English since that is the only language in this BIOS, and assumed maybe it was spelled wrong or something.
Even if it’s not English, it should only be some word longer than 8 characters since that is the rule it’s violating, probably they did on purpose so hinder editing, expecting this exact outcome but not expecting group like us to try and find and fix 
I do bet it’s English though, since it says Language name is violating this, not setting entry or setting name etc.
I will look tonight and this weekend
Yes, you are right, all the files contain the lines ".en-US…E.n.g.l.i.s.h…", but I do not see what is wrong with this…
I think that is OK too, only mentioned English because the error itself says Lanuguage name, but maybe that is wrong/misleading.
At first glance I noticed this in smallest file hddmsart, then looked in next few larger files and found the same. Since this is saved location from originating HDD I think, changing to “test” or some other name under 8 digits should be OK
UVWATAUAVAWH (12) - 55 56 57 41 54 41 55 41 56 41 57 48 - In hddsmart
VWATAUAVH (9) - 56 57 41 54 41 55 41 56 48
WATAVH (6)
word is there many times, sometimes little shorter, looks like a “file location path” on the builders HDD
I think this may be his name, or the main folder name, where the issue starts, other folders based on this named variant on all files
Either 9 or 12 above would be an issue to AMIBCP, if this is what it’s complaining about.
It looks like “UVWATAUAVAWH” and its derivatives are something rather common, I am not sure that this is responsible for the error here…
http://www.hexacorn.com/blog/2013/05/16/…e-pushy-string/
I think that I have identified the faulty sequences because removing them fixes the error, however I do not understand what they are doing.
Btw, could you get usefull infomation with Universal IFR extractor ?
Good find, I didn’t even think to look around about that, just assumed. I guess due to that, this is probably not it at all then! 
What you mention may only be fixing the error because it’s breaking the module, thus no setup tab loaded. You’re only looking for some name longer than 8 characters, is everything OK if you FF the last three digits from sequence in post #24 >> remove these 98 83 9E
I think some files I looked at IFR output, but most were only the 1kb blanks 
Yes, it is difficult to understand what is actually hapening when the lines are removed…
Replacing the last three digits of the sequence in AMITSE by "FF" solves the error (the other files must however be corected). Nevertheless, the folders in "setup configuration" appear without any name, i.e. it is like erasing the entire sequence.
The IFR of "setup" gives a longer file, but I did not find anyting usefull … I attach the file to the post.
Setup_PE32_IFR.txt (314 KB)
Yes, I know setup gives good IFR, but that is not one of the problem modules, so I never looked at it much. Your tests seems like AMITSE might be main/only issue then, that is mostly text setup file. If you make the change there only, it breaks setup tab still in AMIBCP?
Changing only AMITSE does not work, all the files must be either removed or "corrected" (setup is one of them). The test I made was with the other files "corrected" (I change the sequence 00 48 00 49 00 49 to 00 48 00 49 00 00)
So which is it, that sequence or the one I mentioned removing the last three digits from? That sequence above is only 5 digits (Unicode), so shouldn’t be an issue since it’s not longer than 8 digits.
I think that things are a bit confused. Let me summarise what is known on the problem.
The ROM of all the Supermicro motherboards of the series H11-xxx cannot be opened with AMIBCP v 4.53 or higher, the error message being "Language name present in the ROM file exceeds 0x08 in lenght. Setup tab and BIOS String tab will not be shown."
Inspection of the ROM with UEFITool has shown that all the following files are somehow responsible for the error.
- Setup
- ServerMgmtSetup
- ReFlash
- EventLogsSetupPage
- HDDSmart
- FboGroupForm
- AMITSE
The sequence "00 48 00 49 00 49" is present in the first six files, while the sequence "F2 BC 65 CA E9 F9 BE 86 9E 1D 1C 61 91 FC 6F 09 A1 98 83 9E" is present only in AMITSE. All the sequences must be either removed or corrected (or the files removed) in order for AMIBCP to be able to open the ROM with "Setup configuration" and "BIOS String" avaible.
When the sequence in AMITSE is altered, no matter how (for instance by removing the last three digits), all the folders in "Setup configuration" are nameless. When the whole module AMITSE is removed from the ROM two of the folders in "Setup configuration" are normal, "AMD CBS" and "SATA Information", the other ones are however nameless. (The tests on AMITSE must however be done with the other six files "corrected", otherwise AMIBCP will not open the ROM.)
What is strange to me is that changing the last digits of the sequence in AMITSE seems to have a larger effect on "Setup configuration" than removing the entire AMITSE module.
I hope this help…
Thanks for your updated summary, I wasn’t sure about the strings you mentioned, if it was only one now or both. Maybe AMITSE is using a checksum? If not, then maybe instead of removing those last three digits, test these changes
1. F2 BC 65 CA E9 F9 BE 86 9E 1D 1C 61 91 FC 6F 0F A1 98 83 9E
2. F2 BC 65 CA E9 F9 BE 86 FF 1D 1C 61 91 FC 6F 09 A1 98 83 9E
3. F2 BC 65 CA E9 F9 FF 86 9E 1D 1C 61 91 FC 6F 09 A1 98 83 9E
So the first change gives an error:"ROM image contains invalid packages. Setup tab and BIOS String tab will not be shown.", while the second and third changes give nameless folders
Damn! Seems like it’s one of those bytes to me, but unsure what should be set. I think 00 in any of them will cause failure.
So you have been able to open and see named menu items with the 00 48 00 49 00 49 edit to setup, in some instance, or never? I wonder if blank names maybe due to the setup edit rather than the AMITSE change?
When you edit the 00 48 00 49 00 49 H.i.i in setup did you test both FF and 00?
Nope, I tried only 00, i.e. 00 48 00 49 00 49 > 00 48 00 49 00 00 . I will try with FF and let you know.
So replacing the last byte in 00 48 00 49 00 49 by FF or 00 gives the same result, i.e. nameless folders in "Setup configuration".
I meant 00 48 00 49 00 49 >> 00 00 00 00 00 00 or FF FF FF FF FF FF or 00 FF 00 FF 00 FF for all 7 instances