Posts: 220
| Last online: 09.23.2016
-
-
No. Auto means "select suitable value using a dedicated code path", not "some value we happen to call Auto". You can always reverse-engineer all DXE drivers related to this value to understand the code behind it, but it's much harder than poking the image with BCP/UBU/UEFITool/etc.
-
-
Normally, they aren't compatible unless your board manufacturer specifically designed a set of PCH GPIOs to control #WP and #HOLD pins on non-quad chips. In QuadSPI mode, both pins are used as IO pins, but in SPI/DualSPI they must be kept high for the chip to work properly. Moreover, if your BIOS is setup to support and enable QuadSPI on chip detection (which is the case for systems with Q-ships by default), it won't start without modifications. TL;DR: won't work as drop-in replacement, may be forced to work after fairly simple HW (solder pull-ups to #WP and #HOLD pins) and SW (change descriptor/ME settings to disable QuadSPI support with FITC) mods. Some manufacturers have fallback mode for non-Q chips, and they will work right away on such systems, but I won't expect any particular one to do so. TL;DR2: buy the same chip with the same ID and capacity - it should work.
-
-
No, please change the order of values, i.e. on before it's 0x417 x 0x10000, and on after it should be 0x37B x 0x10000. First value here is NumBlocks, second is BlockSize, which must remain constant and be a multiple of 0x10.
-
-
Then I've just messed up with order. 0x1000 is obviously a BlockSize of 4K, and other value that is changing is NumBlocks.
-
It's actually better to change NumBlocks instead of BlockSize, because otherwise physical SPI chip block will not be aligned with "virtual" blocks defined by BlockMap, and every erase/write operation on a "virtual" block will result in erasing/writing 2 blocks, which will shorten the lifespan of the chip and my also lead to data corruption in some rare cases. Please leave BlockSize to be a power of 16, it's normally either 0x10, 0x100 or 0x1000 and modify NumBlocks accordingly.
-
-
Originally modded one was a quick-and-dirty thing just to enable UEFITool's proper parsing, as I've removed DevExp region from there completely and extend BIOS region to the end of the image. I don't know the requirements for APL FIT because I haven't used it yet, but if it crashes on a descriptor without DevExp - it's clearly a bug in the tool.
Volume size is stored in 2 places: directly in volume header as UINT64 FvLength field, and indirectly via BlockMap, which is a structure that tells SPI flash driver how to write/erase volume contents properly. Normally, flash map consists of 2 entries - first one is (UINT32 BlockSize; UINT32 NumBlocks;) and second one is (0 ; 0) to mark the end of block map. All Intel-based images are to be stored on uniform SPI chips (i.e. chips with constant block size), so it's a parsing error for UEFITool if volume block map has other than 2 entries. Obvious check is also that BlockSize * NumBlocks == FvLength, and that's exactly what UEFITool complained about your modified image, because you've modified only the FvLength and skipped the NumBlocks. Also, if you modify something in volume header, UINT16 HeaderChecksum should be recalculated. Just open the modified file with UT NE and it will tell you want checksum value is valid.
If 2 different OEM did the same thing, it's probably a problem in either Intel or AMI batch file that invoke FIT during image build. I've seen that many time already, it will be corrected once that boundary will split some file in half and the image will stop working as a result.
I don't think it's needed to add any support for this TXE parts, just because the tool is meant to be a parser/editor for UEFI PI-compatible images, and ME/TXE is therefore out-of-scope. I will probably add some info text about TXE presence and version, though, once I can have some time for UEFITool development. Please create an issue about new TXE support here, so more people can see it.
P.S. I've seen no offence in your messages, so please don't worry about being wrong about something. We are all wrong at times, and my first solution here was also wrong just because I din't know anything about APL descriptor changes.
-
-
But it is. :)
Here is that FD we are talking about: [[File:APLBITX099_descriptor_2.png|none|auto]] It has 3 non-empty regions: Descriptor (dark red, 0x0000 - 0x0FFF), BIOS (red, 0x1000 - 0x6FEFFF) and Reserved1 (or DevExp in this case, orange, 0x6FF000 - 0x7FE000). All other possible regions for Skylake descriptor (light grey) are not present. Latest firmware volume of that file is at offset 0x384000 and has reported size of 0x417000, so it should occupy the region 0x384000 - 0x79AFFF. Please notice that because BIOS/DevExp region boundary is at 0x6FF000, the volume effectively crosses it. Latest non-empty byte of this volume is at offset 0x680BE5, so the boundary will not split any file, so only volume free space will be trashed by the system writing to 0x6FF000 and below, the system works correctly and the vendor has no worries about it. To correct the error, latest volume size must be adjusted from 0x417000 to 0x37B000, so the corrected volume will occupy the region 0x384000 - 0x6FFFFF. After this modification, the file can be parsed by UEFITool A32 and looks like this: [[File:APLBITX099_UT.png|none|auto]] Notice the padding at the end, it's there because DevExp region has 0x7FE limit instead of expected 0x7FF for some reason, and a padding from 0x7FEFFF to 0x7FFFFF is needed for the file to be 0x800000 of size in total.
Here is what we have: 1. Vendors don't care if something crosses region boundaries, and in this case it's makes no harm and therefore can't be detected without parsing the descriptor. 2. FIT tool is happy to generate such malformed images. 3. If all images will be like this, a modification of UEFITool's parser engine is needed (if there are some boundary crosses, just fall back to RAW file parsing with a message about wrong descriptor settings).
Also, I actually can contribute to UEFITool, just need a permission from my management to do that. Right now I really don't have any time for it, but I will do it later on.
-
UEFITool is totally fine there, despite the changes in APL descriptor (which are very minor compared to Skylake one, Reserved1 region is renamed to Device Expansion region, and that's about it). The problem with that images is the vendor made a mistake in last volume size, so it's free space crosses regions boundary, that's what that error message is all about. If you correct FvLength of the last volume manually to not cross the 0x6FEFFF, the file will be parsed normally. The problem is that vendor don't see that volume free space is outside the BIOS region, but UEFITool sees that and complains about it. As a workaround, someone can add a routine to correct this last volume size automatically during parsing., or tell the vendor that they are doing their images a wrong way.
-
-
-
Sure. ASUS files have UEFI capsule header, and if you haven't removed it, than you wrote the header too and such broken binary will never work.
-
-
Check your chip to be a) inserted properly with respect to orientation, b) readable by programmer and c) has the same data read and data written.
-
-
1. Your BIOS file, stripped from capsule header, is in fact Intel image, no error there. 2. Drivers for CH341A are available in Win8.1 and Win10, Win7 requires this one.
-
-
-
In short steps? UEFITool and hex editor. Please also provide current incorrect ones so it will be easier for me to search and replace.
-
ME and NVRAM must be cleaned, last 0x400 of this files removed, as they don't belong to any region (it's 4 pages of SPI chip data read by good SPI programmer). MAC is stored at the beginning of GbE regions, offset 0x1000, is 70:71:BC:F8:31:3E in that file. I will try to make you a clean file tomorrow, if @plutomaniac doesn't want to make it today. :)
-
-
Don't forget to remove capsule header from factory BIOS file, if any.
-
It's a chip to the left of the first PCIe x16 connector, with crab icon on it.
-
-
The easiest solution on Asrock boards is pinmod (search forum for this word), that will initiate ME overwrite and restore it to clean state.
-
-
I think an external SPI programmer is the best option here. I don't know if your SPI chip is soldered down or socketed (I hope for the second, as it's a workstation, not laptop), but you need to perform dump-modify-flash cycle on it to get your changes applied without having Dell private key.
-
-
@plutomaniac My pleasure. It was planned looong ago and was so easy to implement, that I just kept postponing it. Now the goal is to get rid of Qt for all console-based tools starting with UEFIExtract, as I only use ~10 classes from all the library, and it will really spare me a megabyte of EXE size and enable others to use UE in non-GPL environments.
| |