Posts: 224 | Last online: 01.19.2017
Nikolaj Schlej
Date of birth
4. February 1987
Firmware Engineer
Deggendorf, Germany
Date registered
    • CodeRush has written a new post "cpu upgrade leads to 30 min shutdown" 01.17.2017

      Another option is to buy a compatible C850/C855 motherboard with HM76 for this CPU, but @plutomaniac helped so many people here that he deserves this generous donation. Big thanks from me too, as such behavior is very rare nowadays.

    • CodeRush has written a new post "Add option in AMI UEFI bios menu (how to?)" 09.25.2016

      No. First, prepare an UEFI-bootable USB drive with RU utility (download, unpack, rename RU.efi to bootx64.efi, copy it to /BOOT/EFI of a FAT32-formatted USB drive and boot from it).
      Press Alt+= to open NVRAM variable selector, type "Setup" and press Enter. You see your Setup variable (press Ctrl+PgDn to see offsets past 0xFF), make screenshots (F12) of all values, then change "Legacy USB support" option and repeat the process. Compare screenshots to see where are that 0x00/0x01 is located and try to change (Enter) some 0x00s near it to 0x01s and see if XHCI HO is enabled.

    • CodeRush has written a new post "Add option in AMI UEFI bios menu (how to?)" 09.25.2016

      No, it's hardcoded during build process and can't be changed easily. There is a possibility left that the code to enable/disable XHCI hand-off is still present and it can be controlled by an entry in Setup variable. Try finding where "Legacy USB Support" option is located in your Setup var and switch some 0x00s to 0x01s near it.

    • CodeRush has written a new post "Make "Auto" values visible?" 09.16.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.

    • CodeRush has written a new post "Winbond chips compatiblity - Naming rules" 09.15.2016

      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.

    • CodeRush has written a new post "ME Analyzer: Intel Engine Firmware Analysis Tool" 09.12.2016

      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.

    • CodeRush has written a new post "ME Analyzer: Intel Engine Firmware Analysis Tool" 09.11.2016

      Then I've just messed up with order. 0x1000 is obviously a BlockSize of 4K, and other value that is changing is NumBlocks.

    • CodeRush has written a new post "ME Analyzer: Intel Engine Firmware Analysis Tool" 09.11.2016

      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.

    • CodeRush has written a new post "ME Analyzer: Intel Engine Firmware Analysis Tool" 09.10.2016

      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.

    • CodeRush has written a new post "ME Analyzer: Intel Engine Firmware Analysis Tool" 09.07.2016

      But it is. :)

      Here is that FD we are talking about:
      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:
      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.

    • CodeRush has written a new post "ME Analyzer: Intel Engine Firmware Analysis Tool" 09.07.2016

      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.

    • CodeRush has written a new post "Reflash Error 26 - Z77 i5 3570k" 07.16.2016

      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.

    • CodeRush has written a new post "BIOS Data Intel DH67BL erased" 07.09.2016

      In short steps? UEFITool and hex editor. Please also provide current incorrect ones so it will be easier for me to search and replace.

    • CodeRush has written a new post "BIOS Data Intel DH67BL erased" 07.09.2016

      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. :)



Xobor Forum Software von Xobor