coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] Black screen during SeaBIOS boot
by awokd 15 Dec '17

15 Dec '17

On Fri, December 15, 2017 11:10 am, Daniel K wrote: > Starting up with coreboot and SeaBIOS, the screen is completely black for > around 30 seconds before my on-disc bootloader (grub2) is loaded and > displayed. > > I'm assuming SeaBIOS counts down with some timer before launching the > on-disc bootloader but I don't see anything. > > I want to use coreboot in text-mode so I'm not including a VGA rom. That might be why you are getting the delay. Try adding it and see. I ran into the delay too and think that's what fixed it. > According to lspci (attached), I have two VGA devices: You might need to edit src/device/Kconfig with: config MULTIPLE_VGA_ADAPTERS bool default y

2 1

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Zoran Stojsavljevic 15 Dec '17

15 Dec '17

> pretty sure the I is for Intel ;-) Sure. AMD has AME, as I recall. VIA has VME, Cyrix had CME, etc. ;-) It is ME, simple and plain. I(ntel)ME is a pleonasm (please, look on the Webster Dictionary what the pleonasm is?!). Zoran On Fri, Dec 15, 2017 at 6:18 PM, Matt DeVillier <matt.devillier(a)gmail.com> wrote: > On Fri, Dec 15, 2017 at 10:23 AM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> IME (I is typo) = ME . >> > > pretty sure the I is for Intel ;-) > > (or, at least that's how I've seen it referenced elsewhere) > > >> >> Zoran >> >

1 0

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Matt DeVillier 15 Dec '17

15 Dec '17

On Fri, Dec 15, 2017 at 10:23 AM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > IME (I is typo) = ME . > pretty sure the I is for Intel ;-) (or, at least that's how I've seen it referenced elsewhere) > > Zoran >

1 0

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Zoran Stojsavljevic 15 Dec '17

15 Dec '17

IME (I is typo) = ME . Zoran On Fri, Dec 15, 2017 at 5:14 PM, Gregg Levine <gregg.drwho8(a)gmail.com> wrote: > Hello! > (I'm working from the office today on a library computer...) > My regular laptop might be wearing one of those dratted things. But > before we start confusing people further, perhaps one of the group > needs to reiterate exactly what that contraption is, and why it was > necessary. Oh and what the cleaner is supposed to do, and why machines > who were cleaned of it, may not work correctly, or even may. > > I've got an interesting idea that I do know what it does, and why, but > there must be a few people there who're confused about what the IME is > and isn't. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > > On Fri, Dec 15, 2017 at 10:00 AM, Philipp Stanner <stanner(a)posteo.de> > wrote: > > Thanks. > > > > They didn't seriously include a Java Runtime Environment into the IME?? > > I can't believe what's going on with this company. > > > > Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen: > >> For those who are interested in the Intel ME, the slides and white > >> papers > >> from the Black Hat Europe are public. > >> > >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H > >> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel- > >> Management-Engine.pdf > >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H > >> ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel- > >> Management-Engine-wp.pdf > >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME > >> -Flash-File-System-Explained.pdf > >> https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME > >> -Flash-File-System-Explained-wp.pdf > >> > >> In the conclusion they say "[...]. Such a vulnerability has the > >> potential to > >> jeopardize a number of technologies, including [...] Intel Boot > >> Guard > >> [...]. > >> > >> Maybe it's possible to deactivate Boot Guard permanently or inject > >> custom > >> keys to run own firmware. > >> > >> > >> On 08.12.2017 15:40, Alberto Bursi wrote: > >> > On 12/08/2017 02:59 PM, Timothy Pearson wrote: > >> > > > >> > > That's just the HAP bit. The ME is limited but NOT disabled, and > >> > > the > >> > > remaining stubs are still hackable [1]. > >> > > > >> > > Neither the ME or the PSP can ever be removed from their > >> > > respective > >> > > systems. They can both be limited to some extent, but to call > >> > > either > >> > > of > >> > > them "disabled" is rather far from the truth. > >> > > > >> > > > >> > > >> > Hacking them requires being able to write in the SPI flash, or to > >> > have > >> > buggy UEFI firmware. Which means most systems are still vulnerable. > >> > > >> > But it is also true that if someone can hack UEFI he pwns you > >> > anyway, > >> > even without ME. > >> > > >> > So imho ME with the HAP bit can be called "disabled", although the > >> > fight > >> > isn't over as ME isn't the only thing that was a threat anyway. > >> > > >> > There is still need to secure the UEFI firmware (which is needed > >> > even > >> > if > >> > ME didn't exist), and doing a hardware mod to have a hardware > >> > switch to > >> > turn the SPI chip read-only at the hardware level (also needed > >> > regardless of ME). > >> > > >> > I think many SPI chips only need some pin pulled high/low to go in > >> > read-only mode, and I frankly trust a dumb switch many orders of > >> > magnitude more than Boot Guard or anything software-based. > >> > > >> > -Alberto > >> > >> > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Thomas Heijligen 15 Dec '17

15 Dec '17

For those who are interested in the Intel ME, the slides and white papers from the Black Hat Europe are public. https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-… https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-… https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash… https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash… In the conclusion they say "[...]. Such a vulnerability has the potential to jeopardize a number of technologies, including [...] Intel Boot Guard [...]. Maybe it's possible to deactivate Boot Guard permanently or inject custom keys to run own firmware. On 08.12.2017 15:40, Alberto Bursi wrote: > On 12/08/2017 02:59 PM, Timothy Pearson wrote: >> >> That's just the HAP bit. The ME is limited but NOT disabled, and the >> remaining stubs are still hackable [1]. >> >> Neither the ME or the PSP can ever be removed from their respective >> systems. They can both be limited to some extent, but to call either >> of >> them "disabled" is rather far from the truth. >> >> > > Hacking them requires being able to write in the SPI flash, or to have > buggy UEFI firmware. Which means most systems are still vulnerable. > > But it is also true that if someone can hack UEFI he pwns you anyway, > even without ME. > > So imho ME with the HAP bit can be called "disabled", although the > fight > isn't over as ME isn't the only thing that was a threat anyway. > > There is still need to secure the UEFI firmware (which is needed even > if > ME didn't exist), and doing a hardware mod to have a hardware switch to > turn the SPI chip read-only at the hardware level (also needed > regardless of ME). > > I think many SPI chips only need some pin pulled high/low to go in > read-only mode, and I frankly trust a dumb switch many orders of > magnitude more than Boot Guard or anything software-based. > > -Alberto

6 5

Re: [coreboot] Lenovo G505s AMD Hardware Virtualization
by awokd 15 Dec '17

15 Dec '17

On Fri, December 15, 2017 10:00 am, Ivan Ivanov wrote: > awokd, could you please answer some questions: > > 1) From where you got that 0x06001119 microcode patch? > Is it a trusted source of a microcode? (hope its directly from AMD) > > > 2) Is there any way to determine that 0x06001119 is really the latest > microcode? Or there could be more recent versions available? 1) I got it by executing the following on a Debian Stretch install: dd skip=5284 iflag=skip_bytes if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin of=amd.bin xxd -i amd.bin Then copying and pasting. Executing these steps against coreboot/3rdparty/blobs/cpu/amd/family_15h/microcode_amd_fam15h.bin provides identical results. 2) It's internally dated July 13, 2012. There's another ucode for a different processor in the same microcode_amd_fam15h.bin file dated 2016, so I'm assuming there is not a newer version available for this processor or the maintainer would have updated it at the same time. There could still be one somewhere, but I was having trouble tracking down any information at all on these different patch levels. It looks like the microcode_amd_fam15h.bin that ships with coreboot is slightly out of date. The blob dated 2016 in the Debian distro is dated 2014 in here. I'll try to research why and submit an update if there's no obvious reason not to. > > 2017-12-12 6:21 GMT+03:00 Taiidan(a)gmx.com <Taiidan(a)gmx.com>: >> I am not sure how to do a commit, but I hope you are able to find out >> as you will have helped a lot of people. I did figure it out: https://review.coreboot.org/#/c/22843/ >> I am pleased with myself for noticing that the lack of microcode >> updates was the issue - as the CPU is similar to a piledriver not a >> bulldozer it requires microcode for IOMMU. Thank you for pointing this out! Definitely helped. >> I do not have the technical documents for that chipset and I do not >> know how to change the PCI regs but I am sure the USB controllers >> support FLR considering the nearly identical SR56xx chipsets usb >> controllers do - I will look in to this further. There is something strange going on with interrupt remapping on these USB controllers too. Might be a Qubes regression, still investigating... PS Pls. note email change.

1 0

Black screen during SeaBIOS boot
by Daniel K 15 Dec '17

15 Dec '17

Hello, I'm having an issue with coreboot and was wondering if someone could help me. Starting up with coreboot and SeaBIOS, the screen is completely black for around 30 seconds before my on-disc bootloader (grub2) is loaded and displayed. I'm assuming SeaBIOS counts down with some timer before launching the on-disc bootloader but I don't see anything. I want to use coreboot in text-mode so I'm not including a VGA rom. After the 30 seconds of blackness, my on-disc bootloader becomes visible. According to lspci (attached), I have two VGA devices: 01:01.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 10) -> Onboard VGA (Aspeed AST2050 8MB) 05:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 570] (rev a1) -> PCIe video card (EVGA GTX 570) However it doesn't look like PCI device 05:00.0 is initialised in the SeaBIOS/cbmem console output: Show all devs... After init. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: 0000: enabled 1 PCI: 00:18.0: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:00.1: enabled 0 PCI: 00:00.2: enabled 1 PCI: 00:02.0: enabled 1 PCI: 00:03.0: enabled 0 PCI: 00:04.0: enabled 1 PCI: 00:05.0: enabled 0 PCI: 00:06.0: enabled 0 PCI: 00:07.0: enabled 0 PCI: 00:08.0: enabled 0 PCI: 00:09.0: enabled 1 PCI: 00:0a.0: enabled 1 PCI: 00:0b.0: enabled 1 PCI: 00:0c.0: enabled 1 PCI: 00:0d.0: enabled 1 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 1 PCI: 00:12.1: enabled 1 PCI: 00:12.2: enabled 1 PCI: 00:13.0: enabled 1 PCI: 00:13.1: enabled 1 PCI: 00:13.2: enabled 1 PCI: 00:14.0: enabled 1 I2C: 01:50: enabled 1 I2C: 01:51: enabled 1 I2C: 01:52: enabled 1 I2C: 01:53: enabled 1 I2C: 01:54: enabled 1 I2C: 01:55: enabled 1 I2C: 01:56: enabled 1 I2C: 01:57: enabled 1 I2C: 01:2f: enabled 1 PCI: 00:14.1: enabled 1 PCI: 00:14.2: enabled 1 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.1: enabled 0 PNP: 002e.2: enabled 1 PNP: 002e.3: enabled 1 PNP: 002e.5: enabled 1 PNP: 002e.106: enabled 0 PNP: 002e.107: enabled 0 PNP: 002e.207: enabled 0 PNP: 002e.307: enabled 0 PNP: 002e.407: enabled 0 PNP: 002e.8: enabled 0 PNP: 002e.108: enabled 0 PNP: 002e.9: enabled 0 PNP: 002e.109: enabled 0 PNP: 002e.209: enabled 0 PNP: 002e.309: enabled 0 PNP: 002e.a: enabled 1 PNP: 002e.b: enabled 1 PNP: 002e.c: enabled 0 PNP: 002e.d: enabled 0 PNP: 002e.f: enabled 0 PNP: 004e.0: enabled 1 PCI: 00:14.4: enabled 1 PCI: 08:01.0: enabled 1 PCI: 08:02.0: enabled 1 PCI: 08:03.0: enabled 1 PCI: 00:14.5: enabled 1 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 PCI: 00:18.4: enabled 1 PCI: 00:18.5: enabled 1 PCI: 00:19.0: enabled 1 PCI: 00:19.1: enabled 1 PCI: 00:19.2: enabled 1 PCI: 00:19.3: enabled 1 PCI: 00:19.4: enabled 1 PCI: 00:19.5: enabled 1 PCI: 00:1a.0: enabled 1 PCI: 00:1a.1: enabled 1 PCI: 00:1a.2: enabled 1 PCI: 00:1a.3: enabled 1 PCI: 00:1a.4: enabled 1 PCI: 00:1a.5: enabled 1 PCI: 00:1b.0: enabled 1 PCI: 00:1b.1: enabled 1 PCI: 00:1b.2: enabled 1 PCI: 00:1b.3: enabled 1 PCI: 00:1b.4: enabled 1 PCI: 00:1b.5: enabled 1 APIC: 01: enabled 1 APIC: 02: enabled 1 APIC: 03: enabled 1 APIC: 04: enabled 1 APIC: 05: enabled 1 APIC: 06: enabled 1 APIC: 07: enabled 1 APIC: 08: enabled 1 APIC: 09: enabled 1 APIC: 0a: enabled 1 APIC: 0b: enabled 1 APIC: 0c: enabled 1 APIC: 0d: enabled 1 APIC: 0e: enabled 1 APIC: 0f: enabled 1 APIC: 20: enabled 1 APIC: 21: enabled 1 APIC: 22: enabled 1 APIC: 23: enabled 1 APIC: 24: enabled 1 APIC: 25: enabled 1 APIC: 26: enabled 1 APIC: 27: enabled 1 APIC: 28: enabled 1 APIC: 29: enabled 1 APIC: 2a: enabled 1 APIC: 2b: enabled 1 APIC: 2c: enabled 1 APIC: 2d: enabled 1 APIC: 2e: enabled 1 APIC: 2f: enabled 1 PCI: 01:00.0: enabled 1 PCI: 01:00.1: enabled 1 PCI: 03:00.0: enabled 1 PCI: 04:00.0: enabled 1 PCI: 07:00.0: enabled 1 PCI: 08:03.1: enabled 1 PCI: 08:03.2: enabled 1 ... Instead, it looks like coreboot/SeaBIOS uses my onboard VGA according to the cbmem output. But it's using PCI device 08:01.0? I don't see this appearing in my lspci output. ... VGA: PCI: 00:18.0 (aka node 0) link 1 has VGA device ... PCI: 08:01.0 init ... ASpeed AST2050: initializing video device ast_detect_chip: AST 1100 detected ast_detect_chip: VGA not enabled on entry, requesting chip POST ast_detect_chip: Analog VGA only ast_driver_load: dram 1068000000 0 32 00800000 ASpeed VGA text mode initialized PCI: 08:01.0 init finished in 33171 usecs ... Scan for VGA option rom Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version rel-1.11.0-4-g844b864) ... Could this be an issue with my config files? I've attached the coreboot and SeaBIOS config files I used. I got the SeaBIOS config from the last tested commit on the Supported Motherboards page: https://www.coreboot.org/Supported_Motherboards#asus.2Fkgpe-d16 https://review.coreboot.org/cgit/board-status.git/tree/asus/kgpe-d16/4.6-11… My coreboot VGA related options are as follows: CONFIG_VGA_BIOS_ID="1a03,2000" # CONFIG_ONBOARD_VGA_IS_PRIMARY is not set # CONFIG_VGA_BIOS is not set CONFIG_MAINBOARD_HAS_NATIVE_VGA_INIT=y CONFIG_MAINBOARD_FORCE_NATIVE_VGA_INIT=y CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y # CONFIG_MULTIPLE_VGA_ADAPTERS is not set CONFIG_VGA=y And my SeaBIOS VGA related options are: CONFIG_VGAHOOKS=y # VGA ROM CONFIG_NO_VGABIOS=y # CONFIG_VGA_GEODEGX2 is not set # CONFIG_VGA_GEODELX is not set # CONFIG_VGA_COREBOOT is not set # CONFIG_BUILD_VGABIOS is not set CONFIG_VGA_EXTRA_STACK_SIZE=512 System info: - Coreboot commit: https://review.coreboot.org/cgit/coreboot.git/commit/?id=3f09b0ffef990286ec… (from last tested commit on Supported Motherboards page) - SeaBIOS version: rel-1.11.0-4-g844b864 - Motherboard: Asus KGPE-D16 - CPU: 2x AMD Opteron 6272 (2.1 GHz) - Memory: 16x 4 GB = 64 GB Corsair DDR3-1600 SDRAM (CMZ32GX3M8X1600C9) - Video: PCIe EVGA GeForce GTX 570 (128MB) - Onboard VGA: Aspeed AST2050 (8MB) -> disabled - Disconnected the ASMB4/KVM/BMC module. Memory configurations tried per the manual configurations. (does this matter? wouldn't I not be able to boot to my Disc OS if these weren't supported?) - 16 x 4 GB = 64 GB @ all slots - 8x 4 GB = 32 GB @ A2, B2, C2, D2, E2, F2, G2, H2 - 6x 4 GB = 24 GB @ A2, B2, C2, E2, F2, G2 - 4x 4 GB = 16 GB @ A2, C2, E2, G2 - 2x 4 GB = 8 GB @ A2, E2 Sorry for the information dump. I'm a bit lost here and want to cover all my bases. Regards, - Daniel K.

1 0

Re: [coreboot] Lenovo G505s AMD Hardware Virtualization
by awokd 15 Dec '17

15 Dec '17

On Thu, November 30, 2017 05:38, Zoran Stojsavljevic wrote: >> Last resort is to flash back the OEM image but I'm hoping to avoid that. > > I would suggest to do this step now. As interim step, Then you can verify > everything you are trying to do > with Coreboot. The first and obvious step is to check for MCU using dmesg, > if any exists. If yes, the next > step, probably, is to retrieve MCU from BIOS and port it to Coreboot, so > you can be sure that this is not > an issue. > > Then you can verify all the rest:XEN, Cubes and etc., and record use cases > wit logs, before returning > back to Coreboot. That is a painful (because this laptop needs to be completely disassembled to get at the flash chip, and it's a Lenovo crippled InsydeH2O EFI BIOS with phone home capability) but logical approach. Thanks, will report back on where this problem bisection leads and/or a resolution when I get there.

3 5

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Timothy Pearson 15 Dec '17

15 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you for the detailed response; I figured there had to be some basic miscommunication somewhere. :-) So I assume we now agree that the ME on Sylake + is not disabled, merely limited? On 12/14/2017 01:20 AM, Youness Alaoui wrote: > Hi, > > From the PT article you linked to, after the stage 5 of BUP execution : > "It is at this stage that we find HAP processing; in this mode, BUP > hangs instead of executing InitScript. This means that the remaining > sequence of actions in normal mode has nothing to do with HAP and will > not be considered. The main thing we would like to note is that in HAP > mode, BUP initializes the entire platform (ICC, Boot Guard) but does > not start the main ME processes." > > As for the kernel, that's my mistake, I remembered that prior to ME > 11.x, the KERNEL module was removed by me_cleaner, and BUP was the > first process loaded. I hadn't realized that the execution order > changed in ME 11.x, and that explains why the KERNEL module cannot be > removed by me_cleaner in ME 11.x. > On ME 10.x and lower, the BUP module was the first executed, and it > would then load the KERNEL, so if BUP is halted before it did that, > then the kernel doesn't run. In ME 11.x however, they changed the > order, the KERNEL module is first to be loaded, but it only starts the > BUP process : > "The first process that the kernel creates is BUP, which runs in its > own address space in ring-3. The kernel does not launch any other > processes itself; this is done by BUP itself" > So, you are right, on Skylake+ (ME 11.x), the kernel would be running > but the BUP process is the one halted and no other processes get > launched, but on ME 10.x and lower, the kernel wouldn't be running > since BUP is loaded first (this is true for me_cleaned ME 10.x, and > I'm not sure what exactly the MeAltDisable flag does, which is the > equivalent of HAP on previous versions, but there wasn't any specific > research done on that). > > I hadn't realized that until now when researching an error-free > response to you, so thanks for helping me notice that mistake in my > understanding. > > Youness. > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJaMqOoAAoJEK+E3vEXDOFb/mEH/3Wm0Zgt1xuZA1pvpeOC8+WG kTwczb/18V6fGLHK0SoGX7ynA4+siU+dRHwVX+uharkxED5/d4VCWnb7tUWsiT2s 7EYfYoySXgC1IDJwTZ6UxtDfh+zc5EFlm7ZLdOBXkLq07CSffqRrrbaQuJTj6QwQ wijT5Y9xhx0xVkDTDRO+unG4evAHUamrUOvIF+qranZiKbhFwI5nE+1LU8jcluQ4 2AxkxUqj0hhvEBn2Zkg+LnJbcwnTr3tpmpp5A/bWOZoYZo/Z4vE52RXs9f5ReiWM ZwQH6YH6cHZpnThgTM2wUEJszjSJLr2tvXGXqFXvwFAlQjegGo3pCM7NE7bk9Hg= =8p+9 -----END PGP SIGNATURE-----

2 1

Re: [coreboot] coreboot support for Minnowboard Turbot E3845
by Zoran Stojsavljevic 14 Dec '17

14 Dec '17

> for a E3845 Family: 0x06 Model:0x37 Stepping: 0x09... This is CPUID 0x30679, which uses MCU M0130679901.h (ONLY this one). You can also try the following MCU: M0130679905.inc (attached). You need to convert it to .h Zoran _______ On Thu, Dec 14, 2017 at 6:15 PM, Michael Graichen < michael.graichen(a)hotmail.com> wrote: > Hey Piotr, > > I'm glad to read that somebody else is working on the Atoms as well. > I'm not sure about my ucode config. At the moment I'm using 5 include > files: > > M0130673322.h > M0130678806.h > M0130678817.h > M0130679901.h and > M0230672228.h > > for a E3845 Family: 0x06 Model:0x37 Stepping: 0x09. > I copied the includes from various FSP's and the FSP_GOLD packages. > > I tried other combinations before but then i had no output on the serial > line so I ended up using these five. > > What is your Familly/Model/Stepping and what are you using for ucode? > > Best Regards > > Michael > > > > > Am 14.12.2017 um 00:04 schrieb Piotr Król: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > > > > On 12/13/2017 07:29 PM, Michael Graichen wrote: > >> Hey, > > Hi Michael, > > > >> I've bought a Minnowboard Turbot (quad core / E3845) to start > >> developing on the Atom's. > >> > >> I was hopping that it has support like the Minnowboard Max but it > >> get stuck right after FspInitApi(&FspInitParams); in > >> coreboot/src/drivers/intel/fsp1_0/fsp_util.c. The last output i can > >> see is "POST: 0x92" which comes from > >> post_code(POST_FSP_MEMORY_INIT); right before > >> FspInitApi(&FspInitParams); > > I'm not expert in MinnowBoard Turbot, but I play recently with E3826 > > and saw similar behavior when incorrect microcode was used (or no > > microcode). What are your ucode configuration ? > > > > Best Regards, > > - -- > > Piotr Król > > Embedded Systems Consultant > > https://3mdeb.com | @3mdeb_com > > -----BEGIN PGP SIGNATURE----- > > > > iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAloxsggACgkQsu5x6Weq > > nkzfPg/+PM8fk80pbmexWQw5IO4LbDOX4vw5LYkrkeTxh/3T6hAAjBt7KJ6OA4Ft > > vW8d/Ll37/r7zutrOXemXZRtxulHy4FL/7aGcDdu8JPxnO4ysLGM0fOZxkZtuyNA > > WYI7nS5mYcVdA69driI3rW0cSuGVAy7LiOBIzzV5Z8iWjQXop56cMJiP6In7zayr > > 7B5XZ6Ix934AzYihK6hZ5Rz5jZyouKb0NJRQLnRB+MljuL4sLa18bnX5NUBqgDxu > > cbw54UYgkgd6CsrbGw3XIGB63k7jYYOUayZwBaqg4QYIxPs798pX5MTe7VMJneFc > > kmg+t8HHZxQkaF9YjoVwyS5y4/24FgwQ5bROo/ztNqZMz2q0nK6jd7vQjobFKTVb > > Hc7w0jQIY37z3ZConHj9hHeVQ4AILFgpUl+NJj04hekcs4aAwJhbMun7YEAmchkp > > cCsv+WvXmOUZwTZR+CoH1xTYSMIX6JkMDZlmlhR/UGlAdpIkxMKQ6MezJXgyihvn > > rBBAMDKGvNxeZ00Cf35d+tI9OwDWw/YxYDMV3nx5MzeIkvho4Umg6ey824QlqxBF > > D+3wYuiB4ZO/uEViYkW62jFOMHxeTZ9lBNdigPsnuclDiXhvAoA1uImsaLHjNHpQ > > xndtfh+FPE3kB6c4koorgXxa3OZacd+4pGDmyjOy7Vl+TZk5hkA= > > =r1Ls > > -----END PGP SIGNATURE----- > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2017