I've run into 2 problems with trying to set up coreboot for an HP Probook 440 G7. The first is that I don't see this model listed as an option in the menuconfig. It is a newer Intel Cometlake CPU/chipset and most of what I see listed as options are much older machines. Is there a "generic cometlake" config I can try or am I just out of luck on this?
The 2nd problem is that cbfstool doesn't recognize the bios dump I did from the mainboard. I get the error "Selected image region is not a valid CBFS." I'm pretty sure the the dump is valid because I can read it using the Intel FIT tool or ME_Analyzer. I'm going to need to pull the various binary blobs out of the current firmware and this is the only way I know how. Is there another option here?
hi Brian,
coreboot support is extremely hardware specific by nature, so there are no generic platform targets (other than the emulation ones).
In order to use coreboot on your board, you'd first need to ensure that Bootguard (or similar signature checking schemes) are not being used, which would prevent loading unsigned firmware. Then you'd need to dump the hardware config of the device in order to build a board profile (devicetree, GPIO assignments, etc).
cbfstool isn't going to recognize a dump of your vendor firmware as it doesn't contain a CBFS (coreboot filesystem). You'll need to use other tools if you need to dump/extract bits from the vendor firmware, though that's not always necessary, given that FSP does most of the heavy lifting and is included as part of the build process for (most) platforms that use it
cheers, Matt
On Tue, Sep 14, 2021 at 12:42 PM Brian Milliron brian.milliron@foresite.com wrote:
I've run into 2 problems with trying to set up coreboot for an HP Probook 440 G7. The first is that I don't see this model listed as an option in the menuconfig. It is a newer Intel Cometlake CPU/chipset and most of what I see listed as options are much older machines. Is there a "generic cometlake" config I can try or am I just out of luck on this?
The 2nd problem is that cbfstool doesn't recognize the bios dump I did from the mainboard. I get the error "Selected image region is not a valid CBFS." I'm pretty sure the the dump is valid because I can read it using the Intel FIT tool or ME_Analyzer. I'm going to need to pull the various binary blobs out of the current firmware and this is the only way I know how. Is there another option here? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Matt.
hi Brian,
coreboot support is extremely hardware specific by nature, so there are no generic platform targets (other than the emulation ones).
In order to use coreboot on your board, you'd first need to ensure that Bootguard (or similar signature checking schemes) are not being used, which would prevent loading unsigned firmware. Then you'd need to dump the hardware config of the device in order to build a board profile (devicetree, GPIO assignments, etc).
There is firmware signing, but as I'm using a hardware based flasher, I can circumvent this, I think. How would I dump the hardware config and build a board profile? Is that something I could do myself or would it be up to the coreboot devs to create and integrate a board profile?
cbfstool isn't going to recognize a dump of your vendor firmware as it doesn't contain a CBFS (coreboot filesystem). You'll need to use other tools if you need to dump/extract bits from the vendor firmware, though that's not always necessary, given that FSP does most of the heavy lifting and is included as part of the build process for (most) platforms that use it
I was under the impression I would need the flash descriptor, video BIOS or VBT, Intel ME, PCH Reference Code, and Memory Reference Code (MRC). The Intel ME I downloaded from the winraid archive, but the others I would need to get from firmware. The Intel FSP is now included in coreboot? Are none of the others needed any more? If some of them are needed, what tools could I use to extract them?
On Tue, Sep 14, 2021 at 1:58 PM Brian Milliron brian.milliron@foresite.com wrote:
Hi Matt.
hi Brian,
coreboot support is extremely hardware specific by nature, so there are no generic platform targets (other than the emulation ones).
In order to use coreboot on your board, you'd first need to ensure that Bootguard (or similar signature checking schemes) are not being used, which would prevent loading unsigned firmware. Then you'd need to dump the hardware config of the device in order to build a board profile (devicetree, GPIO assignments, etc).
There is firmware signing, but as I'm using a hardware based flasher, I can circumvent this, I think. How would I dump the hardware config and build a board profile? Is that something I could do myself or would it be up to the coreboot devs to create and integrate a board profile?
Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into the ME. If Bootguard enabled and keys fused, nothing can be done unfortunately.
You can build a large chunk of the board profile using inteltool (if platform supported), dumping ACPI, etc. But there are plenty of bits that aren't currently documented. And getting the EC to cooperate can be a real chore.
cbfstool isn't going to recognize a dump of your vendor firmware as it doesn't contain a CBFS (coreboot filesystem). You'll need to use other tools if you need to dump/extract bits from the vendor firmware, though that's not always necessary, given that FSP does most of the heavy lifting and is included as part of the build process for (most) platforms that use it
I was under the impression I would need the flash descriptor, video BIOS or VBT, Intel ME, PCH Reference Code, and Memory Reference Code (MRC). The Intel ME I downloaded from the winraid archive, but the others I would need to get from firmware. The Intel FSP is now included in coreboot? Are none of the others needed any more? If some of them are needed, what tools could I use to extract them?
the IFD and ME aren't needed strictly speaking, unless you need to modify them in some way. But you would extract those using ifdtool. Definitely don't want to use a non-board-specific ME downloaded from win-raid (eg) as the soft straps and clock mappings will not be correct for your board.
FSP (which contains both the MRC and PCH refcode) also does video init, and VBIOS isn't used on modern platforms. coreboot's native display init (libgfxinit) is preferred if available. The only bit you will likely need is the VBT, which you can get from Linux (or dump from vendor firmware, but often contains multiple copies).
Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into the ME. If Bootguard enabled and keys fused, nothing can be done unfortunately.
I checked the BIOS. There was nothing specifically listed as "Bootguard" but all the BIOS protection options were turned off, including one listed as "Checked boot block on every boot". I'm guessing that means Bootguard is installed but not enabled. Is there another place to look to get a more accurate/detailed read on this?
You can build a large chunk of the board profile using inteltool (if platform supported), dumping ACPI, etc. But there are plenty of bits that aren't currently documented. And getting the EC to cooperate can be a real chore.
I dumped what inteltool was able to read, but I got a lot of "platform not supported" errors. I've attached the output to the end of this message. Do you think this information would be enough to create a bootable board profile?
the IFD and ME aren't needed strictly speaking, unless you need to modify them in some way. But you would extract those using ifdtool. Definitely don't want to use a non-board-specific ME downloaded from win-raid (eg) as the soft straps and clock mappings will not be correct for your board.
I intend on using me_cleaner to wipe all but a stub of the ME code, so having a working copy isn't something I'm too worried about as long as it passes the signature checks.
FSP (which contains both the MRC and PCH refcode) also does video init, and VBIOS isn't used on modern platforms. coreboot's native display init (libgfxinit) is preferred if available. The only bit you will likely need is the VBT, which you can get from Linux (or dump from vendor firmware, but often contains multiple copies).
How would I get hold of this?
###Inteltool output###
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics) SBREG_BAR = 0xfd000000 (MEM)
Error mapping physical memory 0xfd000000[0x1000000] CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
========== LPC/eSPI =========
Error: Dumping LPC/eSPI on this southbridge is not (yet) supported.
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= AHCI Registers ==============
============= AHCI Configuration Registers ==============
============= SATA Initialization Registers ==============
============= ABAR ==============
ABAR = 0xf1215000 (MEM)
Error mapping physical memory 0xf1215000[0x400] CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= Dumping INTEL SGX status ============= Number of CPUs = 8 ------------- CPU 0 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 1 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 2 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 3 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 4 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 5 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 6 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 7 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ==================================================== CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= Dumping INTEL TME status ============= TME supported : NO ====================================================
Have we physically checked to determine if the ME uses e-fuses and not a poly switch. Or are we just trusting Intel on these matters?
On 17/9/21 12:37 am, Brian Milliron wrote:
Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into the ME. If Bootguard enabled and keys fused, nothing can be done unfortunately.
I checked the BIOS. There was nothing specifically listed as "Bootguard" but all the BIOS protection options were turned off, including one listed as "Checked boot block on every boot". I'm guessing that means Bootguard is installed but not enabled. Is there another place to look to get a more accurate/detailed read on this?
You can build a large chunk of the board profile using inteltool (if platform supported), dumping ACPI, etc. But there are plenty of bits that aren't currently documented. And getting the EC to cooperate can be a real chore.
I dumped what inteltool was able to read, but I got a lot of "platform not supported" errors. I've attached the output to the end of this message. Do you think this information would be enough to create a bootable board profile?
the IFD and ME aren't needed strictly speaking, unless you need to modify them in some way. But you would extract those using ifdtool. Definitely don't want to use a non-board-specific ME downloaded from win-raid (eg) as the soft straps and clock mappings will not be correct for your board.
I intend on using me_cleaner to wipe all but a stub of the ME code, so having a working copy isn't something I'm too worried about as long as it passes the signature checks.
FSP (which contains both the MRC and PCH refcode) also does video init, and VBIOS isn't used on modern platforms. coreboot's native display init (libgfxinit) is preferred if available. The only bit you will likely need is the VBT, which you can get from Linux (or dump from vendor firmware, but often contains multiple copies).
How would I get hold of this?
###Inteltool output###
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics) SBREG_BAR = 0xfd000000 (MEM)
Error mapping physical memory 0xfd000000[0x1000000] CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
========== LPC/eSPI =========
Error: Dumping LPC/eSPI on this southbridge is not (yet) supported.
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= AHCI Registers ==============
============= AHCI Configuration Registers ==============
============= SATA Initialization Registers ==============
============= ABAR ==============
ABAR = 0xf1215000 (MEM)
Error mapping physical memory 0xf1215000[0x400] CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= Dumping INTEL SGX status ============= Number of CPUs = 8 ------------- CPU 0 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 1 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 2 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 3 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 4 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 5 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 6 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 7 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ==================================================== CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= Dumping INTEL TME status ============= TME supported : NO ==================================================== _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Thu, Sep 16, 2021 at 9:36 AM Brian Milliron brian.milliron@foresite.com wrote:
Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into the ME. If Bootguard enabled and keys fused, nothing can be done unfortunately.
I checked the BIOS. There was nothing specifically listed as "Bootguard" but all the BIOS protection options were turned off, including one listed as "Checked boot block on every boot". I'm guessing that means Bootguard is installed but not enabled. Is there another place to look to get a more accurate/detailed read on this?
it's not going to be a setting in the vendor firmware.
`intelmetool -b` should report the status properly
You can build a large chunk of the board profile using inteltool (if platform supported), dumping ACPI, etc. But there are plenty of bits that aren't currently documented. And getting the EC to cooperate can be a real chore.
I dumped what inteltool was able to read, but I got a lot of "platform not supported" errors. I've attached the output to the end of this message. Do you think this information would be enough to create a bootable board profile?
nope, you'll need `inteltool -g` as well
the IFD and ME aren't needed strictly speaking, unless you need to modify them in some way. But you would extract those using ifdtool. Definitely don't want to use a non-board-specific ME downloaded from win-raid (eg) as the soft straps and clock mappings will not be correct for your board.
I intend on using me_cleaner to wipe all but a stub of the ME code, so having a working copy isn't something I'm too worried about as long as it passes the signature checks.
me_cleaner doesn't support anything newer than 6th/7th-gen SoCs/CPUs. The best you can do on Cometlake currently is to set the HAP bit in the IFD.
FSP (which contains both the MRC and PCH refcode) also does video init, and VBIOS isn't used on modern platforms. coreboot's native display init (libgfxinit) is preferred if available. The only bit you will likely need is the VBT, which you can get from Linux (or dump from vendor firmware, but often contains multiple copies).
How would I get hold of this?
I don't have the method handy, I usually just extract it from the vendor firmware using UEFITool
###Inteltool output###
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics) SBREG_BAR = 0xfd000000 (MEM)
Error mapping physical memory 0xfd000000[0x1000000] CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
========== LPC/eSPI =========
Error: Dumping LPC/eSPI on this southbridge is not (yet) supported.
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= AHCI Registers ==============
============= AHCI Configuration Registers ==============
============= SATA Initialization Registers ==============
============= ABAR ==============
ABAR = 0xf1215000 (MEM)
Error mapping physical memory 0xf1215000[0x400] CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= Dumping INTEL SGX status ============= Number of CPUs = 8 ------------- CPU 0 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 1 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 2 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 3 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 4 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 5 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 6 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ------------- CPU 7 ---------------- SGX supported : YES SGX enabled : YES Feature Control locked : YES ==================================================== CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics)
============= Dumping INTEL TME status ============= TME supported : NO ====================================================
it's not going to be a setting in the vendor firmware.
`intelmetool -b` should report the status properly
intelmetool reports Bootguard is not activated, so looks like I am in the clear, though there was a memory read error for some reason.
MEI found: [8086:2e0] Device 02e0
ME Status : 0xa0000245 ME Status 2 : 0x6f10506
ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : YES ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : M0 with UMA ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase ME: Power Management Event : Pseudo-global reset ME: Progress Phase State : (null)
ME: Extend SHA-256: 05045e8332f6cd294b001985eef893ac5c9fb1c58666459731b3fc0eeff07ad2
Error mapping physical memory 0x0000000001101824 [0x2000] ERRNO=1 Operation not permitted Could not map ME setup memory. Do you have kernel cmdline argument 'iomem=relaxed' set ? BootGuard MSR Output : 0x0 [32mYour system isn't BootGuard ready. You can flash other firmware! [0m
Not sure why the memory error since I included iomem=relaxed in the grub.cfg
linux /boot/vmlinuz-4.19.0-10-amd64 root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro iomem=relaxed quiet linux /boot/vmlinuz-4.19.0-10-amd64 root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro iomem=relaxed quiet linux /boot/vmlinuz-4.19.0-10-amd64 root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro single iomem=relaxed
nope, you'll need `inteltool -g` as well
inteltool -g is one of the ones that doesn't work on this board.
Error mapping SBREG_BAR: Operation not permitted CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics) SBREG_BAR = 0xfd000000 (MEM)
Error mapping physical memory 0xfd000000[0x1000000]
me_cleaner doesn't support anything newer than 6th/7th-gen SoCs/CPUs. The best you can do on Cometlake currently is to set the HAP bit in the IFD.
I suppose the HAP bit will have to do then.
So, I guess the question at this point is how feasible would it be to install coreboot on this board? I'd rather not sink a lot of time into it if it's only going to lead to a dead end and using the board with vendor firmware is not an option for me because in addition to the Intel ME there is also Computrace which can't be disabled. I can't trust any PC with spyware built in.
Andreas suggested I use the intel reference board setup in debug mode and use that to try to configure a working system. I see there is an intel reference board for Cometlake, but I don't know if I have the needed information to successfully configure the board properly, given the inteltool -g doesn't work and there may be problems finding the correct GPIO settings. I do have the pinout for the W25Q128JV chip which holds the BIOS. Not sure if that helps with the GPIO or not. What do the coreboot developers think about this situation? Is there a way forward and if so what would it involve?
On Fri, Sep 17, 2021 at 12:57 PM Brian Milliron brian.milliron@foresite.com wrote:
it's not going to be a setting in the vendor firmware.
`intelmetool -b` should report the status properly
intelmetool reports Bootguard is not activated, so looks like I am in the clear, though there was a memory read error for some reason.
MEI found: [8086:2e0] Device 02e0
ME Status : 0xa0000245 ME Status 2 : 0x6f10506
ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : YES ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : M0 with UMA ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase ME: Power Management Event : Pseudo-global reset ME: Progress Phase State : (null)
ME: Extend SHA-256: 05045e8332f6cd294b001985eef893ac5c9fb1c58666459731b3fc0eeff07ad2
Error mapping physical memory 0x0000000001101824 [0x2000] ERRNO=1 Operation not permitted Could not map ME setup memory. Do you have kernel cmdline argument 'iomem=relaxed' set ? BootGuard MSR Output : 0x0 [32mYour system isn't BootGuard ready. You can flash other firmware! [0m
Not sure why the memory error since I included iomem=relaxed in the grub.cfg
linux /boot/vmlinuz-4.19.0-10-amd64 root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro iomem=relaxed quiet linux /boot/vmlinuz-4.19.0-10-amd64 root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro iomem=relaxed quiet linux /boot/vmlinuz-4.19.0-10-amd64 root=UUID=b889fd33-7705-4b9c-9c33-c304bbe7a6e5 ro single iomem=relaxed
nope, you'll need `inteltool -g` as well
inteltool -g is one of the ones that doesn't work on this board.
well, fixing that is necessary, can't set up the GPIOs properly without it (or the schematics)
Error mapping SBREG_BAR: Operation not permitted CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics) SBREG_BAR = 0xfd000000 (MEM)
Error mapping physical memory 0xfd000000[0x1000000]
me_cleaner doesn't support anything newer than 6th/7th-gen SoCs/CPUs. The best you can do on Cometlake currently is to set the HAP bit in the IFD.
I suppose the HAP bit will have to do then.
So, I guess the question at this point is how feasible would it be to install coreboot on this board? I'd rather not sink a lot of time into it if it's only going to lead to a dead end and using the board with vendor firmware is not an option for me because in addition to the Intel ME there is also Computrace which can't be disabled. I can't trust any PC with spyware built in.
Andreas suggested I use the intel reference board setup in debug mode and use that to try to configure a working system. I see there is an intel reference board for Cometlake, but I don't know if I have the needed information to successfully configure the board properly, given the inteltool -g doesn't work and there may be problems finding the correct GPIO settings.
I do have the pinout for the W25Q128JV chip which holds the BIOS. Not sure if that helps with the GPIO or not.
that's standard and not of any use with GPIOs
What do the coreboot developers think about this situation? Is there a way forward and if so what would it involve?
I'm guessing it's kernel perms that's preventing inteltool from dumping GPIOs, might try with an early 5.x kernel and see if any different
I'm guessing it's kernel perms that's preventing inteltool from dumping GPIOs, might try with an early 5.x kernel and see if any different
That was a good guess. I got all the data from inteltool. Thanksfully I happened to have a bunch of old livecds lying around. Even though inteltool was compiled under Debian 10 using a 5.x kernel, it ran just fine under Fedora 29 with a 4.x kernel. A welcome surprise.
So is that all I need to configure my motherboard to use coreboot?
CPU: ID 0x806ec, Processor Type 0x0, Family 0x6, Model 0x8e, Stepping 0xc Northbridge: 8086:9b61 (10th generation (Comet Lake family) Core Processor (Mobile)) Southbridge: 8086:0284 (Comet Point-LP U Premium/Cometlake) IGD: 8086:9b41 (Intel(R) UHD Graphics) SBREG_BAR = 0xfd000000 (MEM)
============= GPIOS =============
------- GPIO Community 0 -------
PCR Port ID: 0x6e0000
------- GPIO Group GPP_A ------- 0x0600: 0x0000001884000100 GPP_A0 GPIO 0x0610: 0x0000301944000b00 GPP_A1 ESPI_IO0 0x0620: 0x0000301a44000b02 GPP_A2 ESPI_IO1 0x0630: 0x0000301b44000b00 GPP_A3 ESPI_IO2 0x0640: 0x0000301c44000b00 GPP_A4 ESPI_IO3 0x0650: 0x0000301d44000b00 GPP_A5 ESPI_CS0# 0x0660: 0x0000001e84000602 GPP_A6 SERIRQ 0x0670: 0x0000001f44000300 GPP_A7 GPIO 0x0680: 0x0000002044000300 GPP_A8 GPIO 0x0690: 0x0000102144000b00 GPP_A9 ESPI_CLK 0x06a0: 0x0000002244000300 GPP_A10 GPIO 0x06b0: 0x0000002344000300 GPP_A11 GPIO 0x06c0: 0x0000002444000300 GPP_A12 GPIO 0x06d0: 0x0000002544000300 GPP_A13 GPIO 0x06e0: 0x0000002644000b00 GPP_A14 ESPI_RESET# 0x06f0: 0x0000002704000201 GPP_A15 GPIO 0x0700: 0x0000002844000300 GPP_A16 GPIO 0x0710: 0x0000002944000600 GPP_A17 SD_VDD1_PWR_EN# 0x0720: 0x0000002a44000300 GPP_A18 GPIO 0x0730: 0x0000002b44000300 GPP_A19 GPIO 0x0740: 0x0000002c44000300 GPP_A20 GPIO 0x0750: 0x0000002d44000300 GPP_A21 GPIO 0x0760: 0x0000002e44000300 GPP_A22 GPIO 0x0770: 0x0000002f44000300 GPP_A23 GPIO 0x0780: 0x0000000044000700 ESPI_CLK_LOOPBK ESPI_CLK_LOOPBK ------- GPIO Group GPP_B ------- 0x0790: 0x0000003044000300 GPP_B0 GPIO 0x07a0: 0x0000003144000300 GPP_B1 GPIO 0x07b0: 0x0000003284000200 GPP_B2 GPIO 0x07c0: 0x0000003344000102 GPP_B3 GPIO 0x07d0: 0x0000003484000201 GPP_B4 GPIO 0x07e0: 0x0000003544000700 GPP_B5 SRCCLKREQ0# 0x07f0: 0x0000003644000300 GPP_B6 GPIO 0x0800: 0x0000003744000700 GPP_B7 SRCCLKREQ2# 0x0810: 0x0000003844000702 GPP_B8 SRCCLKREQ3# 0x0820: 0x0000003944000702 GPP_B9 SRCCLKREQ4# 0x0830: 0x0000003a44000702 GPP_B10 SRCCLKREQ5# 0x0840: 0x0000003b44000300 GPP_B11 GPIO 0x0850: 0x0000003c44000700 GPP_B12 SLP_S0# 0x0860: 0x0000003d44000700 GPP_B13 PLTRST# 0x0870: 0x0000003e44000700 GPP_B14 SPKR 0x0880: 0x0000003f44000300 GPP_B15 GPIO 0x0890: 0x0000004084000200 GPP_B16 GPIO 0x08a0: 0x0000004144000300 GPP_B17 GPIO 0x08b0: 0x0000004244000300 GPP_B18 GPIO 0x08c0: 0x0000004384000201 GPP_B19 GPIO 0x08d0: 0x0000004442020102 GPP_B20 GPIO 0x08e0: 0x0000004544000300 GPP_B21 GPIO 0x08f0: 0x0000004644000300 GPP_B22 GPIO 0x0900: 0x0000004744000300 GPP_B23 GPIO 0x0910: 0x0000000044000700 GSPI0_CLK_LOOPBK GSPI0_CLK_LOOPBK 0x0920: 0x0000000044000700 GSPI1_CLK_LOOPBK GSPI1_CLK_LOOPBK ------- GPIO Group GPP_G ------- 0x0930: 0x00003c6c84000702 GPP_G0 SD_CMD 0x0940: 0x00003c6d84000702 GPP_G1 SD_DATA0 0x0950: 0x00003c6e84000702 GPP_G2 SD_DATA1 0x0960: 0x00003c6f84000702 GPP_G3 SD_DATA2 0x0970: 0x00003c7084000702 GPP_G4 SD_DATA3 0x0980: 0x0000307184000702 GPP_G5 SD3_CD# 0x0990: 0x00003c7284000700 GPP_G6 SD3_CLK 0x09a0: 0x0000307384000702 GPP_G7 SD3_WP ------- GPIO Group SPI ------- 0x09b0: 0x00003c1840000700 SPI0_IO_2 SPI0_IO_2 0x09c0: 0x00003c1940000700 SPI0_IO_3 SPI0_IO_3 0x09d0: 0x00003c1a40000700 SPI0_MISO SPI0_MISO 0x09e0: 0x00003c1b40000700 SPI0_MOSI SPI0_MOSI 0x09f0: 0x00003c1c40000700 SPI0_CS2_B SPI0_CS2# 0x0a00: 0x00003c1d40000700 SPI0_CS0_B SPI0_CS0# 0x0a10: 0x00003c1e40000700 SPI0_CS1_B SPI0_CS1# 0x0a20: 0x00003c1f40000700 SPI0_CLK SPI0_CLK 0x0a30: 0x0000000040000700 SPI0_CLK_LOOPBK SPI0_CLK_LOOPBK ------- GPIO Community 1 -------
PCR Port ID: 0x6d0000
------- GPIO Group GPP_D ------- 0x0600: 0x0000006082840102 GPP_D0 GPIO 0x0610: 0x0000006144000300 GPP_D1 GPIO 0x0620: 0x0000006244000300 GPP_D2 GPIO 0x0630: 0x0000006344000300 GPP_D3 GPIO 0x0640: 0x0000006444000102 GPP_D4 GPIO 0x0650: 0x0000006544000300 GPP_D5 GPIO 0x0660: 0x0000006644000300 GPP_D6 GPIO 0x0670: 0x0000006744000702 GPP_D7 ISH_I2C1_SDA 0x0680: 0x0000006844000702 GPP_D8 ISH_I2C1_SCL 0x0690: 0x0000006944000201 GPP_D9 GPIO 0x06a0: 0x0000006a80100102 GPP_D10 GPIO 0x06b0: 0x0000006b44000300 GPP_D11 GPIO 0x06c0: 0x0000006c44000300 GPP_D12 GPIO 0x06d0: 0x0000006d84000201 GPP_D13 GPIO 0x06e0: 0x0000006e44000300 GPP_D14 GPIO 0x06f0: 0x0000006f44000300 GPP_D15 GPIO 0x0700: 0x0000007044000102 GPP_D16 GPIO 0x0710: 0x0000007144000700 GPP_D17 DMIC_CLK1 0x0720: 0x0000007244000700 GPP_D18 DMIC_DATA1 0x0730: 0x0000007384000700 GPP_D19 DMIC_CLK0 0x0740: 0x0000007484000700 GPP_D20 DMIC_DATA0 0x0750: 0x0000007544000102 GPP_D21 GPIO 0x0760: 0x0000007644000102 GPP_D22 GPIO 0x0770: 0x0000007744000300 GPP_D23 GPIO 0x0780: 0x0000000044000700 GSPI2_CLK_LOOPBK GSPI2_CLK_LOOPBK ------- GPIO Group GPP_F ------- 0x0790: 0x0000003084000102 GPP_F0 GPIO 0x07a0: 0x0000003144000300 GPP_F1 GPIO 0x07b0: 0x0000003244000300 GPP_F2 GPIO 0x07c0: 0x0000003384000100 GPP_F3 GPIO 0x07d0: 0x0000003444000700 GPP_F4 CNV_BRI_DT 0x07e0: 0x0000303544000702 GPP_F5 CNV_BRI_RSP 0x07f0: 0x0000003644000700 GPP_F6 CNV_RGI_DT 0x0800: 0x0000303744000702 GPP_F7 CNV_RGI_RSP 0x0810: 0x0000003884000100 GPP_F8 GPIO 0x0820: 0x0000003984000102 GPP_F9 GPIO 0x0830: 0x0000003a84000102 GPP_F10 GPIO 0x0840: 0x0000003b44000300 GPP_F11 GPIO 0x0850: 0x0000003c44000300 GPP_F12 GPIO 0x0860: 0x0000003d44000300 GPP_F13 GPIO 0x0870: 0x0000003e44000300 GPP_F14 GPIO 0x0880: 0x0000003f44000300 GPP_F15 GPIO 0x0890: 0x0000004044000300 GPP_F16 GPIO 0x08a0: 0x0000004144000300 GPP_F17 GPIO 0x08b0: 0x0000004244000300 GPP_F18 GPIO 0x08c0: 0x0000004344000300 GPP_F19 GPIO 0x08d0: 0x0000004444000300 GPP_F20 GPIO 0x08e0: 0x0000004544000300 GPP_F21 GPIO 0x08f0: 0x0000004644000300 GPP_F22 GPIO 0x0900: 0x0000004784000100 GPP_F23 GPIO ------- GPIO Group GPP_H ------- 0x0910: 0x0000004844000300 GPP_H0 GPIO 0x0920: 0x0000004944000f00 GPP_H1 CNV_RF_RESET# 0x0930: 0x0000004a44000f00 GPP_H2 MODEM_CLKREQ 0x0940: 0x0000004b44000300 GPP_H3 GPIO 0x0950: 0x0000004c44000300 GPP_H4 GPIO 0x0960: 0x0000004d44000300 GPP_H5 GPIO 0x0970: 0x0000004e44000300 GPP_H6 GPIO 0x0980: 0x0000004f44000300 GPP_H7 GPIO 0x0990: 0x0000005044000300 GPP_H8 GPIO 0x09a0: 0x0000005184000200 GPP_H9 GPIO 0x09b0: 0x0000005244000300 GPP_H10 GPIO 0x09c0: 0x0000005344000300 GPP_H11 GPIO 0x09d0: 0x0000005484000102 GPP_H12 GPIO 0x09e0: 0x0000005584000102 GPP_H13 GPIO 0x09f0: 0x0000005684000100 GPP_H14 GPIO 0x0a00: 0x0000005784000100 GPP_H15 GPIO 0x0a10: 0x0000005884000201 GPP_H16 GPIO 0x0a20: 0x0000005944000300 GPP_H17 GPIO 0x0a30: 0x0000005a44000300 GPP_H18 GPIO 0x0a40: 0x0000005b44000300 GPP_H19 GPIO 0x0a50: 0x0000005c44000300 GPP_H20 GPIO 0x0a60: 0x0000005d44000300 GPP_H21 GPIO 0x0a70: 0x0000005e44000300 GPP_H22 GPIO 0x0a80: 0x0000005f44000300 GPP_H23 GPIO ------- GPIO Group VGPIO ------- 0x0a90: 0x0000000044000200 CNV_BTEN GPIO 0x0aa0: 0x0000000044000000 CNV_GNEN GPIO 0x0ab0: 0x0000000044000000 CNV_WFEN GPIO 0x0ac0: 0x0000000044000003 CNV_WCEN GPIO 0x0ad0: 0x0000007444000102 CNV_BT_HOST_WAKE_B GPIO 0x0ae0: 0x0000000044000003 CNV_BT_IF_SELECT GPIO 0x0af0: 0x0000000044000402 vCNV_BT_UART_TXD ISH UART0 0x0b00: 0x0000000044000400 vCNV_BT_UART_RXD ISH UART0 0x0b10: 0x0000000044000400 vCNV_BT_UART_CTS_B ISH UART0 0x0b20: 0x0000000044000402 vCNV_BT_UART_RTS_B ISH UART0 0x0b30: 0x0000000044000402 vCNV_MFUART1_TXD ISH UART0 0x0b40: 0x0000000044000400 vCNV_MFUART1_RXD ISH UART0 0x0b50: 0x0000000044000400 vCNV_MFUART1_CTS_B ISH UART0 0x0b60: 0x0000000044000402 vCNV_MFUART1_RTS_B ISH UART0 0x0b70: 0x0000000044000402 vCNV_GNSS_UART_TXD n/a 0x0b80: 0x0000000044000400 vCNV_GNSS_UART_RXD n/a 0x0b90: 0x0000000044000400 vCNV_GNSS_UART_CTS_B n/a 0x0ba0: 0x0000000044000402 vCNV_GNSS_UART_RTS_B n/a 0x0bb0: 0x0000000044000402 vUART0_TXD mapped 0x0bc0: 0x0000000044000400 vUART0_RXD mapped 0x0bd0: 0x0000000044000400 vUART0_CTS_B mapped 0x0be0: 0x0000000044000402 vUART0_RTS_B mapped 0x0bf0: 0x0000000044000402 vISH_UART0_TXD mapped 0x0c00: 0x0000000044000400 vISH_UART0_RXD mapped 0x0c10: 0x0000000044000400 vISH_UART0_CTS_B mapped 0x0c20: 0x0000000044000402 vISH_UART0_RTS_B mapped 0x0c30: 0x0000000044000402 vISH_UART1_TXD mapped 0x0c40: 0x0000000044000400 vISH_UART1_RXD mapped 0x0c50: 0x0000000044000400 vISH_UART1_CTS_B mapped 0x0c60: 0x0000000044000402 vISH_UART1_RTS_B mapped 0x0c70: 0x0000000044000400 vCNV_BT_I2S_BCLK SSP0 0x0c80: 0x0000000044000400 vCNV_BT_I2S_WS_SYNC SSP0 0x0c90: 0x0000000044000400 vCNV_BT_I2S_SDO SSP0 0x0ca0: 0x0000000044000400 vCNV_BT_I2S_SDI SSP0 0x0cb0: 0x0000000044000400 vSSP2_SCLK mapped 0x0cc0: 0x0000000044000402 vSSP2_SFRM mapped 0x0cd0: 0x0000000044000400 vSSP2_TXD mapped 0x0ce0: 0x0000000044000400 vSSP2_RXD n/a 0x0cf0: 0x0000007544000000 vCNV_GNSS_HOST_WAKE_B GPIO 0x0d00: 0x0000007646000102 vSD3_CD_B GPIO ------- GPIO Community 2 -------
PCR Port ID: 0x6c0000
------- GPIO Group GPD ------- 0x0600: 0x0000006044000502 GPD0 BATLOW# 0x0610: 0x0000006144000500 GPD1 ACPRESENT 0x0620: 0x0000006204000702 GPD2 LAN_WAKE# 0x0630: 0x0000006304000502 GPD3 PRWBTN# 0x0640: 0x0000006404000600 GPD4 SLP_S3# 0x0650: 0x0000006504000600 GPD5 SLP_S4# 0x0660: 0x0000006604000600 GPD6 SLP_A# 0x0670: 0x0000006744000300 GPD7 GPIO 0x0680: 0x0000006804000600 GPD8 SUSCLK 0x0690: 0x0000006944000700 GPD9 SLP_WLAN# 0x06a0: 0x0000006a04000600 GPD10 SLP_S5# 0x06b0: 0x0000006b44000300 GPD11 GPIO 0x06c0: 0x0000000004000700 SLP_LAN_B SLP_LAN# 0x06d0: 0x0000002e04000700 SLP_SUS_B SLP_SUS# 0x06e0: 0x0000002f04000700 WAKE_B WAKE# 0x06f0: 0x0000003004000702 DRAM_RESET_B DRAM_RESET# ------- GPIO Community 3 -------
PCR Port ID: 0x6b0000
------- GPIO Group AZA ------- 0x0600: 0x0000002044000700 HDA_BCLK HDA_BCLK 0x0610: 0x0000002144000700 HDA_RST_B HDA_RST# 0x0620: 0x00003c2244000700 HDA_SYNC HDA_SYNC 0x0630: 0x00003c2344000700 HDA_SDO HDA_SDO 0x0640: 0x00003c2444000700 HDA_SDI0 HDA_SDI0 0x0650: 0x00003c2544000700 HDA_SDI1 HDA_SDI1 0x0660: 0x00003c2644000700 I2S1_SFRM I2S1_SFRM 0x0670: 0x00003c2744000700 I2S1_TXD I2S1_TXD ------- GPIO Group CPU ------- 0x0680: 0x00003c0044000700 HDACPU_SDI HDACPU_SDI 0x0690: 0x00003c0044000700 HDACPU_SDO HDACPU_SDO 0x06a0: 0x0000000044000700 HDACPU_SCLK HDACPU_SCLK 0x06b0: 0x0000000044000700 PM_SYNC PM_SYNC 0x06c0: 0x0000000044000700 PECI PECI 0x06d0: 0x0000000044000700 CPUPWRGD CPUPWRGD 0x06e0: 0x0000000044000702 THRMTRIP_B THRMTRIP# 0x06f0: 0x0000000044000700 PLTRST_CPU_B PLTRST_CPU# 0x0700: 0x0000000044000700 PM_DOWN PM_DOWN 0x0710: 0x0000100044000700 TRIGGER_IN TRIGGER_IN 0x0720: 0x0000100044000700 TRIGGER_OUT TRIGGER_OUT ------- GPIO Community 4 -------
PCR Port ID: 0x6a0000
------- GPIO Group GPP_C ------- 0x0600: 0x0000004844000702 GPP_C0 SMBCLK 0x0610: 0x0000004944000702 GPP_C1 SMBDATA 0x0620: 0x0000004a44000300 GPP_C2 GPIO 0x0630: 0x0000004b44000300 GPP_C3 GPIO 0x0640: 0x0000004c44000300 GPP_C4 GPIO 0x0650: 0x0000004d44000102 GPP_C5 GPIO 0x0660: 0x0000004e44000300 GPP_C6 GPIO 0x0670: 0x0000004f44000300 GPP_C7 GPIO 0x0680: 0x0000005084000702 GPP_C8 UART0_RXD 0x0690: 0x0000005184000700 GPP_C9 UART0_TXD 0x06a0: 0x0000005284000201 GPP_C10 GPIO 0x06b0: 0x0000005380100102 GPP_C11 GPIO 0x06c0: 0x0000005444000300 GPP_C12 GPIO 0x06d0: 0x0000005544000300 GPP_C13 GPIO 0x06e0: 0x0000005644000300 GPP_C14 GPIO 0x06f0: 0x0000005784000201 GPP_C15 GPIO 0x0700: 0x0000005844000702 GPP_C16 I2C0_SDA 0x0710: 0x0000005944000702 GPP_C17 I2C0_SCL 0x0720: 0x0000005a44000702 GPP_C18 I2C1_SDA 0x0730: 0x0000005b44000702 GPP_C19 I2C1_SCL 0x0740: 0x0000005c44000300 GPP_C20 GPIO 0x0750: 0x0000005d84000200 GPP_C21 GPIO 0x0760: 0x0000005e42100100 GPP_C22 GPIO 0x0770: 0x0000005f44000300 GPP_C23 GPIO ------- GPIO Group GPP_E ------- 0x0780: 0x0000001844000300 GPP_E0 GPIO 0x0790: 0x0000001944000300 GPP_E1 GPIO 0x07a0: 0x0000001a84000500 GPP_E2 SATAXPCIE2 0x07b0: 0x0000001b80000102 GPP_E3 GPIO 0x07c0: 0x0000001c44000300 GPP_E4 GPIO 0x07d0: 0x0000001d44000700 GPP_E5 SATA_DEVSLP1 0x07e0: 0x0000001e44000700 GPP_E6 SATA_DEVSLP2 0x07f0: 0x0000001f84000100 GPP_E7 GPIO 0x0800: 0x0000002084000700 GPP_E8 SATALED# 0x0810: 0x0000002184000200 GPP_E9 GPIO 0x0820: 0x0000002244000103 GPP_E10 GPIO 0x0830: 0x0000002384000200 GPP_E11 GPIO 0x0840: 0x0000002484000102 GPP_E12 GPIO 0x0850: 0x0000002544000700 GPP_E13 DDPB_HPD0 0x0860: 0x0000002644000700 GPP_E14 DDPC_HPD1 0x0870: 0x0000002780880102 GPP_E15 GPIO 0x0880: 0x0000002884000201 GPP_E16 GPIO 0x0890: 0x0000002944000702 GPP_E17 EDP_HPD 0x08a0: 0x0000002a44000700 GPP_E18 DPPB_CTRLCLK 0x08b0: 0x0000002b44000700 GPP_E19 DPPB_CTRLDATA 0x08c0: 0x0000002c44000300 GPP_E20 GPIO 0x08d0: 0x0000002d44000300 GPP_E21 GPIO 0x08e0: 0x0000002e44000300 GPP_E22 GPIO 0x08f0: 0x0000002f44000200 GPP_E23 GPIO ------- GPIO Group JTAG ------- 0x0900: 0x00003c0040000700 PCH_TDO PCH_TDO 0x0910: 0x00003c0040000700 PCH_JTAGX PCH_JTAGX 0x0920: 0x00003c0040000702 PROC_PRDY_B PROC_PRDY# 0x0930: 0x00003c0040000702 PROC_PREQ_B PROC_PREQ# 0x0940: 0x00003c0040000700 CPU_TRST_B CPU_TRST# 0x0950: 0x00003c0040000700 PCH_TDI PCH_TDI 0x0960: 0x00003c0040000700 PCH_TMS PCH_TMS 0x0970: 0x00003c0040000700 PCH_TCK PCH_TCK 0x0980: 0x00003c0040000700 ITP_PMODE ITP_PMODE ------- GPIO Group HVMOS ------- 0x0990: 0x0000002844000700 EDP_VDDEN EDP_VDDEN 0x09a0: 0x0000002944000700 EDP_BKLTEN EDP_BKLTEN 0x09b0: 0x0000002a44000700 EDP_BKLTCTL EDP_BKLTCTL 0x09c0: 0x0000002b44000702 SYS_PWROK SYS_PWROK 0x09d0: 0x0000002c44000702 SYS_RESET_B SYS_RESET# 0x09e0: 0x0000002d44000700 CL_RST_B CL_RST#
Am Thu, Sep 16, 2021 at 09:37:02AM -0500 schrieb Brian Milliron:
Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into the ME. If Bootguard enabled and keys fused, nothing can be done unfortunately.
I checked the BIOS. There was nothing specifically listed as "Bootguard" but all the BIOS protection options were turned off, including one listed as "Checked boot block on every boot". I'm guessing that means Bootguard is installed but not enabled. Is there another place to look to get a more accurate/detailed read on this?
May I suggest the best way forward would be to compile coreboot with debug options and go ahead and flash it. You will find out quickly where the issues are. Obviously backup your current rom !
I myself am quite new to coreboot, but have been able to sucessfully flash two yet unsupported boards to coreboot (with some problems remaining).
For an initial trial, the steps I took look like this:
- read vendor bios and extract descriptor.bin and me.bin from it (util/ifdtool -x vendor.bios) - look through src/mainboard for the most similar board you can identify (for me, in retrospective, the Intel reference board was a good choice) - create a new directory and modify Kconfig* accordingly - look through devicetree.cb and all *.c files and remove code not applicable to your board. In general, be careful with Voltage settings and such. My approach was to remove them when in doubt.
If you don't have serial on the platform, the next best option is to enable flash log and read back the rom after an boot attempt.
Send me an email if you need help doing these things, I would be glad to share my experience time permitting.
FSP (which contains both the MRC and PCH refcode) also does video init, and VBIOS isn't used on modern platforms. coreboot's native display init (libgfxinit) is preferred if available. The only bit you will likely need is the VBT, which you can get from Linux (or dump from vendor firmware, but often contains multiple copies).
How would I get hold of this?
# find /sys -name "*vbt" /sys/kernel/debug/dri/0/i915_vbt
best wishes,
Andreas
Is that module functional?
It refused to compile when I tried it for F2A85-M.
On 17/9/21 1:29 am, Andreas Bauer wrote:
If you don't have serial on the platform, the next best option is to enable flash log and read back the rom after an boot attempt.
Am Fri, Sep 17, 2021 at 08:28:33AM +1000 schrieb Keith Emery:
On 17/9/21 1:29 am, Andreas Bauer wrote:
If you don't have serial on the platform, the next best option is to enable flash log and read back the rom after an boot attempt.
Is that module functional?
It refused to compile when I tried it for F2A85-M.
Indeed it is, it worked just fine for me. Be careful not to confuse it with another similar sounding config option. This is what worked for me:
CONFIG_ELOG=y CONFIG_ELOG_DEBUG=y CONFIG_ELOG_CBMEM=y CONFIG_ELOG_BOOT_COUNT=y
CONFIG_BOOT_DEVICE_SPI_FLASH=y CONFIG_BOOT_DEVICE_MEMORY_MAPPED=y CONFIG_BOOT_DEVICE_SUPPORTS_WRITES=y
CONFIG_BOOTBLOCK_CONSOLE=y CONFIG_POSTCAR_CONSOLE=y CONFIG_SQUELCH_EARLY_SMP=y CONFIG_CONSOLE_CBMEM=y CONFIG_CONSOLE_SPI_FLASH=y CONFIG_CONSOLE_SPI_FLASH_BUFFER_SIZE=0x20000 CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 CONFIG_HWBASE_DEBUG_CB=y
(bootcount enabled also)
regards,
Andreas
On 16.09.21 17:29, Andreas Bauer wrote:
May I suggest the best way forward would be to compile coreboot with debug options and go ahead and flash it. You will find out quickly where the issues are. Obviously backup your current rom !
Not likely, but you can harm the hardware with such brute-force testing, see about GPIOs below.
I myself am quite new to coreboot, but have been able to sucessfully flash two yet unsupported boards to coreboot (with some problems remaining).
For an initial trial, the steps I took look like this:
- read vendor bios and extract descriptor.bin and me.bin from it (util/ifdtool -x vendor.bios)
Always good to keep a backup, but you don't need to extract these for coreboot. Just keep them where they are in flash, no need to extract /overwrite anything.
- look through src/mainboard for the most similar board you can identify (for me, in retrospective, the Intel reference board was a good choice)
- create a new directory and modify Kconfig* accordingly
- look through devicetree.cb and all *.c files and remove code not applicable to your board. In general, be careful with Voltage settings and such. My approach was to remove them when in doubt.
Very important are the GPIO configurations. Plural, as there may be configurations for multiple chips, not just the southbridge. Never copy GPIO config from another board. If you configure a pin as output by accident, you risk a short circuit.
Nico
Am Fri, Sep 17, 2021 at 01:18:53AM +0200 schrieb Nico Huber:
On 16.09.21 17:29, Andreas Bauer wrote:
May I suggest the best way forward would be to compile coreboot with debug options and go ahead and flash it. You will find out quickly where the issues are. Obviously backup your current rom !
Not likely, but you can harm the hardware with such brute-force testing, see about GPIOs below.
Thanks for that heads up. I guess I was just lucky, but when you don't have schematics, lack experience in hardware development and such, the best I could do was this "brute force" testing.
My impression was that the OP is in the same situation as I was (missing knowledge), and in my case I decided to go ahead and try and eventually archieved some success.
I did delete the GPIO config, though, and good for bringing that up as I failed to mention that.
- read vendor bios and extract descriptor.bin and me.bin from it (util/ifdtool -x vendor.bios)
Always good to keep a backup, but you don't need to extract these for coreboot. Just keep them where they are in flash, no need to extract /overwrite anything.
Well, if you want to clean the ME you obviously need that. I found it easier to always produce a complete image that can just be flashed as a whole.
regards,
Andreas
On 17.09.21 01:41, Andreas Bauer wrote:
Am Fri, Sep 17, 2021 at 01:18:53AM +0200 schrieb Nico Huber:
On 16.09.21 17:29, Andreas Bauer wrote:
May I suggest the best way forward would be to compile coreboot with debug options and go ahead and flash it. You will find out quickly where the issues are. Obviously backup your current rom !
Not likely, but you can harm the hardware with such brute-force testing, see about GPIOs below.
Thanks for that heads up. I guess I was just lucky, but when you don't have schematics, lack experience in hardware development and such, the best I could do was this "brute force" testing.
My impression was that the OP is in the same situation as I was (missing knowledge), and in my case I decided to go ahead and try and eventually archieved some success.
Don't worry, it's still what most people do. Even with documentation at hand not everything always works out, so we all resort to some trial-by- error at some point. I just wanted to point out that there is at least one point (GPIOs) to always be careful about ;)
I did delete the GPIO config, though, and good for bringing that up as I failed to mention that.
- read vendor bios and extract descriptor.bin and me.bin from it (util/ifdtool -x vendor.bios)
Always good to keep a backup, but you don't need to extract these for coreboot. Just keep them where they are in flash, no need to extract /overwrite anything.
Well, if you want to clean the ME you obviously need that. I found it easier to always produce a complete image that can just be flashed as a whole.
Yes, it can be useful eventually of course. But for a start and during coreboot development, we advice to change as little as possible outside of coreboot. Otherwise, it's hard to find out where a problem persists if something doesn't work.
Nico
On 16.09.21 16:37, Brian Milliron wrote:
Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into the ME. If Bootguard enabled and keys fused, nothing can be done unfortunately.
I checked the BIOS. There was nothing specifically listed as "Bootguard" but all the BIOS protection options were turned off, including one listed as "Checked boot block on every boot". I'm guessing that means Bootguard is installed but not enabled. Is there another place to look to get a more accurate/detailed read on this?
There are more mechanisms beside Intel BootGuard. HP usually uses their own tech called SureStart (at least on EliteBooks and up to maybe two years ago). SureStart seems to be differently implemented from time to time. One really has to look into it and try, I guess. AFAIR, there are implementations that you can get around by externally flashing a secon- dary chip.
the IFD and ME aren't needed strictly speaking, unless you need to modify them in some way. But you would extract those using ifdtool. Definitely don't want to use a non-board-specific ME downloaded from win-raid (eg) as the soft straps and clock mappings will not be correct for your board.
I intend on using me_cleaner to wipe all but a stub of the ME code, so having a working copy isn't something I'm too worried about as long as it passes the signature checks.
This "stub of the ME code" is what contains those board specific information. Never skip to configure the ME firmware unless you just keep the one that was shipped. This is recommended anyway during coreboot development, just never flash it (flashrom has options to only flash the BIOS region).
Nico
-
Andreas Bauer -
Brian Milliron -
Keith Emery -
Matt DeVillier -
Nico Huber