[coreboot] Re: ACPI_BIOS_ERROR windows boot error with PCIe GPU

[Alex Feinman]

My approach to this (requires a debug connection or a dump) is first to enable 
BSOD error parameter display:
Under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl create a 
DWORD value DisplayParameters=1
At this point you can configure it to create a dump which should be sufficient 
for your needs
To create dump:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl set 
CrashDumpEnabled to 1 and AutoReboot to 0 

When BSOD hits, you will see 4 hex values - BSOD parameters. For A5 
(ACPI_BIOS_ERROR) they can be decoded using this table:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xa5--acpi-bios-error

This list is not complete and I have a standing bug report to fix that. However 
the hope is that it will be enough for your needs.
Most of the time one of the parameters will be a pointer to a Unicode string 
containing the name of the offending DSTD node.
In any case the next step would be opening the dump in WinDbg and looking at 
what's at that address.


From: vladocb via coreboot 
Sent: Wednesday, June 12, 2019 8:47 PM
To: coreboot@coreboot.org
Subject: [coreboot] ACPI_BIOS_ERROR windows boot error with PCIe GPU

Hi,
I'm trying to boot Windows 10 with Coreboot 4.9.2002 using Tianocore + a PCIe 
GPU and I always get an strange ACPI_BIOS_ERROR.

Without the PCIe GPU, works ok.

I'm pretty sure is an error with my DSDT or the southbridge code.
Sadly, I cannot debug Windows to know determine the exact ACPI problem.
I also tested with other boards like the Asus Maximus IV GeneZ and the problem 
is there too: with the IGP only works, but when I attach a PCIe GPU then it 
crashes.

Take a look to my code if you want, any help about this will be welcome.
https://review.coreboot.org/c/coreboot/+/33328

Thanks.







___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

[Alex Feinman]

Indeed this was it. I had a mismatch between the IFD and FMD. As a result my 
MRC cache was in the IFD ME region. Obviously the mapper masks ME  region. I 
think I also have a problem with ME being too large for 16 MB chip (it's 10 MB 
alone). I might have to expand the storage on my board.
Thank you for looking into this

Alex


From: Alex Feinman 
Sent: Friday, June 7, 2019 2:58 AM
To: Nico Huber; coreboot@coreboot.org
Subject: [coreboot] Re: MRC cache save/readback failure (SKL/KBL)

Hi Nico,

That's an interesting idea (IFD). Here is a dump of my IFD, but the problem is 
- I am not sure what the regions are and what they should be.
Perhaps I need a region that includes my MRC cache  (0x9f)?

File build/coreboot.rom is 16777216 bytes
Found Flash Descriptor signature at 0x0010
FLMAP0:0x00040003
  NR:  0
  FRBA:0x40
  NC:  1
  FCBA:0x30
FLMAP1:0x42100208
  ISL: 0x42
  FPSBA:   0x100
  NM:  2
  FMBA:0x80
FLMAP2:0x00310330
  PSL: 0x3103
  FMSBA:   0x300
FLUMAP1:   0x06df

Found Region Section
FLREG0:0x
FLREG1:0x0fff0a00
FLREG2:0x09ff0003
FLREG3:0x00020001
FLREG4:0x7fff

Found Component Section
FLCOMP 0x365c00f5
  Read ID/Read Status Clock Frequency: unknown<6>MHz
  Write/Erase Clock Frequency: unknown<6>MHz
  Fast Read Clock Frequency:   unknown<2>MHz
FLILL  0xad604221
FLPB   0xc7c4b9b7

Found PCH Strap Section
PCHSTRP0:  0x00220002
PCHSTRP1:  0x44000100
PCHSTRP2:  0x0001
PCHSTRP3:  0x
PCHSTRP4:  0x
PCHSTRP5:  0x0001
PCHSTRP6:  0x0100
PCHSTRP7:  0x
PCHSTRP8:  0x
PCHSTRP9:  0x
PCHSTRP10: 0x0003
PCHSTRP11: 0x0100
PCHSTRP12: 0x
PCHSTRP13: 0x
PCHSTRP14: 0x
PCHSTRP15: 0x0001

Found Master Section
FLMSTR1:   0xff00
FLMSTR2:   0xff00
FLMSTR3:   0xff00

Found Processor Strap Section
:  0x1000
:  0x00108002
:  0x0210
:  0x



From: Nico Huber 
Sent: Friday, June 7, 2019 2:41 AM
To: Alex Feinman; coreboot@coreboot.org
Subject: Re: [coreboot] MRC cache save/readback failure (SKL/KBL)

Hi Alex,

On 07.06.19 08:56, Alex Feinman wrote:
> I've checked the upper 16 MB - simply dumped the block at 0xff9f
> (0xff00 is the last 16 MB + MRC  cache region offset 0x9f from
> the layout file ) where in my image the MRC cache region resides (I can
> confirm it's there by dumping the image from flash). The data I read
> from the supposed memory mapping is all 0xff.

IIRC, you already confirmed with an external programmer that the data
is written at this location, right? If the data is there but not memory
mapped, maybe that offset isn't covered by the BIOS region in IFD?

>
> fmd and .config files are attached

I didn't spot anything problematic there. But as you don't have
CONFIG_VBOOT selected, you could also try a much simpler FMD file or
just the automatically generated default, by unsetting CONFIG_FMDFILE.

Nico
___
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: MRC cache save/readback failure (SKL/KBL)

[Alex Feinman]

Hi Nico,

That's an interesting idea (IFD). Here is a dump of my IFD, but the problem is 
- I am not sure what the regions are and what they should be.
Perhaps I need a region that includes my MRC cache  (0x9f)?

File build/coreboot.rom is 16777216 bytes
Found Flash Descriptor signature at 0x0010
FLMAP0:0x00040003
  NR:  0
  FRBA:0x40
  NC:  1
  FCBA:0x30
FLMAP1:0x42100208
  ISL: 0x42
  FPSBA:   0x100
  NM:  2
  FMBA:0x80
FLMAP2:0x00310330
  PSL: 0x3103
  FMSBA:   0x300
FLUMAP1:   0x06df

Found Region Section
FLREG0:0x
FLREG1:0x0fff0a00
FLREG2:0x09ff0003
FLREG3:0x00020001
FLREG4:0x7fff

Found Component Section
FLCOMP 0x365c00f5
  Read ID/Read Status Clock Frequency: unknown<6>MHz
  Write/Erase Clock Frequency: unknown<6>MHz
  Fast Read Clock Frequency:   unknown<2>MHz
FLILL  0xad604221
FLPB   0xc7c4b9b7

Found PCH Strap Section
PCHSTRP0:  0x00220002
PCHSTRP1:  0x44000100
PCHSTRP2:  0x0001
PCHSTRP3:  0x
PCHSTRP4:  0x
PCHSTRP5:  0x0001
PCHSTRP6:  0x0100
PCHSTRP7:  0x
PCHSTRP8:  0x
PCHSTRP9:  0x
PCHSTRP10: 0x0003
PCHSTRP11: 0x0100
PCHSTRP12: 0x
PCHSTRP13: 0x
PCHSTRP14: 0x
PCHSTRP15: 0x0001

Found Master Section
FLMSTR1:   0xff00
FLMSTR2:   0xff00
FLMSTR3:   0xff00

Found Processor Strap Section
:  0x1000
:  0x00108002
:  0x0210
:  0x



From: Nico Huber 
Sent: Friday, June 7, 2019 2:41 AM
To: Alex Feinman; coreboot@coreboot.org
Subject: Re: [coreboot] MRC cache save/readback failure (SKL/KBL)

Hi Alex,

On 07.06.19 08:56, Alex Feinman wrote:
> I've checked the upper 16 MB - simply dumped the block at 0xff9f
> (0xff00 is the last 16 MB + MRC  cache region offset 0x9f from
> the layout file ) where in my image the MRC cache region resides (I can
> confirm it's there by dumping the image from flash). The data I read
> from the supposed memory mapping is all 0xff.

IIRC, you already confirmed with an external programmer that the data
is written at this location, right? If the data is there but not memory
mapped, maybe that offset isn't covered by the BIOS region in IFD?

>
> fmd and .config files are attached

I didn't spot anything problematic there. But as you don't have
CONFIG_VBOOT selected, you could also try a much simpler FMD file or
just the automatically generated default, by unsetting CONFIG_FMDFILE.

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

[Alex Feinman]

I've checked the upper 16 MB - simply dumped the block at 0xff9f 
(0xff00 is the last 16 MB + MRC  cache region offset 0x9f from the 
layout file ) where in my image the MRC cache region resides (I can confirm 
it's there by dumping the image from flash). The data I read from the supposed 
memory mapping is all 0xff.

fmd and .config files are attached

cbfstool output at the end of the build:

This image contains the following sections that can be manipulated with this 
tool:

'SI_DESC' (size 4096, offset 0)
'SI_ME' (size 2093056, offset 4096)
'VBLOCK_A' (size 65536, offset 2097152)
'FW_MAIN_A' (size 4063168, offset 2162688)
'RW_FWID_A' (size 64, offset 6225856)
'VBLOCK_B' (size 65536, offset 6225920)
'FW_MAIN_B' (size 4063168, offset 6291456)
'RW_FWID_B' (size 64, offset 10354624)
'RECOVERY_MRC_CACHE' (size 65536, offset 10354688)
'RW_MRC_CACHE' (size 57344, offset 10420224)
'RW_VAR_MRC_CACHE' (size 8192, offset 10477568)
'RW_ELOG' (size 16384, offset 10485760)
'SHARED_DATA' (size 8192, offset 10502144)
'VBLOCK_DEV' (size 8192, offset 10510336)
'RW_VPD' (size 8192, offset 10518528)
'RW_NVRAM' (size 24576, offset 10526720)
'SMMSTORE' (size 262144, offset 10551296)
'RW_LEGACY' (CBFS, size 1769472, offset 10813440)
'RO_UNUSED' (size 40960, offset 12607488)
'RO_FRID' (size 64, offset 12650496)
'RO_FRID_PAD' (size 1984, offset 12650560)
'GBB' (size 978944, offset 12652544)
'RO_VPD' (size 15872, offset 13631488)
'RO_FTW' (size 8192, offset 13885440)
'RO_UNUSE' (size 327680, offset 13893632)
'COREBOOT' (CBFS, size 2555904, offset 14221312)

It is possible to perform either the write action or the CBFS add/remove 
actions on every section listed above.
To see the image's read-only sections as well, rerun with the -w option.
CBFSPRINT  coreboot.rom

FMAP REGION: COREBOOT
Name   Offset Type   Size   Comp
cbfs master header 0x0cbfs header32 none
fallback/romstage  0x80   stage   41084 none
cpu_microcode_blob.bin 0xa180 microcode  785408 none
fallback/ramstage  0xc9e00stage   94218 none
config 0xe0e80raw  1072 none
revision   0xe1300raw   577 none
spd.bin0xe1580spd  2048 none
wifi_sar_defaults.hex  0xe1dc0raw81 none
(empty)0xe1e80null  280 none
fspm.bin   0xe1fc0fsp401408 none
vbt.bin0x144000   raw  1168 LZMA (4608 
decompressed)
cmos_layout.bin0x144500   cmos_layout   904 none
(empty)0x1448c0   null 1752 none
fsps.bin   0x144fc0   fsp188416 none
pci8086,591e.rom   0x173000   optionrom   65536 none
fallback/postcar   0x183080   stage   20396 none
fallback/dsdt.aml  0x188080   raw 18172 none
fallback/payload   0x18c800   simple elf 671666 none
(empty)0x230800   null   210840 none
bootblock  0x263fc0   bootblock   49152 none




From: Nico Huber 
Sent: Thursday, June 6, 2019 1:28 PM
To: Alex Feinman; coreboot@coreboot.org
Subject: Re: [coreboot] MRC cache save/readback failure (SKL/KBL)

Hi Alex,

On 06.06.19 18:43, Alex Feinman wrote:
> If the boot_device_ro from mmap_boot.c is being  used, I don't see how the 
> flash content gets mapped into top of the 4GB space. In case of Apollo Lake, 
> there is a special implementation. But for the rest of x86 there is nothing. 
> Is there something I missed in the SKL+ specification that says that the BIOS 
> is mapped into memory automatically?

yes, it's traditionally mapped there. Actually, on all current Intel
platforms, the BIOS region in flash is mapped there. Apollo Lake needs
a little special treatment because a) the BIOS region usually isn't at
the end of the flash chip and b) an SRAM replaces the topmost part of
the mapping. Not sure where it is documented, maybe in the PCH data-
sheet.

> PS How should I provide my .config - attachment or inline?

Attachment works.

Nico


ATT53651.config
Description: ATT53651.config


chromeos.fmd
Description: chromeos.fmd
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: MRC cache save/readback failure (SKL/KBL)

[Alex Feinman]

Hi Niko, thank you for looking into this

If the boot_device_ro from mmap_boot.c is being  used, I don't see how the 
flash content gets mapped into top of the 4GB space. In case of Apollo Lake, 
there is a special implementation. But for the rest of x86 there is nothing. Is 
there something I missed in the SKL+ specification that says that the BIOS is 
mapped into memory automatically?
For now if I use boot_device_ro as a backing device for MRC reads, I am getting 
0xFF all around, resulting in cache slot treated as uninitialized.

PS How should I provide my .config - attachment or inline?

From: Nico Huber 
Sent: Tuesday, June 4, 2019 3:33 PM
To: Alex Feinman; coreboot@coreboot.org
Subject: Re: [coreboot] MRC cache save/readback failure (SKL/KBL)

Hi Alex,

On 04.06.19 22:27, Alex Feinman wrote:
> In my Coreboot build (derived from kblrvp configuration) based on 4.9
> label I am seeing that MRC test is run on every boot. From what I can
> tell, what happens is:
> 1) On first boot the MRC cache is not found (correct). MRC test is done
> and the MRC cache is saved successfully. If I pull the BIOS image down,
> I can see valid contents of the MRC cache where they are supposed to be
> 2) On the second boot MRC verification fails because rdev_mmap does not
> have .mmap method in the rdev ops. Since this rdev is based on
> boot_device_rw_nommap, this seems to be both intended and clearly wrong.

this is odd. AFAIK, it should use boot_device_ro (src/arch/x86/
mmap_boot.c).

> I'm open to suggestions

Share your code. The FMD format alone provides enough flexibility that
it's impossible to tell what could go wrong. Also, your .config might
contain some spurious setting (though, I don't see how it could result
in using the rdev).

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] MRC cache save/readback failure (SKL/KBL)

[Alex Feinman]

In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I 
am seeing that MRC test is run on every boot. From what I can tell, what 
happens is:
1) On first boot the MRC cache is not found (correct). MRC test is done and the 
MRC cache is saved successfully. If I pull the BIOS image down, I can see valid 
contents of the MRC cache where they are supposed to be
2) On the second boot MRC verification fails because rdev_mmap does not have 
.mmap method in the rdev ops. Since this rdev is based on 
boot_device_rw_nommap, this seems to be both intended and clearly wrong.
3) At this point MRC test is rerun and is written to the flash *without erasing 
it first* resulting in corrupted data. 
4) Next and all subsequent boots result in reading back corrupt header from MRC 
cache and a failure followed by retrain.

I was able to hack it by replacing 3 calls to mmap with readat and adding erase 
before the MRC update, but clearly it is supposed to work, so what am I missing?

The board is fairly close to KBL RVP3 and the changes to coreboot are minimal. 
FMD file has MRC cache section

I'm open to suggestions

Alex
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Building Coreboot Image for Opencellular

[Alex Feinman]

OpenCellular project provides very decent Coreboot instructions. In particular, 
they suggest that you flash just the coreboot section of ROM as per 
https://github.com/Telecominfraproject/OpenCellular/wiki/How-to-coreboot#updates

=
Updates can simply applied by using the coreboot flashrom tool and applying 
this patch.

Update FW partition A
flashrom --fmap -i RW_SECTION_A -w coreboot.rom
Update FW partition B
flashrom --fmap -i RW_SECTION_B -w coreboot.rom
=

If you do this, you won't need the descriptor as you are not overwriting the 
entire ROM

From: karthikm...@gmail.com 
Sent: Monday, May 6, 2019 11:38 PM
To: coreboot@coreboot.org
Subject: [coreboot] Building Coreboot Image for Opencellular

Hello,

I'm Karthik working on Opencellular 
(https://code.fb.com/connectivity/introducing-opencellular-an-open-source-wireless-access-platform/).
 I'm trying to build coreboot image for Opencellular Board. Finally, succeeded 
in building the image but with a WARNING message

** WARNING **
coreboot will be built without an Intel Firmware Descriptor.
Never write a complete coreboot.rom without an IFD to your
board's flash chip! You can use flashrom's IFD or layout
parameters to flash only to the BIOS region.

So my question is
1. Is it okay to flash the image with above WARNING message onto the board?

Help me to find a way.

Thank you, in advance.
___
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: Question regarding 7th generation Intel CPUs

[Alex Feinman]

To add to this - in my opinion there is no reason to believe that Coreboot is 
less secure than a proprietary BIOS built on top of the code distributed by 
Intel to established BIOS vendors (AMI, Phoenix/Award etc). The FSPs are also 
built out of that same code and because Coreboot is open-source, it at least 
can be audited. As Stefan points out CSME/ME is the main source of worry for 
security-conscious, and from this standpoint there is no difference between 
coreboot and the proprietary BIOS.

Best regards
Alex


From: Stefan Reinauer 
Sent: Monday, April 1, 2019 5:53 PM
To: Coins
Cc: coreboot@coreboot.org
Subject: [coreboot] Re: Question regarding 7th generation Intel CPUs

Hi Coins,

I'm not coreboot, but I'm a part of it, so I will try to answer your
question. CCing the coreboot mailing list for more input, as I can only
assume that that list was the intended recipient for your email.

It is unproven that Intel deliberately builds in backdoors into their
CPUs. However, a lot of their software / hardware designs create a
rather large attack surface that could be exploited, if someone puts the
right amount of resources on the problem.

This attack surface lives

- in the SOC's converged security management engine (CSME / ME), which
  in some SKUs enables remote access to the system through builtin
  network interfaces. The CSME cannot be fully disabled, but some
  security issues can be mitigated in a good hardware software design
  i.e. by using the non-enterprise (aka 1.5M SKU) of the ME firmware or
  by not using the SOC associated network interfaces (questionable) or
  by disabling as many CSME features as possible.
  CSME is particularly problematic because it can access main memory, so
  a remote attack could steal your private keys, rendering your
  cryptographical secrets useless.

- FSP / BLOBS. Closed source firmware pieces generally have the problem
  that they are impossible to audit. Even if there are fixed version out
  in the field, you can not tell from a binary what is fixed or not.
  Bugs are also impossible to fix, even when known. Imaginable attack
  scenarios could also be deliberate changes to memory training data
  which open known but fixed memory controller issues.

Generally coreboot tries to enable the user / developer / systembuilder
to address as many of these concerns as possible, but it can not 100%
fix them at this point. If you are concerned about your hardware
architecture, please study the source code of coreboot and the available
open documentation on x86 hardware (of which there is a fair amount) and
help us audit our code.

Stefan



* Coins  [190331 18:29]:
> Dear Coreboot,
>
> As far as I know, Intel puts proprietary backdoors in any recent CPU they
> develop.
>
> How does this affect the security of a PC/laptop with coreboot installed
> when it is using such a processor?
>
> Best regards,
>
>
> Coins
___
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] QQ/

[Alex Feinman]

DDR RComp calculation is explained in the CPU platform design guide. If you are 
an Intel licensee, you can request this document by number - 561280 for KBL. 
There seems to be also a whitepaper you can ask your OEM rep for. 
The actual values are calculated based on memory topology and board layout and 
then fine-tuned through measurement. Basically, if you are a system designer, 
you have the documents and know how to do it, and if you are not, then these 
values are calculated by the manufacturer/BIOS writer so your only recourse is 
to find out from them. 

Similarly, DQ array is filled according to the information supplied by the 
system designer. Intel CPUs allow certain freedom in routing the memory pins to 
simplify the board layout task. The pin map should be filled for DQ/DQS 
according to the physical connectivity chosen by the system designer. 

Bottom line - it's not something you can figure out by looking at a motherboard


From: Nico Huber 
Sent: Friday, March 29, 2019 10:03 AM
To: Michal Zygowski; coreboot@coreboot.org
Subject: [coreboot] Re: FSP2.0 DQ byte map

Hi Michal,

On 29.03.19 16:49, Michal Zygowski wrote:
> I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M
> configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM
> (correct me if I'm wrong) for DDR4 for example. But the DQ map is an
> 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My
> questions are:
>
> 1. Why there are more bytes in array than DQ lanes?

it's actually not an array but a rather complex structure. You can
find some clues in the Skylake FSP Integration Guide [1] and also
in coreboot header files [2]. I have no idea why the documentation
was removed from future guides.

> 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?

If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that
it's for memory-down configurations with LPDDR3 only. And, AFAIR, an
investigation into the deep of the KBL FSP source didn't find any
relation to DDR4.

> I know about 3 Rcomp resistors of the chipset and what they are for, but
> what RcompTarget is?
> In the code I can see function `mainboard_fill_rcomp_strength_data` and
> begin to wonder what rcomp strength is (not Rcomp Target?). How to
> correctly fill RcompTarget FSP-M configuration?

Please tell me if you find out ;) even Intel developers working on
coreboot don't know. Some insider came back quoting identifiers from
comments in the FSP header... identifiers nowhere to be found in
source/documentation.

My guess is that the targets are either computed or even measured by
some very confidential tool.

Nico

[1]
https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspIntegrationGuide.pdf
[2]
https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/include/soc/pei_data.h#n236
___
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: Intel sVID controller and SVID bus.

[Alex Feinman]

Intel CPUs typically drive SVID-enabled PMICs using an internal small core (at 
least Core m and Core i parts). In any case, the peripherals on SVID bus have 
addresses that sometimes are assigned via bootstrap pins. Your Denverton design 
probably has a TI and ST Micro PMICs connected to SVID. If the device does not 
respond on the expected address, the CPU probably won't retry communication. 
I'm not closely familiar with Atom family, so I don't know what it would do. 
The Core CPU will raise CATERR signal and die. In any case, I recommend trying 
to capture what happens on the SVID bus from the very moment of powerup. Expect 
a low-voltage (~ 1V) 25 MHz I2C-like signal.

If you do capture it and you have a support agreement with Intel, you can ask 
them for an SVID decoder. You might also try decoding it manually (search web 
for "vr pwm specification intel"), using the Intel spec.

Finally, if you determine that the peripherals in your system indeed nak the 
SVID traffic, the actual addresses of these peripherals can be programmed in 
the BIOS code, however I am not certain if this is something happening inside 
the FSP and if it can be modified externally.



From: dponamo...@gmail.com 
Sent: Friday, February 22, 2019 7:05 AM
To: coreboot@coreboot.org
Subject: [coreboot] Intel sVID controller and SVID bus.
 
On the motherboard developed by our company (intel atom denverton 3538), there 
is a low performance of the processor and memory. When trying to monitor the 
exchange of the SVID bus lines with the oscilloscope (SVID_CLK, SVID_DATA and 
SVID_ALERT), no activity was noticed. Circuit design is correct (passed Intel 
review).
Could this be the reason for the slow speed of the processor and memory? Do I 
need to activate this technology in coreboot or FSP? Is there any way to check 
the operation of the sVID controller from Linux?
___
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: Caby lake support

[Alex Feinman]

There are existing configurations for KBL RVP3/7/8 and a couple of KBL-based 
google boards (Fizz, Poppy)

find -name board_info.txt|xargs grep -i kaby
./src/mainboard/google/poppy/board_info.txt:Board name: Poppy Kabylake 
Reference Board
./src/mainboard/google/fizz/board_info.txt:Board name: Fizz Kabylake Reference 
Board
./src/mainboard/intel/kblrvp/board_info.txt:Board name: Kabylake RVP Reference 
Board



From: Zaolin 
Sent: Wednesday, February 20, 2019 2:34 AM
To: Mayuri Tendulkar; Angel Pons
Cc: coreboot
Subject: [coreboot] Re: Caby lake support

There are Intel reference boards. You can find them in the code under:

src/mainboard/intel/

A Kaby Lake reference board should be kblrvp.

On 20.02.19 11:29, Mayuri Tendulkar wrote:
Thanks for quick response.

I see below release- this support is added.

https://coreboot.org/releases/coreboot-4.8.1-relnotes.txt

Is there any reference board used with this chipset , which can be referred as 
some POC?

From: Angel Pons 
Sent: 20 February 2019 15:55
To: Mayuri Tendulkar 

Cc: coreboot 
Subject: Re: [coreboot] Caby lake support

** This mail has been sent from an external source **

Hello,
On Wed, Feb 20, 2019, 11:23 Mayuri Tendulkar 
mailto:mayuri.tendul...@aricent.com> wrote:
Is there support for Intel Cabylake chipset in latest coreboot?
Kaby Lake? Yes.
=
Please refer to http://www.aricent.com/email-disclaimer
for important disclosures regarding this electronic communication.
=



___
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: VBIOS/VBT in Coreboot [SOLVED]

[Alex Feinman]

I think I almost got to the bottom of it. I thought, incorrectly, that the VBT 
on my system is not accessible because I trusted intelvbttool from utils/ to 
dump it. It is outdated as it relies on VGA option ROM. If I use the 
intel_vbt_decode from intel-gpu-tools package (Ubuntu), I can see the VBT just 
fine:
sudo intel_vbt_decode --file /sys/kernel/debug/dri/0/i915_vbt

As for VBT - the way to set it up is to use vbt.bin (renamed to vbt.dat) and 
vbt.bsf with intel BMP.exe  or bct tool supplied in the FSP GIT. 

I think it would be nice to document that intelvbttool does not work in 
UEFI/GOP setups (and is generally speaking obsoleted by the new utilities in 
the intel-gpu-tools package). 

Best regards

Alex

From: Matt DeVillier 
Sent: Tuesday, February 19, 2019 2:52 PM
To: Alex Feinman
Cc: Nico Huber; coreboot@coreboot.org
Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot

since you're using Tianocore, you'll need to set a VESA/hi-res framebuffer; VGA 
text mode doesn't work IIRC.  You can set that under the Display options, but a 
better option than using/running a VBIOS would be to use the FSP/GOP init, 
since it automatically sets a hi-res framebuffer (usually equal to the panel 
native resolution). But it seems you were having trouble with that before?

On Tue, Feb 19, 2019 at 8:33 AM Alex Feinman 
mailto:alexfein...@hotmail.com>> wrote:
I am using Tianocore payload because I require UEFI support. PCI ID for the 
option ROM is set to 8086:591e (KBL-Y)
config file is attached


From: Matt DeVillier mailto:matt.devill...@gmail.com>>
Sent: Monday, February 18, 2019 10:10 PM
To: Alex Feinman
Cc: Nico Huber; coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot

what payload is being used here? If SeaBIOS, you'd ideally want SeaBIOS to run 
the VGA BIOS, not coreboot (in which case, only the oprom name in cbfs needs to 
match the PCI ID, not the one in the VBIOS header - only coreboot checks that). 
You'd set coreboot's display init to none, and simply include the VBIOS and set 
the PCI ID to match.  That's what I'm doing here for the Purism Librem 
13v4/15v4 boards (which are loosely RVP3-based).  Might not hurt to do a 'make 
savedefconfig' and reply with the contents of defconfig (stripping your board's 
make/model if needed)


On Mon, Feb 18, 2019 at 11:08 PM Alex Feinman 
mailto:alexfein...@hotmail.com>> wrote:

Nico, thank you.

I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on 
advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 
to the one matching my hardware. Now I see the 0xc segment and intelvbttool 
can decode VBT. However there is a remaining issue - the video on boot is not 
present and only comes up when Linux boots. I feel like I need the GOP driver 
after all.

Best regards
Alex





From: Nico Huber mailto:nic...@gmx.de>>
Sent: Saturday, February 16, 2019 11:05 AM
To: Alex Feinman; coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: Re: [coreboot] VBIOS/VBT in Coreboot

Hello Alex,

On 16.02.19 18:39, Alex Feinman wrote:
> In my Coreboot build I provide both VBIOS and VBT blobs via appropriate
> configuration items. The VBIOS blob contains expected signature at the
> top and VBT is valid as confirmed by running intelvbttool against it.
> The platform is slightly modified kblrvp (RVP3).

AIUI, you only need the VBT. If you are not going to run the VBIOS, you
don't need that one.

>
> During the build I can see cbfstool reporting that both blobs were
> placed in the image: To see the image's read-only sections as well,
> rerun with the -w option.
>
> However, once the system boots, the VBIOS is not found at address
> 0xc

You'd have to tell coreboot or a payload to load the VBIOS. AFAIK,
coreboot only does it when you also tell it to use it for gfx init
(`VGA_ROM_RUN`).

> and VBT cannot be located either.  I need VBT to be accessible
> in order to specify the DP connector configuration for eDP. Suggestions
> are appreciated

Maybe check the coreboot console for clues. For instance there should
be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up
that points to the VBT.

If that doesn't happen, one possible cause is that your processors SKU
isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`.
There is no reliable public source for these IDs. So it's hard to tell
if the list is comprehensive.

In any case, please report back. If you can't find a solution, please
point to the exact code you are using and attach your `.config` file.

Nico
___
coreboot mailing list -- coreboot@coreboot.org<mailto:coreboot@coreboot.org>
To unsubscribe send an email to 
coreboot-le...@coreboot.org<mailto:coreboot-le...@coreboot.org>
___

[coreboot] Re: VBIOS/VBT in Coreboot

[Alex Feinman]

I am using Tianocore payload because I require UEFI support. PCI ID for the 
option ROM is set to 8086:591e (KBL-Y)
config file is attached


From: Matt DeVillier 
Sent: Monday, February 18, 2019 10:10 PM
To: Alex Feinman
Cc: Nico Huber; coreboot@coreboot.org
Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot
 
what payload is being used here? If SeaBIOS, you'd ideally want SeaBIOS to run 
the VGA BIOS, not coreboot (in which case, only the oprom name in cbfs needs to 
match the PCI ID, not the one in the VBIOS header - only coreboot checks that). 
You'd set coreboot's display init to none, and simply include the VBIOS and set 
the PCI ID to match.  That's what I'm doing here for the Purism Librem 
13v4/15v4 boards (which are loosely RVP3-based).  Might not hurt to do a 'make 
savedefconfig' and reply with the contents of defconfig (stripping your board's 
make/model if needed)


On Mon, Feb 18, 2019 at 11:08 PM Alex Feinman  wrote:

Nico, thank you.

I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on 
advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 
to the one matching my hardware. Now I see the 0xc segment and intelvbttool 
can decode VBT. However there is a remaining issue - the video on boot is not 
present and only comes up when Linux boots. I feel like I need the GOP driver 
after all.

Best regards
Alex





From: Nico Huber 
Sent: Saturday, February 16, 2019 11:05 AM
To: Alex Feinman; coreboot@coreboot.org
Subject: Re: [coreboot] VBIOS/VBT in Coreboot
 
Hello Alex,

On 16.02.19 18:39, Alex Feinman wrote:
> In my Coreboot build I provide both VBIOS and VBT blobs via appropriate
> configuration items. The VBIOS blob contains expected signature at the
> top and VBT is valid as confirmed by running intelvbttool against it.
> The platform is slightly modified kblrvp (RVP3).

AIUI, you only need the VBT. If you are not going to run the VBIOS, you
don't need that one.

>
> During the build I can see cbfstool reporting that both blobs were
> placed in the image: To see the image's read-only sections as well,
> rerun with the -w option.
>
> However, once the system boots, the VBIOS is not found at address
> 0xc

You'd have to tell coreboot or a payload to load the VBIOS. AFAIK,
coreboot only does it when you also tell it to use it for gfx init
(`VGA_ROM_RUN`).

> and VBT cannot be located either.  I need VBT to be accessible
> in order to specify the DP connector configuration for eDP. Suggestions
> are appreciated

Maybe check the coreboot console for clues. For instance there should
be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up
that points to the VBT.

If that doesn't happen, one possible cause is that your processors SKU
isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`.
There is no reliable public source for these IDs. So it's hard to tell
if the list is comprehensive.

In any case, please report back. If you can't find a solution, please
point to the exact code you are using and attach your `.config` file.

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


defconfig
Description: defconfig
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: VBIOS/VBT in Coreboot

[Alex Feinman]

Nico, thank you.
​
I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on 
advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 
to the one matching my hardware. Now I see the 0xc segment and intelvbttool 
can decode VBT. However there is a remaining issue - the video on boot is not 
present and only comes up when Linux boots. I feel like I need the GOP driver 
after all.

Best regards
Alex





From: Nico Huber 
Sent: Saturday, February 16, 2019 11:05 AM
To: Alex Feinman; coreboot@coreboot.org
Subject: Re: [coreboot] VBIOS/VBT in Coreboot
 
Hello Alex,

On 16.02.19 18:39, Alex Feinman wrote:
> In my Coreboot build I provide both VBIOS and VBT blobs via appropriate
> configuration items. The VBIOS blob contains expected signature at the
> top and VBT is valid as confirmed by running intelvbttool against it.
> The platform is slightly modified kblrvp (RVP3).

AIUI, you only need the VBT. If you are not going to run the VBIOS, you
don't need that one.

>
> During the build I can see cbfstool reporting that both blobs were
> placed in the image: To see the image's read-only sections as well,
> rerun with the -w option.
>
> However, once the system boots, the VBIOS is not found at address
> 0xc

You'd have to tell coreboot or a payload to load the VBIOS. AFAIK,
coreboot only does it when you also tell it to use it for gfx init
(`VGA_ROM_RUN`).

> and VBT cannot be located either.  I need VBT to be accessible
> in order to specify the DP connector configuration for eDP. Suggestions
> are appreciated

Maybe check the coreboot console for clues. For instance there should
be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up
that points to the VBT.

If that doesn't happen, one possible cause is that your processors SKU
isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`.
There is no reliable public source for these IDs. So it's hard to tell
if the list is comprehensive.

In any case, please report back. If you can't find a solution, please
point to the exact code you are using and attach your `.config` file.

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] VBIOS/VBT in Coreboot

[Alex Feinman]

In my Coreboot build I provide both VBIOS and VBT blobs via appropriate 
configuration items. The VBIOS blob contains expected signature at the top and 
VBT is valid as confirmed by running intelvbttool against it. The platform is 
slightly modified kblrvp (RVP3).

During the build I can see cbfstool reporting that both blobs were placed in 
the image:
To see the image's read-only sections as well, rerun with the -w option.

    CBFSPRINT  coreboot.rom



Name                           Offset     Type           Size   Comp

cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           41372 none
cpu_microcode_blob.bin         0xa280     microcode       98304 none
fallback/ramstage              0x22300    stage           90199 none
config                         0x383c0    raw              1302 none
revision                       0x38940    raw               612 none
spd.bin                        0x38c00    spd              2048 none
--> vbt.bin                        0x39440    raw              1168 LZMA (4608 
decompressed)
cmos_layout.bin                0x39940    cmos_layout       904 none
(empty)                        0x39d00    null              664 none
fspm.bin                       0x39fc0    fsp            401408 none
(empty)                        0x9c000    null             3992 none
fsps.bin                       0x9cfc0    fsp            188416 none
--> pci8086,591e.rom               0xcb000    optionrom       65536 none
fallback/postcar               0xdb080    stage           16512 none
fallback/dsdt.aml              0xdf140    raw             19077 none
fallback/payload               0xe3c40    simple elf    1166029 none
(empty)                        0x200780   null           997400 none
bootblock                      0x2f3fc0   bootblock       49152 none

However, once the system boots, the VBIOS is not found at address 0xc and 
VBT cannot be located either.
I need VBT to be accessible in order to specify the DP connector configuration 
for eDP. Suggestions are appreciated

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] How to get correct memory params for FSP

[Alex Feinman]

This tells us nothing about swizzling - the order in which DQ/DQS lines of the 
memory address bus are connected to the CPU. Memory connections to the CPU are 
flexible to simplify PCB routing. As a result in order for the memory 
controller to be able to use memory you need to provide board-specific mapping. 
You cannot glean this from looking at the PCB - you need the schematic. And no, 
off the shelf Tianocore will not automatically do this either - it's a 
customizable part of the build


From: Alexey Borovikov 
Sent: Tuesday, November 6, 2018 11:06 AM
To: R S; alexfein...@hotmail.com
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] How to get correct memory params for FSP

Ok, there is no spd on the board. Four memory chips are soldered on the board 
(Micron DDR3L 4х512MB 1333Mhz). I understand that I need to set the correct 
memory parameters in the fsp configurator. Even if it works, replacing the 
memory chips may lead to a stop working of the coreboot.rom. It is necessary to 
change the parameters of the fsp again and rebuild coreboot.rom.
How does the proprietary BIOS (TianoCore) work in case of replacing the memory 
chips on board?
Are there universal parameters for this memory types and what should I take 
note for when configuring FSP?

From: R S<mailto:rene.shus...@bcsemail.org>
Sent: Tuesday, November 06, 2018 8:30 PM
To: alexfein...@hotmail.com<mailto:alexfein...@hotmail.com>
Cc: coreboot@coreboot.org<mailto:coreboot@coreboot.org> ; 
alexey_...@mail.ru<mailto:alexey_...@mail.ru>
Subject: Re: [coreboot] How to get correct memory params for FSP

Faint memories... are you the ISO recorder author from 15 years ago?

On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman 
mailto:alexfein...@hotmail.com>> wrote:
The two major issues with bringing up the memory subsystem on a new board are 
SPD parameters and DQ/DQS layout
Specifically, if you look at the apollolake rvp subtree, you can see a whole 
bunch of parameters being set in romstage.c. Some of it is fairly 
straightforward. Swizzling tables are not and require you to be able to read 
schematic (and have access to it in the first place)
Obviously, the problem could be elsewhere. I would start with enabling MRC 
debug and perhaps posting the MRC output

From: coreboot 
mailto:coreboot-boun...@coreboot.org>> on behalf 
of Alexey Borovikov via coreboot 
mailto:coreboot@coreboot.org>>
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: [coreboot] How to get correct memory params for FSP

Hi.
I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the 
Baytrail family. The result - postcode is 0x2A. From the descriptions on the 
Internet, I understand that the problem is in the incorrect memory parameters.
Question: are there any utilities or methods that will help to get the correct 
memory parameters when working a regular BIOS from Linux or Windows systems?
Many thanks!
--
coreboot mailing list: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
https://mail.coreboot.org/mailman/listinfo/coreboot


--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign<http://comicsanscriminal.com>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to get correct memory params for FSP

[Alex Feinman]

Guilty as charged :)


From: R S 
Sent: Tuesday, November 6, 2018 9:30 AM
To: alexfein...@hotmail.com
Cc: coreboot@coreboot.org; alexey_...@mail.ru
Subject: Re: [coreboot] How to get correct memory params for FSP

Faint memories... are you the ISO recorder author from 15 years ago?

On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman 
mailto:alexfein...@hotmail.com>> wrote:
The two major issues with bringing up the memory subsystem on a new board are 
SPD parameters and DQ/DQS layout
Specifically, if you look at the apollolake rvp subtree, you can see a whole 
bunch of parameters being set in romstage.c. Some of it is fairly 
straightforward. Swizzling tables are not and require you to be able to read 
schematic (and have access to it in the first place)
Obviously, the problem could be elsewhere. I would start with enabling MRC 
debug and perhaps posting the MRC output


From: coreboot 
mailto:coreboot-boun...@coreboot.org>> on behalf 
of Alexey Borovikov via coreboot 
mailto:coreboot@coreboot.org>>
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
Subject: [coreboot] How to get correct memory params for FSP

Hi.
I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the 
Baytrail family. The result - postcode is 0x2A. From the descriptions on the 
Internet, I understand that the problem is in the incorrect memory parameters.
Question: are there any utilities or methods that will help to get the correct 
memory parameters when working a regular BIOS from Linux or Windows systems?
Many thanks!
--
coreboot mailing list: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
https://mail.coreboot.org/mailman/listinfo/coreboot


--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign<http://comicsanscriminal.com>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to get correct memory params for FSP

[Alex Feinman]

The two major issues with bringing up the memory subsystem on a new board are 
SPD parameters and DQ/DQS layout
Specifically, if you look at the apollolake rvp subtree, you can see a whole 
bunch of parameters being set in romstage.c. Some of it is fairly 
straightforward. Swizzling tables are not and require you to be able to read 
schematic (and have access to it in the first place)
Obviously, the problem could be elsewhere. I would start with enabling MRC 
debug and perhaps posting the MRC output


From: coreboot  on behalf of Alexey Borovikov 
via coreboot 
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot@coreboot.org
Subject: [coreboot] How to get correct memory params for FSP

Hi.
I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the 
Baytrail family. The result - postcode is 0x2A. From the descriptions on the 
Internet, I understand that the problem is in the incorrect memory parameters.
Question: are there any utilities or methods that will help to get the correct 
memory parameters when working a regular BIOS from Linux or Windows systems?
Many thanks!
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"

[Alex Feinman]

Keep in mind that Intel RVP boards ship with Intel EC code, which is not 
compatible with Coreboot. You need to reflash it with Google EC - it's built as 
a part of Coreboot, or it can be built separately as well.


From: coreboot  on behalf of Nico Huber 

Sent: Thursday, September 20, 2018 1:16 PM
To: Jose Trujillo; Naresh G. Solanki
Cc: coreboot
Subject: Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: 
pre-conditions not met"

Hi Jose,

On 20.09.2018 15:58, Jose Trujillo via coreboot wrote:
> I will follow your advise of checking EC and about the base FW I am
> using the original UEFI AMI FW but, if still doesn't boot I will replace
> ME and descriptor as you suggested.

Better don't. The Firmware Descriptor and ME are orthogonal to coreboot.
It's best to leave them in flash as they are once you have them working
with the original firmware. If you use flashrom, you can use a layout
file or the --ifd option and include only the BIOS region when writing.

Nico

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[Alex Feinman]

Chris,

The GPIO tables are usually compiled into the BIOS C code and not into ASL. 
While decompiling DSDT can give you some insight into what GPIOs are used for 
say WLAN power control or some of the hardware interrupts, there is also a 
number of Kaby Lake pins that drive system signals or control onboard hardware 
without going through ASL. For instance Coreboot build for KBL RVP3 uses this:

https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/kblrvp/variants/rvp3/include/variant/gpio.h


What Niko suggests is to review carefully all the lines that use GPIO_CFG_GPO 
(output) to ensure that no pins that are configured as output unless you are 
absolutely sure about where they go. Of course, this requires you to understand 
the code




From: coreboot  on behalf of 
chrisglow...@tutanota.com 
Sent: Monday, June 25, 2018 11:39 AM
To: Coreboot
Subject: Re: [coreboot] Porting Kabylake laptop

On 25. Jun 2018 18:18 nic...@gmx.de wrote:

you can generally boot without a complete port. But you can also damage
the hardware if you are not careful. Beside the devicetree settings (pay
attention when it comes to the voltage regulator settings!), the GPIO
configuration should also match your board. You can try to boot without
GPIO configuration (it should be safe because the hardware has to expect
the reset defaults for the GPIOs). But *never* try to boot with a copied
GPIO configuration from another board.


Thank you Nico for the warnings! A few questions:

1. Is it safe to leave default VR settings from Kabylake Reference Board?

2. Can the laptop work properly without GPIO? I don't know if there is a way to 
dump the GPIO config in vendor firmware on Kabylake.

3. Are there other settings that could damage the hardware?



Regarding the EC, you can learn a lot about its interface from the ven-
dor's ACPI implementation. Unless the board uses a lot of PnP interfaces
of the EC (unlikely for a modern laptop), the datasheet is usually not
helpful. What you really would need is documentation about the EC firm-
ware and its OS interface. And you'll likely not get that.


Can the laptop boot to Linux without EC support in coreboot?

Regarding the ACPI implementation, can that be dumped using acpidump and then 
used in the ec.asl file?


Thanks,

Chris


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ACPI error booting Windows

[Alex Feinman]

Just to close the thread - I've found the problem. It was a reference to 
PMIC.OVTH in the mipi camera asl file. I've removed the entire MIPI block for 
now because my platform does not have a camera, but the underlying issue should 
be easy to solve if needed

From: Matt DeVillier <matt.devill...@gmail.com>
Sent: Wednesday, April 25, 2018 8:50 PM
To: alexfein...@hotmail.com
Cc: coreboot
Subject: Re: [coreboot] ACPI error booting Windows

you can take a look at all my configs as as well as all the patches in my tree 
in my github there.  They aren't all fully up to date, but should be useful.  
Check Caroline, Cave, Chell, Sentry for Skylake CrOS devices, which should all 
be the same ACPI-wise as kblrvp3.  I haven't pushed the config for the KabyLake 
CrOS device yet since it's not yet released, but it it doesn't require any 
additional patches from what's in my tree now.

On Wed, Apr 25, 2018 at 9:02 PM Alex Feinman 
<alexfein...@hotmail.com<mailto:alexfein...@hotmail.com>> wrote:
That unfortunately did not help. Would it be possible to take a look at your 
.config? Perhaps I'll be able to spot something

From: Matt DeVillier <matt.devill...@gmail.com<mailto:matt.devill...@gmail.com>>
Sent: Wednesday, April 25, 2018 4:14 PM
To: alexfein...@hotmail.com<mailto:alexfein...@hotmail.com>
Cc: coreboot
Subject: Re: [coreboot] ACPI error booting Windows

I have Windows booting on a KBL CrOS device, and looking at my tree, pretty 
sure the only change I have that would potentially address that error is adding 
the pcon value to the IGD ACPI OpRegion header:
https://github.com/MattDevo/coreboot/commit/3349065354709c85276168272469797dd3f6

there were a few others but they've all since been merged upstream


On Wed, Apr 25, 2018 at 6:00 PM Alex Feinman 
<alexfein...@hotmail.com<mailto:alexfein...@hotmail.com>> wrote:
I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board. The 
build uses Chrome EC and is based on kblrvp3 mainboard configuration. Linux 
runs fine, but when I attempt to install Windows 10 (or boot a preinstalled 
Windows image from USB) I instantly get ACPI_BIOS_ERROR (0xC0A5). There is 
a Microsoft document that provides a large amount of possible reasons for this 
error, however I can't even narrow it down because cleverly Windows 10 no 
longer prints the bug check parameters, at least not in this case.

I would appreciate some pointers if possible.

Thank you
Alex
--
coreboot mailing list: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ACPI error booting Windows

[Alex Feinman]

That unfortunately did not help. Would it be possible to take a look at your 
.config? Perhaps I'll be able to spot something

From: Matt DeVillier <matt.devill...@gmail.com>
Sent: Wednesday, April 25, 2018 4:14 PM
To: alexfein...@hotmail.com
Cc: coreboot
Subject: Re: [coreboot] ACPI error booting Windows

I have Windows booting on a KBL CrOS device, and looking at my tree, pretty 
sure the only change I have that would potentially address that error is adding 
the pcon value to the IGD ACPI OpRegion header:
https://github.com/MattDevo/coreboot/commit/3349065354709c85276168272469797dd3f6

there were a few others but they've all since been merged upstream


On Wed, Apr 25, 2018 at 6:00 PM Alex Feinman 
<alexfein...@hotmail.com<mailto:alexfein...@hotmail.com>> wrote:
I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board. The 
build uses Chrome EC and is based on kblrvp3 mainboard configuration. Linux 
runs fine, but when I attempt to install Windows 10 (or boot a preinstalled 
Windows image from USB) I instantly get ACPI_BIOS_ERROR (0xC0A5). There is 
a Microsoft document that provides a large amount of possible reasons for this 
error, however I can't even narrow it down because cleverly Windows 10 no 
longer prints the bug check parameters, at least not in this case.

I would appreciate some pointers if possible.

Thank you
Alex
--
coreboot mailing list: coreboot@coreboot.org<mailto:coreboot@coreboot.org>
https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] ACPI error booting Windows

[Alex Feinman]

I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board. The 
build uses Chrome EC and is based on kblrvp3 mainboard configuration. Linux 
runs fine, but when I attempt to install Windows 10 (or boot a preinstalled 
Windows image from USB) I instantly get ACPI_BIOS_ERROR (0xC0A5). There is 
a Microsoft document that provides a large amount of possible reasons for this 
error, however I can't even narrow it down because cleverly Windows 10 no 
longer prints the bug check parameters, at least not in this case.

I would appreciate some pointers if possible.

Thank you
Alex
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot