This automatic translation is a crap. I meant that I can't add NCB support directly, because I'm bound by NDA and can't prove that I haven't looked into AMI code for making such support, but I will think about adding support for patches that are applied directly to input file without parsing (they can be used for patching descriptor region, for example). I'm sorry we are using Russian on this English-speaking forums, BTW. Will provide a translation next times, because I see that automatic translation from russian sucks a lot.
Too few free space for repacked files, it must be modified manually. Problems with Windows XP will hopefully be solved in next release.
@Tito, you are talking about HII files parser with very interesting interface, and it can be done, but it will be a project more complex and harder to develop as the whole UEFITool before. It's possible as an idea, but I won't do this right now for sure.
UEFITool 0.18.2 is out. Changes: - messages are now delayed until tree item is created and therefore double click on a message selects the item itself, not it's parent, as it was by all previous versions. - error messages are now user-friendlier, i.e "UEFI volumes not found" instead of "Error code: 14". Search for GUID and pattern-based search will be implemented in next version. Please test and write your reports here or on issue tracker.
Another UEFITool update - 0.18.3. Changes: - '.' (dot) symbol can be used as "any hex digit" placeholder for hex pattern search - added search for GUIDs (pattern format is the same as above) - added copy action to copy the text of selected message (hotkey: Ctrl+Shift+C) - small changes to focus handling in search window Please test and report any errors you may find.
Something about DXE dependency will be useful,if that info could be decoded. Another useful ideea I think,since I see on some BIOS they don't have user interface sections,in that case display possible name from a predefined list based on GUID ID. For free form ones parse module and if PCIR detected,name it Option rom and append hardware id into resulted name. Same method could apply for SSDT DSDT etc
@Aigor, I have a lot of such BIOSes. FFF.. volume is an NVRAM storage on that platform, 005.. is some non-FV board data I don't know anything about, and for those non-FV (i.e. no FFS files inside) modules there are always some inconsistencies in BlockMap or VolumeSize, so I recommend not to give a f*ck here. Sections with 0xF0 type are common too, and their puprose is somewhat related to CRC32 calculation, I think, but any modification can be performed and works so it appears that this checkums are nowhere to be verified. There are nothing to do about OSX there, don't be confused by names. PartitionDxe is a normal EDK-based partition driver that consumes DISK_IO device node and produces BLOCK_IO nodes for each partitions it could find on specific disk.
Thank you CodeRush for your knwoledge that you share with me If i can i would like to ask you another thing, it seems that this bios is uefi, but in bios i cant see anything about efi, maybe it's hidden? do you know some software like amibcp that show bios menu and so on? Thank you in advance I hope that my messages dont bother you
1. I can either be hidden or just removed because UEFI boot didn't work as expected for some reason that time. 2. I don't know any dedicated software, but D6K's Universal IFR Extractor may help in digging thru menus.
UEFITool 0.18.5 is out. Changes: -added "Copy all" action for messages -solved a bug with inserting/replacing RAW files introduced in 0.18.0 -windows version compiled by VS2010 Please check if the program still works in Windows XP, I don't have a platform to test it.