NitroPC bios backup and update

I recently run my first Niktrokey device what is NitroPC. I purchased open-firmware solution to learn about it and also get a enhanced security computer (neutralized ME and open source firmware) for programmer / sysadmin.

I cloned the repository:

The compilation was trivial (I used default main branch). As a result I received tianocore-4.13.rom file.

At initial try I didn’t modify anything but I really like the bootsplash modification feature and I will try it.

First thing I wanted to do is to backup the default BIOS. I installed flashrom.

$ sudo flashrom -p ch341a_spi -c W25Q128.V -r backup.rom
[sudo] password for user:
flashrom v1.2 on Linux 5.11.0-40-generic (x86_64)
flashrom is free software, get the source code at https:

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Couldn’t open device 1a86:5512.
Error: Programmer initialization failed.

Question 0: Do I use a correct source code repository?
Question 1: Do I have to open the case and there is a jumper or something which blocks me from getting a current ROM copy? Or I’m getting it wrong.
Question 2: The flashing of updated firmware should be as simple as executing of script flashrom, however it is likely not to succeed because of error 1a86:5512 during getting backup, however there might be a necessity to modify jumper settings on motherboard or something like this.
Question 3: When you release a new version will it always be visible on GitHub?
Question 4: I wanted to test build result in virtual machine and I’ve chosen QEMU to do this (CoreBoot recommends this). I tried the following idea:

$ qemu-system-x86_64 -bios tianocore-4.13.rom -boot d -cdrom debian-11.1.0-amd64-netinst.iso -m 500

Error is "Gust has not initialized the display (yet).

When I remove BIOS parameter Debian installer starts. The question is if I have made a mistake during image preparation (built BIOS is wrong) or I am using QEMU wrong (I’m not QEMU expert).

Best regards,
Marcin Górski

flashrom version 1.2 is not supporting the chipset yet, please use the most recent git, this one should support the hardware properly. Backing up the bios should then be done using the internal programmer like this: flashrom -p internal, the parameters you have been using is for an external programmer…


nope, see flashrom version thingy above

This clearly is not trivial, we are not testing with QEMU, so I can’t help you here, sorry


I’ve compiled the recent master version from source (repository: This version detects Comet Lake chipset.

And it succeeded to get a BIOS backup.
mar@mar-desktop:~/firmware/another-build-dir/coreboot-builder$ sudo /home/mar/flashrom-recent-master/flashrom -p internal -r output.bin
[sudo] password for mar:
flashrom v1.2-551-gf47ff31 on Linux 5.11.0-40-generic (x86_64)
flashrom is free software, get the source code at

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x99b85000.
Found chipset “Intel Comet Lake U Premium”.
Enabling flash write… Warning: Setting BIOS Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
SPI Configuration is locked down.
Found Programmer flash chip “Opaque flash chip” (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
Reading flash… done.
It has 16 MB - very big image.

So I guess when I have a backup I can flash the UEFI with recent built. It was also trivial.

So it should be possible now to do the same write operation. The risk is quite low, because I use the proper source code repository.

Question 5: Is it possible to write new image when ‘SPI Configuration is locked down’? What does it mean? I will try to write recent BIOS tomorrow (modify splash screen).
Question 6: Is Management engine running on my Comet Lake machine?

I will try to answer question 6 by myself. I downloaded tool ME Analyzer from GitHub (

The results are:


I understand this data as Management Engine in version present, up and running, but I have no AMT to manage it by my own. It seems to me that it should be at least partially erased (error codes should be present).

Is my current interpretation true?

Yes, this is possible. Anyways be careful, if you mess something up, you will need to open the device & flashing equipment to flash it back to a working state.

MEAnalyzer is made to analyze an image, the best way to determine if the ME is running is from the inside of the system using coreboot’s intelmetool (

Nope, this is not true. Before jumping into conclusions, please understand how the ME is disabled/neutered:

and here is a documentation on how you actually read out the state: