Posts: 240 | Last online: 07.25.2017
Nikolaj Schlej
Date of birth
4. February 1987
Firmware Engineer
Deggendorf, Germany
Date registered
    • CodeRush has written a new post "Lenovo E530 - BIOS Startup menu with boot options missing" 06.29.2017

      Both chips are "main" on this platform because .FL file is 12 Mb exactly. There's a little sense in splitting ME region in half, so I think that Descriptor, ME and NVRAM are in the Q64 one.
      If you don't have SPI programmer, you should definitely get one instead of buying pre-programmed SPI chips (which cost a lot and have unknown firmware in them).
      The state of this system is definitely fixable, it looks like a corruption of some NVRAM variables required for booting (BootXXXX, for example).

    • CodeRush has written a new post "Lenovo E530 - BIOS Startup menu with boot options missing" 06.29.2017

      This looks like a broken NVRAM issue, you need to dump W25Q64 chip and fix NVRAM in there. It could be rather difficult because there are no tools for doing it besides hex editor, but if you could attach the dump and the .FL1 file, I will try to help.

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



Xobor Forum Software von Xobor