![]() Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x029E, 0x434D5341344758334D314131303636433720ĪirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.106.98.100.24)īluetooth: Version 4.3.During the debugging of strange behavior of using UEFITool with Gigabyte BIOSes, I have found either a bug or a special non-standard region map configuration in all recent Gigabyte BIOS images. Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB Model: MacBookPro6,1, BootROM 0F, 2 processors, Intel Core i7, 2.8 GHz, 8 GB, SMC 1.57f18 Rip: 0x00007fff5fc01075 rfl: 0x0000000000000202 cr2: 0x00007fff5fc3a008Ĭalls made by other processes targeting this process:Ĭalls made by all processes on this machine: Unknown thread crashed with X86 Thread State (64-bit): Path: /Users/USER/Downloads/UEFITool.app/Contents/MacOS/UEFIToolĪnonymous UUID: CE630B4F-8DA3-F31D-DC3A-00A1CF81D098 It goes without mentioning that this has low priority and shouldn't be done before other work, but it is something for usability. Maybe add a bold tag for the double-clicked message, like this? The item selected in messages tab is barely visible. Let's say the focus is in the tree/structure, something like in the image above. For me, it should be something like this: This takes me to that section, but the parent GUID is hidden. Let's say I have clicked a few messages, than I want to click a previous message, in reverse order. If somehow every GUID in that area is expanded from previous searches, it will get very confusing and you need to always visually check the parent. ![]() ![]() It is helpful to have the parent GUID in bold, to know where you are standing. Notice that the focus is in Messages tab, I have double-clicked one of the messages and it has scrolled in the tree to that section. Keep up the good work.Ĭlick to expand.Here is the first case: I do know there aren't many users of this tool, so any report is useful, and detailed reports are very useful. Please explain further (some drawing will be nice, because if it comes to UI stuff, I'm becoming pretty dumb), how it should work and why. More to say, if a section is really misaligned, parser code can't find it, because section header is too generic to be found by pattern matching.Ībout positions in tree: right now I'm just using scrollTo(item), so I have no control over it. N-bytes alignment is not "make the size of this chunk NxSomething", but "start this chunk at NxSomething offset". MMTool includes 2 additional empty bytes of FFS alignment, which have nothing to do with a file itself and are part of firmware volume. That CapsuleX64.ffs is 0x2F6E bytes long, with a UI section of 0x0E bytes, and UEFITool extracts it exactly like this. UEFITool does the extraction according to FFS file header, and if it's size is not 8xSomething, no additional bytes will be included. MMTool includes FFS alignment bytes as part of an extracted file for some reason, so all MMTool-extracted files have 8xSomething in size, with 0 to 7 empty bytes at the end. 0xFF in like 99,99% cases and 0x00 otherwise). There are also alignment requirements for FFS files, they must be aligned to 8 bytes boundary by default, and default alignment byte for FFS files depends on volume's erase polarity (i.e. Alignment bytes must be 0x00 according to the spec (MMTool uses 0xFD, AFAIR, but it's not the bug I'm talking about). Specs says that all sections must be aligned to 4 bytes boundary, with 0 byte beginning right after FFS file header. I think you have some wrong assumptions about section alignment, and MMTool proves them to be correct because of a bug in it. ![]() Good thing is: if you don't touch it - it won't be modified at all. I will try to implement more convenient way to parse RAW file, so if there are something wrong, no subitems will be shown. The whole thing about parsed-but-not-showed contents pisses me off too, but the main reason for this is that all reconstruct* routines are using tree items and only them for reconstructing BIOS image, that is why I'll better not add something malformed into the tree. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |