[coreboot] Boot order?
I have experimentet with coreboot on my CompuLab Intense PC (Ivy Bridge) for some time, and I think everything is working now, with Intel ME disabled. Although, I have some troubles with boot selection. I'm currently running coreboot [4cea00a64] with default SeaBIOS payload and a bootorder file. The boot device search order is this: 1. USB 2.0 device 2. USB 3.0 device 3. SATA devices (in order: 2.5″ internal, mSATA, eSATA, FACE module) During testing I have been running the system from a USB 3.0 flash disk. This worked as expected and system would automatically select this device during boot/reboot. I then wanted to use the internal 2.5" SATA disk, so I installed an OS and confirmed it working by manually selecting the SATA disk in boot menu. I then removed boot sector from flash disk, reboot and expected that the system would now automatically boot from internal SATA disk, but this happened instead: === Booting from Hard Disk... Boot failed: not a bootable disk Booting from Floppy... Boot failed: not a bootable disk No bootable device. Retrying in 60 seconds. === Not sure what is going on with "Floppy". No such thing exists on the system. If I remove flash disk from USB port before power on, the system will boot correctly from internal SATA disk. Is this correct behaviour? I would expect that it should not matter that flash disk is inserted in USB port, as long as no boot sector is present on the device. If this is NOT correct behaviour, then what could be the problem here? Thanks in advance. Regards, Mogens Jensen___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Debugging undetected SATA disk?
Thanks everyone for pointing me in the right direction, I didn't know about configuration data in ME. I did a quick comparison of the ICC profiles in the two ME images and found multiple differences. FCIM/BTM Specific ICC Registers: = Clock Source Select SRC Source Select PLL Reference Clock Select Divider Enable ICC Registers: = Flex Clock Source Select Output Clock Enable PI12BiasParms I need to do more research to find out what all this means, but in theory, if I update the new ME with same values as the old one, then I should have a working SATA disk? Regards, Mogens Jensen ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Debugging undetected SATA disk?
I have installed coreboot on my CompuLab Intense PC (Ivy Bridge). Intel ME blob was extracted from firmware image dump. This ME version (8.1.20.1336) contains multiple security vulnerabilites, so I have downloaded latest firmware update from vendor website extracted the ME (8.1.72.3002) and used that to build coreboot. However, after flashing updated rom, the SATA disk is no longer detected. The coreboot configuration is identical for both roms, only difference is the ME version. The SATA controller is detected in both cases by coreboot and Linux: SATA: Initializing... SATA: Controller in AHCI mode. 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) With newer ME, there are no errors, it's just like the SATA disk is not plugged in. I have compared output of cbmem, line by line in cronological order, from system booted by USB disk with working and non working SATA, cut out blocks with differences and marked them with a *. I don't know if this is a good way, please let me know if I should have done otherwise. SATA disk working: = Update PCI-E configuration space: PCI(0, 0, 0)[a0] = 0 PCI(0, 0, 0)[a4] = 2 * PCI(0, 0, 0)[bc] = 82a0 PCI(0, 0, 0)[a8] = 7b60 PCI(0, 0, 0)[ac] = 2 * PCI(0, 0, 0)[b8] = 8000 PCI(0, 0, 0)[b0] = 80a0 PCI(0, 0, 0)[b4] = 8080 PCI(0, 0, 0)[7c] = 7f PCI(0, 0, 0)[70] = fe00 PCI(0, 0, 0)[74] = 1 * PCI(0, 0, 0)[78] = fe000c00 = SATA disk NOT working: = Update PCI-E configuration space: PCI(0, 0, 0)[a0] = 0 PCI(0, 0, 0)[a4] = 4 * PCI(0, 0, 0)[bc] = 82a0 PCI(0, 0, 0)[a8] = 7b60 PCI(0, 0, 0)[ac] = 4 * PCI(0, 0, 0)[b8] = 8000 PCI(0, 0, 0)[b0] = 80a0 PCI(0, 0, 0)[b4] = 8080 PCI(0, 0, 0)[7c] = 7f PCI(0, 0, 0)[70] = fe00 PCI(0, 0, 0)[74] = 3 * PCI(0, 0, 0)[78] = fe000c00 = SATA disk working: = ME: FWS2: 0x161f012a * ME: Bist in progress: 0x0 ME: ICC Status : 0x1 * ME: Invoke MEBx : 0x1 ME: CPU replaced: 0x0 = SATA disk NOT working: = ME: FWS2: 0x161f012e * ME: Bist in progress: 0x0 ME: ICC Status : 0x3 * ME: Invoke MEBx : 0x1 ME: CPU replaced: 0x0 = SATA disk working: = PASSED! Tell ME that DRAM is ready ME: FWS2: 0x1650012e * ME: Bist in progress: 0x0 ME: ICC Status : 0x3 * ME: Invoke MEBx : 0x1 ME: CPU replaced: 0x0 = SATA disk NOT working: = PASSED! Tell ME that DRAM is ready ME: FWS2: 0x1650012a * ME: Bist in progress: 0x0 ME: ICC Status : 0x1 * ME: Invoke MEBx : 0x1 ME: CPU replaced: 0x0 = SATA disk working: = memcfg channel assignment: A: 1, B 0, C 2 * memcfg channel[0] config (): * ECC inactive enhanced interleave mode off * rank interleave off * DIMMA 0 MB width x8 single rank, selected * DIMMB 0 MB width x8 single rank = SATA disk NOT working: = memcfg channel assignment: A: 0, B 1, C 2 * memcfg channel[0] config (00620020): * ECC inactive enhanced interleave mode on * rank interleave on * DIMMA 8192 MB width x8 dual rank, selected * DIMMB 0 MB width x8 single rank = SATA disk working: = PCH: Remap PCIe function 4 to 3 PCI: 00:1c.4 [8086/1e18] enabled PCI: 00:1c.5: Disabling device PCI: 00:1c.6: Disabling device PCI: 00:1c.6 [8086/1e1c] disabled * PCI: 00:1c.7: Disabling device = SATA disk NOT working: = PCH: Remap PCIe function 4 to 3 PCI: 00:1c.4 [8086/1e18] enabled PCI: 00:1c.5: Disabling device PCI: 00:1c.6: Disabling device * PCI: 00:1c.7: Disabling device = SATA disk working: = PCI: Leftover static devices: PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.5 * PCI: 00:1c.7 PCI: Check your devicetree.cb. = SATA disk NOT working: = PCI: Leftover static devices: PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.5 PCI: 00:1c.6 * PCI: 00:1c.7 PCI: Check your devicetree.cb. = SATA disk working: = Available memory below 4GB: 2048M Available memory above 4GB: 6070M * = SATA disk NOT working: = Available memory below 4GB: 2048M Available memory above 4GB: 14262M * = SATA disk working: = CPU physical address size: 36 bits MTRR: default type WB/UC MTRR counts: 4/4. * MTRR: UC selected as default type. * = SAT
[coreboot] Re: No video output?
Hello Jose, Thanks, you must have missed my reply to the thread a few days back. Everything is working perfectly now, I had to disable VGA_BIOS as you also suggests. Regards, Mogens Jensen ‐‐‐ Original Message ‐‐‐ On Tuesday, January 28, 2020 5:01 PM, Jose Trujillo wrote: > Hello Mogens, > > If you want to use LIBGFXINIT please disable VGA_BIOS and for SeaBIOS choose > "Legacy VGA text mode" as framebuffer mode in "Display". > > Let us know if the problem remains after this. > > Jose Trujillo. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, January 23, 2020 12:41 PM, Mogens Jensen via coreboot > coreboot@coreboot.org wrote: > > > I have compiled coreboot from master branch (63fd650e2e) and flashed it to > > a CompuLab Intense PC following this guide: > > https://watchmysys.com/blog/2017/12/coreboot-compulab-intense-pc-mintbox/ > > My problem is that video ouput is missing during POST, only after Linux > > kernel starts booting, video output become available. This problem is > > described in the guide and the solution is to include Intel VGA BIOS, which > > I have done, but still no video ouput before Linux kernel. > > The guide is two years old, maybe something has changed in coreboot since > > then, so more steps are required to get the video working? > > This is my defconfig: > > CONFIG_USE_BLOBS=y > > CONFIG_VENDOR_COMPULAB=y > > CONFIG_VGA_BIOS=y > > CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbios.rom" > > CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbt.rom" > > CONFIG_ENABLE_MSATA=y > > CONFIG_DRIVERS_INTEL_WIFI is not set > > = > > CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_0_flashdescriptor.bin" > > CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_2_intel_me.bin" > > CONFIG_GBE_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_3_gbe.bin" > > CONFIG_HAVE_IFD_BIN=y > > CONFIG_HAVE_ME_BIN=y > > CONFIG_CHECK_ME=y > > CONFIG_HAVE_GBE_BIN=y > > CONFIG_MAINBOARD_USE_LIBGFXINIT=y > > CONFIG_INTEL_GMA_ADD_VBT=y > > CONFIG_SEABIOS_BOOTORDER_FILE="bootorder.txt" > > Any ideas on what I could be doing wrong? > > Regards, > > Mogens Jensen > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: ME extracted from vendor BIOS update?
On Sunday, January 26, 2020 3:34 PM, Simon Newton wrote: > Have you considered different permutations of me_cleaner - for example using > the AltMeDisable/HAP switch instead of the partition removal method? i tend > to do both the partition removal and the altme/hap switch, but some > motherboards simply dont like partitions removed.In those cases, ive used > HAP/altMEdisable and ME has stayed inoperative. Theres a reason a certain > three letter agency asked for that switch to be there for their high > assurance platform. Id be surprised if the HAP switch setting didnt work - > try the lowercase -s switch. > > Another area to consider would be whitelisting some FTPR modules when running > me_cleaner and see if that resolves the issue with SATA, if you really have > to run the partition removal method. Some of my mobos require --whitelist > EFFS,FCRS > >> > > -- > Kind Regards, > > Simon Newton > > E: simon.new...@gmail.com I have not tried to run me_cleaner on the blob myself, I got the information on broken SATA from the me_cleaner GitHub bug report. I rely on internal programmer, so I have not made too many experiments in fear of bricking the system. But if system still boots from USB after messing with ME, I can make some experiments with me_cleaner, as a disable ME would be better than anything else. Regards, Mogens Jensen___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: ME extracted from vendor BIOS update?
‐‐‐ Original Message ‐‐‐ On Sunday, January 26, 2020 9:59 AM, Benjamin Doron wrote: > As I understand it, the BIOS image simply has space reserved for ME in the > descriptor, which is what ifdtool can find. If me_cleaner or MEAnalyzer are > fine with 81723002.ME, provide it and the descriptor to coreboot. I don't > know about gbe so I can't comment on that. > > The paths start at the root of the tree. The default ME location is > "3rdparty/blobs/$(MAINBOARDDIR)/me.bin", so try putting 81723002.ME there. You're right. I don't know what went wrong, but I must have made a mistake as coreboot now compiles fine with 81723002.ME after trying one more time.___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] ME extracted from vendor BIOS update?
When compiling coreboot for my Intense PC, I used binary blobs extracted from stock firmware. The ME/TXE firmware version is 8.1.20.1336 and this contains multiple security vulnerabilities. Unfortunately, running me_cleaner on ME blob breaks SATA [1], so next best thing is updating to latest ME blob released by CompuLab. However, this seems not so straight forward. Latest BIOS update for Intense PC was downloaded from here: https://fit-iot.com/files/download/intense-pc/bios/16-04-2018/ipc_2.2.400.5.img.zip I unpacked and mounted the image like this: # mount -o loop,offset=16384 ipc_2.2.400.5.img /mnt/ This is the interesting files found in /mnt/ afterwards: 81723002.ME (7843840 bytes) BIOS_IMG.bin (16777216 bytes) I tried to extract intel fd modules from BIOS_IMG.bin: $ ifdtool -x BIOS_IMG.bin File BIOS_IMG.bin is 16777216 bytes Flash Region 0 (Flash Descriptor): - 0fff Flash Region 1 (BIOS): 00d0 - 00ff Flash Region 2 (Intel ME): 3000 - 00cf Flash Region 3 (GbE): 1000 - 2fff Flash Region 4 (Platform Data): 00fff000 - 0fff (unused) However flashregion_2_intel_me.bin is just an empty file and the ME data is in 81723002.ME: $ hexdump flashregion_2_intel_me.bin 000 * 0cfd000 $ me_cleaner.py --check 81723002.ME ME/TXE image detected Found FPT header at 0x10 Found 23 partition(s) Found FTPR header: FTPR partition spans from 0x18 to 0x24a000 ME/TXE firmware version 8.1.72.3002 Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x Checking the FTPR RSA signature... VALID Setting location of 81723002.ME in CONFIG_ME_BIN_PATH during configuration of coreboot seems not to work. Another important thing I found in coreboot documentation: "Warning: Sandybridge Chipsets need a matching ME blob and IFD ! The board won't boot at all if one of them is invalid." So if I understand correctly, I have to compile coreboot with the following files extracted from ipc_2.2.400.5.img: flashregion_0_flashdescriptor.bin flashregion_2_intel_me.bin 81723002.ME The flashregion_3_gbe.bin extracted from stock firmware, also used when compiling coreboot the first time. Does this sound right? Also, what is the correct way to convert 81723002.ME into the proper flashregion_2_intel_me.bin? Thanks in advance! Regards, Mogens Jensen [1]: https://github.com/corna/me_cleaner/issues/119 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: No video output?
‐‐‐ Original Message ‐‐‐ On Saturday, January 25, 2020 10:01 AM, Paul Menzel wrote: > Dear Mogens, > > Am 25.01.20 um 08:15 schrieb Mogens Jensen via coreboot: > > […] > > > Thanks for your help. Both the suggestions you provided made video > > output work. I prefer to use the open-source libgfxinit option so I > > need one blob less. > > My Intense PC is now running latest coreboot, I can use the boot menu > > etc. and the things I have tested so far seems to work. Very cool. > > These are good news. > > Could you please upload the logs to the board status repository [1]? > Please make sure `git describe --tags --dirty` shows a clean version, > and the commit you use is in the master branch, that means, no local > changes, and rebuild `cbmem`. If you disable the serial console, then > we’d also get the time-stamps not slowed down by transmitting messages > over the slow serial connection. > > Kind regards, > > Paul > > [1]: > https://review.coreboot.org/cgit/coreboot.git/tree/util/board_status/README Hello Paul, Yes, no problem, I will try to upload the logs. Regards, Mogense Jensen ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: No video output?
‐‐‐ Original Message ‐‐‐ On Thursday, January 23, 2020 10:01 AM, Nico Huber wrote: > Hello Mogens, > > On 23.01.20 10:41, Mogens Jensen via coreboot wrote: > > > The guide is two years old, maybe something has changed in coreboot since > > then, so more steps are required to get the video working? > > or maybe less steps are required. coreboot has an open-source graphics- > init option for this board (libgfxinit). I'm not sure if it was tested > for the Intense PC. But please try: Remove the VBIOS, and make sure you > have these in your .config: > > CONFIG_MAINBOARD_USE_LIBGFXINIT=y > CONFIG_SEABIOS_VGA_COREBOOT=y > > If that doesn't work, keep the VBIOS and make sure to have > > CONFIG_NO_GFX_INIT=y > > Otherwise coreboot and SeaBIOS would both try to init graphics. I guess > this is what is going wrong with your current config. > > If libgfxinit doesn't work, and you want to help to get it running, you > can enable CONFIG_DEBUG_ADA_CODE and fetch a log via `cbmem -c` once > Linux is running. > > Please report back in any case :) > > Nico Hello Nico Thanks for your help. Both the suggestions you provided made video output work. I prefer to use the open-source libgfxinit option so I need one blob less. My Intense PC is now running latest coreboot, I can use the boot menu etc. and the things I have tested so far seems to work. Very cool. Thanks again. Regards, Mogens Jensen ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] No video output?
I have compiled coreboot from master branch (63fd650e2e) and flashed it to a CompuLab Intense PC following this guide: https://watchmysys.com/blog/2017/12/coreboot-compulab-intense-pc-mintbox/ My problem is that video ouput is missing during POST, only after Linux kernel starts booting, video output become available. This problem is described in the guide and the solution is to include Intel VGA BIOS, which I have done, but still no video ouput before Linux kernel. The guide is two years old, maybe something has changed in coreboot since then, so more steps are required to get the video working? This is my defconfig: CONFIG_USE_BLOBS=y CONFIG_VENDOR_COMPULAB=y CONFIG_VGA_BIOS=y CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbios.rom" CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbt.rom" CONFIG_ENABLE_MSATA=y # CONFIG_DRIVERS_INTEL_WIFI is not set CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_0_flashdescriptor.bin" CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_2_intel_me.bin" CONFIG_GBE_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_3_gbe.bin" CONFIG_HAVE_IFD_BIN=y CONFIG_HAVE_ME_BIN=y CONFIG_CHECK_ME=y CONFIG_HAVE_GBE_BIN=y CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_INTEL_GMA_ADD_VBT=y CONFIG_SEABIOS_BOOTORDER_FILE="bootorder.txt" Any ideas on what I could be doing wrong? Regards, Mogens Jensen ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] CompuLab Intense PC?
I have a CompuLab Intense PC that has not been patched for CVE-2017-8083 (no CloseMnf protection mechanism for write protection of flash memory regions), which should allow me to install coreboot without an external programmer according to https://www.coreboot.org/Board:compulab/intense_pc So far I have successfully compiled coreboot from master branch, with binary blobs extracted from stock firmware. 1. The coreboot toolchain is built with command 'make crossgcc-i386 CPUS=$(nproc)' as shown in the tutorial, but my system is x86-64 so should I have used 'make crossgcc-x64' instead? 2. As I'm not using an external programmer to flash coreboot, is it correct to run flashrom like this 'flashrom -w coreboot.rom -p internal'? or do I need to pass more arguments? 3. In my configuration, this option is set by default: CONFIG_UNLOCK_FLASH_REGIONS=y, just to be sure, this will allow me to flash all regions, including ME, again without an external programmer after coreboot is installed? Regards, Mogens Jensen___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
