On Fri, Sep 17, 2021 at 12:57 PM Brian Milliron <[email protected]> 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 _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
