Posts: 236 | Last online: 05.27.2017
Nikolaj Schlej
Date of birth
4. February 1987
Firmware Engineer
Deggendorf, Germany
Date registered
    • It's great that this brings you fun, @davidm71, way to go! Just wanted to warn you: if you want to share your tool and want others to use it - be prepared of the constant stream of "please patch my BIOS", "why is this shit not working?!" and "you need to pay for repairing my motherboard!!!"
      I very much encourage everyone to share the knowledge and have fun with BIOS modifications, but there's also a big chunk of people who don't understand that we aren't a tech support, we don't have to help anyone with anything and we won't be hold responsible for anything that they read here.
      The whole FW modding community really need people like you, @davidm71, so please don't stop tinkering and having fun because I've said something. I won't be where I'm now without UEFITool, and I still think that "automate everything" is a bad idea, but I don't discourage you from doing anything or releasing anything.

    • @Fernando, about the OROM integration guide: I can't write it just because I don't know anything about them, but @SoniX may know more.
      CSM in general is a bane of every EFI developer's existence, so the sooner we get rid of legacy OptionROMs - the better.
      I know there are still a lot of systems that can't work in pure UEFI mode with disabled CSM, but this is a very good reason to upgrade your system.

    • All my tools are explicitly BSD- and/or GPLv2-licensed, so no one needs any permission to modify them.
      OZMTool is written by TuxUser (with a bit of my help in better understanding the inner works of the 0.2x engine), but it's also based on UEFITool's source code.

      There's a problem with insertion of new stuff in DXE volume if the volume itself is a root volume and hasn't enough space to fit the new driver, and in this particular case, even UEFITool can do nothing with the situation, but this case is very rare on modern systems.

      In my opinion, automation tools like OZMTool, UEFIPatch or UBU are actually making things worse, and I only realized it after 5 years of developing/helping developing them.
      The tool obscures the real complexity and danger of FW modifications, so less and less people are actually understand what they are doing and why they are doing it, switching to mindlessly applying any VBIOS/OROM/ME update they may find, trying to get another 100 IOPS from the same SSD and another 50 Mhz of already overclocked RAM. This kind of tinkering is totally fine, but only if it helps learning how the FW actually works and why you need to change this instead of that, and automation simply destroys this step. A proper guide with explanations and infos is 100 times better than a program that automates it, because if you read a guide - you learn something, and if you run a program - you learn nothing at all, only it's author did during the program development.
      Please think twice before telling the world "hey guys, I've automated your routine BIOS modding task!" as I did, as you will be blamed for every user mistake, every bricked system, every corrupted BIOS and about 10% of those will actually be your fault because a perfect 100% working program can't exist.

    • It makes no sense to change any defaults the was selected by platform manufacturer. You can try decompressing DxeCore, if it was compressed originally, but if it will work or not - depends solely on the implementation in a given FW image. EFI decompression is limited by SPI throughput only, and the difference of compressed/uncompressed is extremely small on any CPU better than 400Mhz Quark.
      I know it's a lot of fun to mess with EFI, but if you just want to insert a NVMe driver and get your drive to be bootable - there's no reason to repack anything, just insert the driver to the end of DXE volume and be happy.

    • I do not understand why the whole OSM community wants to add anything into the DXE volume in the first place. SPI flash is slower than any modern HDD or SSD, and EFI System Partition is a perfect place for such files, but instead of using ESP for it's purpose, OZM folk want to get rid of it to spare 200 Mb of drive space. It makes no sense, FW modifications lead to countless problems, but many people still want "the native experience" of OZM integrated into the FW.
      Why the hell you all do it? I don't know. I've implemented internal volume grow because it's easy and requires very few changes in the FW (root volumes are much harder to resize, I must say).

    • The correct amount of free space will actually depend of a definition of "free space".
      Specification defines free space to be all bytes from the end of the last file of the volume to the end of the volume itself, so volume_header_offset_of(last_file) + size_of(last_file) + size_of(free_space) = size_of(volume).
      There's, however, another possible definition of free space: maximum size of a file that can still fit into the volume. This size will be 0 - 7 bytes less because of default file alignment of 8, or even lesser if the alignment is set to be more than 8 (like it's for Volume Top File, for example).
      Actually, because EFI FFS doesn't define any order, it's possible to rearrange files to have less alignment gaps between them by solving a knapsack problem. This will be implemented in UEFITool NE after I can get to it's development again.

    • @davidm71 ,could you please be more specific about the difference?
      MMTool tend to align all file sizes to 8 (which works, but it's out of spec). so UEFITool may report from 0 to 7 bytes more free space than MMTool, but it's a harmless quirk in the later.

    • CodeRush has written a new post "[check] 3 bioses to verify if they are valid " 01.27.2017

      The only way to "verify" them is to try and restore if they aren't working. Yes, you need a hardware SPI programmer for making backups and for restoring, but it's the only option if you want to be sure. No one but you will check you files.

    • CodeRush has written a new post "What modules in bios safe to compress?" 01.20.2017

      You can tell it by the image structure, if it has "Compressed" sections (i.e. UEFITool shows them with this name) - it's EDK1 for sure.
      OZMTool is written by TuxUser, he's active on insanelymac.org forums.

    • CodeRush has written a new post "new ASRock Aptio 5 bios on J4205-ITX" 01.20.2017

      Already discussed here, there's a bug in descriptor configuration of that file. Use MMTool 5 or PhoenixTool to work with it.

    • CodeRush has written a new post "What modules in bios safe to compress?" 01.20.2017

      It depends on actual image structure.
      If you have a compressed volume, adding any other compression of files/sections will make things worse and will also probably don't work.
      If you have a normal volume, there will be 2 option: 1. EDK1-based images used compressed sections with various compression types (EFI11/Tiano/LZMA variations), 2. EDK2-based images are using GUID-defined sections with predefined GUIDs for different compression types. You can try compressing some uncompressed files the way it's done in your image, but only if there are files of the same type compressed the same way.
      PEI modules from boot volume are executable-in-place and therefore shouldn't ever be compressed.
      As a matter of fact, trial and error is the best option here. Try your compression out, if the board does boot - it's probably fine.

    • 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.



Xobor Forum Software von Xobor