coreboot September 2016

coreboot@coreboot.org

51 participants
82 discussions

Will coreboot work on my laptop?
by MingHeng Wang 22 Sep '16

22 Sep '16

Hello everyone, I have a HP stream 11 x360 laptop. It has the following outputs performing the commands listed in coreboot FAQ: [ifoolb@192 ~]$ lspci -tvnn -[0000:00]-+-00.0 Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register [8086:0f00] +-02.0 Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] +-14.0 Intel Corporation Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI [8086:0f35] +-1a.0 Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18] +-1b.0 Intel Corporation Atom Processor Z36xxx/Z37xxx Series High Definition Audio Controller [8086:0f04] +-1c.0-[01]-- +-1c.1-[02]----00.0 Broadcom Limited BCM43142 802.11b/g/n [14e4:4365] +-1c.2-[03]----00.0 Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader [10ec:5227] +-1c.3-[04]----00.0 Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136] +-1f.0 Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c] \-1f.3 Intel Corporation Atom Processor E3800 Series SMBus Controller [8086:0f12] superiotool reported no superio found. [ifoolb@192 ~]$ sudo flashrom -p internal -V flashrom v0.9.7-r1850 on Linux 4.7.3-200.fc24.x86_64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.4.1, GCC 6.0.0 20160201 (Red Hat 6.0.0-0.9), little endian Command line (3 args): flashrom -p internal -V Calibrating delay loop... OS timer resolution is 1 usecs, 1364M loops per second, 10 myus = 10 us, 100 myus = 99 us, 1000 myus = 1058 us, 10000 myus = 10333 us, 4 myus = 5 us, OK. Initializing internal programmer No coreboot table found. Using External DMI decoder. DMI string chassis-type: "Notebook" Laptop detected via DMI. DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "HP Stream x360 Convertible PC 11" DMI string system-version: "Type1 - ProductConfigId" DMI string baseboard-manufacturer: "Hewlett-Packard" DMI string baseboard-product-name: "802B" DMI string baseboard-version: "57.16" ======================================================================== WARNING! You seem to be running flashrom on an unsupported laptop. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See the manpage and http://www.flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Aborting. Error: Programmer initialization failed. Will coreboot work on it? Thanks in advance.

1 0

Kyösti: IMB-A180 motherboard is available
by Mark Mason 22 Sep '16

22 Sep '16

Kyösti, my emails to you are bouncing. Please send me a shipping address. Best regards, Mark Mason Engineering Design Team mark(a)edt.com

1 0

Re: [coreboot] FYI: ACPI ASL 2.0
by Marc Jones 20 Sep '16

20 Sep '16

On Tue, Sep 20, 2016 at 1:02 PM Duncan Laurie <dlaurie(a)chromium.org> wrote: > So far I've been asking people in ACPI patches to not introduce ASL 2.0 > syntax into existing ASL code as it can be confusing if the two are mixed. > So we should either convert everything or at least only use ASL 2.0 syntax > in new files. > > I agree. We don't want mixed. Maybe a comment at the top of the file if it is an ACPI2.0 format. > The problem with auto-converting sources with the disassembly/assembly > trick is you lose all the comments. > > I don't know how many changes there are and how much could be partial automated. We need to understand the scale of the work involved and have a plan to integrate the changes. > The problem with doing it by hand is it very easy to mess something up. > > But that *should* be easy to check. The disassembly should match before and after. Marc > -duncan > > > On Tue, Sep 20, 2016 at 11:39 AM, Marc Jones <marcj303(a)gmail.com> wrote: > >> Hi Rudolf, >> >> I'm for this change. I don't think it would be too invasive and should be >> easy to test with the compiler. >> >> Marc >> >> >> On Mon, Sep 19, 2016 at 2:49 PM Rudolf Marek <r.marek(a)assembler.cz> >> wrote: >> >>> Hi all, >>> >>> Just FYI [1], maybe you already know. >>> >>> There is an alternate syntax available for ACPI ASL sources. >>> It just converts Polish notation of ASL to something less geeky like C >>> operators. It says that the tool to convert the sources is in >>> development (to >>> ratain comments). I think it would make ACPI more readable if coreboot >>> would >>> switch to ASL 2.0. Note that the change is only on syntax side! Latest >>> ACPICA >>> iasl already decompiles to this syntax by default! >>> >>> Example before: >>> >>> Method (SRDY, 0, Serialized) >>> { >>> Store (200, Local0) // Timeout 200ms >>> While (Local0) { >>> If (And(HSTS, 0x40)) { // IN_USE? >>> Sleep(1) // Wait 1ms >>> Decrement(Local0) // timeout-- >>> If (LEqual(Local0, 0)) { >>> Return (1) >>> } >>> } Else { >>> Store (0, Local0) // We're ready >>> } >>> } >>> >>> Store (4000, Local0) // Timeout 200ms (50us * 4000) >>> While (Local0) { >>> If (And (HSTS, 0x01)) { // Host Busy? >>> Stall(50) // Wait 50us >>> Decrement(Local0) // timeout-- >>> If (LEqual(Local0, 0)) { >>> KILL() >>> } >>> } Else { >>> Return (0) // Success >>> } >>> } >>> >>> Return (1) // Failure >>> } >>> >>> >>> After: >>> >>> Method (SRDY, 0, Serialized) >>> { >>> Local0 = 0xC8 >>> While (Local0) >>> { >>> If (HSTS & 0x40) >>> { >>> Sleep (0x01) >>> Local0-- >>> If (Local0 == 0x00) >>> { >>> Return (0x01) >>> } >>> } >>> Else >>> { >>> Local0 = 0x00 >>> } >>> } >>> >>> Local0 = 0x0FA0 >>> While (Local0) >>> { >>> If (HSTS & 0x01) >>> { >>> Stall (0x32) >>> Local0-- >>> If (Local0 == 0x00) >>> { >>> KILL () >>> } >>> } >>> Else >>> { >>> Return (0x00) >>> } >>> } >>> >>> Return (0x01) >>> } >>> >>> >>> Thanks >>> Rudolf >>> >>> >>> [1] https://acpica.org/sites/acpica/files/ASL2.0Overview.pdf >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> -- >> http://marcjonesconsulting.com >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > -- http://marcjonesconsulting.com

1 0

Re: [coreboot] FYI: ACPI ASL 2.0
by ron minnich 20 Sep '16

20 Sep '16

I've even seen this done, or maybe I did it, I forget, but it's a one time pass through something like cpp: #define Store(src, dst) dst = src to produce the final output. repeat for all ops of interest. Then, if there is a switch to ASL to not accept pre-asl-2.0 code you do a clean up stage as needed. You only need the cpp hack once as you want to switch to the transformed output. Not pretty, but maybe ACPI is so simple that it would work. ron On Tue, Sep 20, 2016 at 12:11 PM ron minnich <rminnich(a)gmail.com> wrote: > It would be nice if there were a source to source transformation tool out > there but failing that RPN to infix is pretty simple to automate. > > ron > > On Tue, Sep 20, 2016 at 12:03 PM Duncan Laurie <dlaurie(a)chromium.org> > wrote: > >> So far I've been asking people in ACPI patches to not introduce ASL 2.0 >> syntax into existing ASL code as it can be confusing if the two are mixed. >> So we should either convert everything or at least only use ASL 2.0 syntax >> in new files. >> >> The problem with auto-converting sources with the disassembly/assembly >> trick is you lose all the comments. >> >> The problem with doing it by hand is it very easy to mess something up. >> >> -duncan >> >> >> On Tue, Sep 20, 2016 at 11:39 AM, Marc Jones <marcj303(a)gmail.com> wrote: >> >>> Hi Rudolf, >>> >>> I'm for this change. I don't think it would be too invasive and should >>> be easy to test with the compiler. >>> >>> Marc >>> >>> >>> On Mon, Sep 19, 2016 at 2:49 PM Rudolf Marek <r.marek(a)assembler.cz> >>> wrote: >>> >>>> Hi all, >>>> >>>> Just FYI [1], maybe you already know. >>>> >>>> There is an alternate syntax available for ACPI ASL sources. >>>> It just converts Polish notation of ASL to something less geeky like C >>>> operators. It says that the tool to convert the sources is in >>>> development (to >>>> ratain comments). I think it would make ACPI more readable if coreboot >>>> would >>>> switch to ASL 2.0. Note that the change is only on syntax side! Latest >>>> ACPICA >>>> iasl already decompiles to this syntax by default! >>>> >>>> Example before: >>>> >>>> Method (SRDY, 0, Serialized) >>>> { >>>> Store (200, Local0) // Timeout 200ms >>>> While (Local0) { >>>> If (And(HSTS, 0x40)) { // IN_USE? >>>> Sleep(1) // Wait 1ms >>>> Decrement(Local0) // timeout-- >>>> If (LEqual(Local0, 0)) { >>>> Return (1) >>>> } >>>> } Else { >>>> Store (0, Local0) // We're ready >>>> } >>>> } >>>> >>>> Store (4000, Local0) // Timeout 200ms (50us * 4000) >>>> While (Local0) { >>>> If (And (HSTS, 0x01)) { // Host Busy? >>>> Stall(50) // Wait 50us >>>> Decrement(Local0) // timeout-- >>>> If (LEqual(Local0, 0)) { >>>> KILL() >>>> } >>>> } Else { >>>> Return (0) // Success >>>> } >>>> } >>>> >>>> Return (1) // Failure >>>> } >>>> >>>> >>>> After: >>>> >>>> Method (SRDY, 0, Serialized) >>>> { >>>> Local0 = 0xC8 >>>> While (Local0) >>>> { >>>> If (HSTS & 0x40) >>>> { >>>> Sleep (0x01) >>>> Local0-- >>>> If (Local0 == 0x00) >>>> { >>>> Return (0x01) >>>> } >>>> } >>>> Else >>>> { >>>> Local0 = 0x00 >>>> } >>>> } >>>> >>>> Local0 = 0x0FA0 >>>> While (Local0) >>>> { >>>> If (HSTS & 0x01) >>>> { >>>> Stall (0x32) >>>> Local0-- >>>> If (Local0 == 0x00) >>>> { >>>> KILL () >>>> } >>>> } >>>> Else >>>> { >>>> Return (0x00) >>>> } >>>> } >>>> >>>> Return (0x01) >>>> } >>>> >>>> >>>> Thanks >>>> Rudolf >>>> >>>> >>>> [1] https://acpica.org/sites/acpica/files/ASL2.0Overview.pdf >>>> >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> -- >>> http://marcjonesconsulting.com >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230
by Trammell Hudson 20 Sep '16

20 Sep '16

Zoran -- Thanks for your insights on the ME. It's quite a messy bit of HW and it makes no sense to me why Intel has it shrouded in such secrecy. There is no reason that I can see for it to be undocumented. > [...] > Link to the very useful presentation (I clipped the above figure): > http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub Igor's 2012 presentation and 2014 update have been very helpful as I have been poking at the ME, especially the layout of some of the structs in the firmware partition table and partition headers. As an update to my previous message, I've built an even more reduced ME firmware that has removed a few modules from the FTPR partition: UPDATE, HOSTCOMM, RSA, CLS, TDT, ClsPriv and SESSMGR can be replaced with 0xFF and the ME will still initialize the system correctly. This leaves only ROMP, BUP, KERNEL, POLICY and FTCS. >[...] > Essentially, talking about ME, we are talking about the PCH's HW entity, > which has the complete CPU inside itself, called ARC (32 bit, not sure if > this is a RISC, high probability it is) On Sandybridge/Ivybridge it is the ARC CPU, radare2 has a dissassembler and the files can be decompressed with http://io.netgarage.org/me/ > [...] Something like this: ME partition gets > downloaded to PCH, where it occupies small SRAM area, for the beginning. There must be some amount of on-chip ROM as well, since the FTPR code is Huffman compressed. The decompressor also checks a signature on the partition header, so we can't modify many of the fields in the header. > Then ME initializes Integrated Clock Controller (ICC). Then BIOS starts > booting. BIOS thread of execution is the following (the best I could > invision from the patchworks reachable to me): > > [1] Initializes VGA (via PCIe port); > > [2] Initializes Host Embedded Controller I/F init (via HECI PCIe port); > > [3] Then BIOS/HECI initiates communication with ME/MEI; > > [4] BIOS continues with DDRAMx MRC; > > [5] Upon finishing MRC, BIOS/HECI communicates with ME/MEI; > > [6] ME starts booting ARC 32bit Threadx RTOS kernel; > > [7] ME reserves on the DDRx's TOM (Top Of Memory) 32MB UMA region solely > for its own (application) use! That matches my understanding as well, with the exception that the UMA region appears to be configured immediately after MRC execution in the BIOS. > Coreboot, upon bringing up, does NOT know about HECI I/F (my best guess) > and ME (and MEI). I believe Coreboot does both HECI and MEI, depending on the chipset. For the bd82x6x it uses MEI via PCIe. If it didn't talk to the ME, the UMA would never be configured and (I believe) the ME wouldn't make any progress past its bring up. That might also be an easy way to neutralize the ME; if it is never given any resources, can we prevent it from doing anything bad? > [...] > Then, it is easy to imagine that FTPR is THE only ME component, which needs > to be executed, since it is essentially part of INTERNAL ME init! And I'm hoping that by removing the rest of the code that there is nothing in the on-die ROM that has additoinal backdoors. With the network device driver and java bytecode interpreter gone, I also hope that the ME can not be subverted by an outside party. -- Trammell

4 3

Re: [coreboot] FYI: ACPI ASL 2.0
by ron minnich 20 Sep '16

20 Sep '16

It would be nice if there were a source to source transformation tool out there but failing that RPN to infix is pretty simple to automate. ron On Tue, Sep 20, 2016 at 12:03 PM Duncan Laurie <dlaurie(a)chromium.org> wrote: > So far I've been asking people in ACPI patches to not introduce ASL 2.0 > syntax into existing ASL code as it can be confusing if the two are mixed. > So we should either convert everything or at least only use ASL 2.0 syntax > in new files. > > The problem with auto-converting sources with the disassembly/assembly > trick is you lose all the comments. > > The problem with doing it by hand is it very easy to mess something up. > > -duncan > > > On Tue, Sep 20, 2016 at 11:39 AM, Marc Jones <marcj303(a)gmail.com> wrote: > >> Hi Rudolf, >> >> I'm for this change. I don't think it would be too invasive and should be >> easy to test with the compiler. >> >> Marc >> >> >> On Mon, Sep 19, 2016 at 2:49 PM Rudolf Marek <r.marek(a)assembler.cz> >> wrote: >> >>> Hi all, >>> >>> Just FYI [1], maybe you already know. >>> >>> There is an alternate syntax available for ACPI ASL sources. >>> It just converts Polish notation of ASL to something less geeky like C >>> operators. It says that the tool to convert the sources is in >>> development (to >>> ratain comments). I think it would make ACPI more readable if coreboot >>> would >>> switch to ASL 2.0. Note that the change is only on syntax side! Latest >>> ACPICA >>> iasl already decompiles to this syntax by default! >>> >>> Example before: >>> >>> Method (SRDY, 0, Serialized) >>> { >>> Store (200, Local0) // Timeout 200ms >>> While (Local0) { >>> If (And(HSTS, 0x40)) { // IN_USE? >>> Sleep(1) // Wait 1ms >>> Decrement(Local0) // timeout-- >>> If (LEqual(Local0, 0)) { >>> Return (1) >>> } >>> } Else { >>> Store (0, Local0) // We're ready >>> } >>> } >>> >>> Store (4000, Local0) // Timeout 200ms (50us * 4000) >>> While (Local0) { >>> If (And (HSTS, 0x01)) { // Host Busy? >>> Stall(50) // Wait 50us >>> Decrement(Local0) // timeout-- >>> If (LEqual(Local0, 0)) { >>> KILL() >>> } >>> } Else { >>> Return (0) // Success >>> } >>> } >>> >>> Return (1) // Failure >>> } >>> >>> >>> After: >>> >>> Method (SRDY, 0, Serialized) >>> { >>> Local0 = 0xC8 >>> While (Local0) >>> { >>> If (HSTS & 0x40) >>> { >>> Sleep (0x01) >>> Local0-- >>> If (Local0 == 0x00) >>> { >>> Return (0x01) >>> } >>> } >>> Else >>> { >>> Local0 = 0x00 >>> } >>> } >>> >>> Local0 = 0x0FA0 >>> While (Local0) >>> { >>> If (HSTS & 0x01) >>> { >>> Stall (0x32) >>> Local0-- >>> If (Local0 == 0x00) >>> { >>> KILL () >>> } >>> } >>> Else >>> { >>> Return (0x00) >>> } >>> } >>> >>> Return (0x01) >>> } >>> >>> >>> Thanks >>> Rudolf >>> >>> >>> [1] https://acpica.org/sites/acpica/files/ASL2.0Overview.pdf >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> -- >> http://marcjonesconsulting.com >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] FYI: ACPI ASL 2.0
by Duncan Laurie 20 Sep '16

20 Sep '16

So far I've been asking people in ACPI patches to not introduce ASL 2.0 syntax into existing ASL code as it can be confusing if the two are mixed. So we should either convert everything or at least only use ASL 2.0 syntax in new files. The problem with auto-converting sources with the disassembly/assembly trick is you lose all the comments. The problem with doing it by hand is it very easy to mess something up. -duncan On Tue, Sep 20, 2016 at 11:39 AM, Marc Jones <marcj303(a)gmail.com> wrote: > Hi Rudolf, > > I'm for this change. I don't think it would be too invasive and should be > easy to test with the compiler. > > Marc > > > On Mon, Sep 19, 2016 at 2:49 PM Rudolf Marek <r.marek(a)assembler.cz> wrote: > >> Hi all, >> >> Just FYI [1], maybe you already know. >> >> There is an alternate syntax available for ACPI ASL sources. >> It just converts Polish notation of ASL to something less geeky like C >> operators. It says that the tool to convert the sources is in development >> (to >> ratain comments). I think it would make ACPI more readable if coreboot >> would >> switch to ASL 2.0. Note that the change is only on syntax side! Latest >> ACPICA >> iasl already decompiles to this syntax by default! >> >> Example before: >> >> Method (SRDY, 0, Serialized) >> { >> Store (200, Local0) // Timeout 200ms >> While (Local0) { >> If (And(HSTS, 0x40)) { // IN_USE? >> Sleep(1) // Wait 1ms >> Decrement(Local0) // timeout-- >> If (LEqual(Local0, 0)) { >> Return (1) >> } >> } Else { >> Store (0, Local0) // We're ready >> } >> } >> >> Store (4000, Local0) // Timeout 200ms (50us * 4000) >> While (Local0) { >> If (And (HSTS, 0x01)) { // Host Busy? >> Stall(50) // Wait 50us >> Decrement(Local0) // timeout-- >> If (LEqual(Local0, 0)) { >> KILL() >> } >> } Else { >> Return (0) // Success >> } >> } >> >> Return (1) // Failure >> } >> >> >> After: >> >> Method (SRDY, 0, Serialized) >> { >> Local0 = 0xC8 >> While (Local0) >> { >> If (HSTS & 0x40) >> { >> Sleep (0x01) >> Local0-- >> If (Local0 == 0x00) >> { >> Return (0x01) >> } >> } >> Else >> { >> Local0 = 0x00 >> } >> } >> >> Local0 = 0x0FA0 >> While (Local0) >> { >> If (HSTS & 0x01) >> { >> Stall (0x32) >> Local0-- >> If (Local0 == 0x00) >> { >> KILL () >> } >> } >> Else >> { >> Return (0x00) >> } >> } >> >> Return (0x01) >> } >> >> >> Thanks >> Rudolf >> >> >> [1] https://acpica.org/sites/acpica/files/ASL2.0Overview.pdf >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > -- > http://marcjonesconsulting.com > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

FYI: ACPI ASL 2.0
by Rudolf Marek 20 Sep '16

20 Sep '16

Hi all, Just FYI [1], maybe you already know. There is an alternate syntax available for ACPI ASL sources. It just converts Polish notation of ASL to something less geeky like C operators. It says that the tool to convert the sources is in development (to ratain comments). I think it would make ACPI more readable if coreboot would switch to ASL 2.0. Note that the change is only on syntax side! Latest ACPICA iasl already decompiles to this syntax by default! Example before: Method (SRDY, 0, Serialized) { Store (200, Local0) // Timeout 200ms While (Local0) { If (And(HSTS, 0x40)) { // IN_USE? Sleep(1) // Wait 1ms Decrement(Local0) // timeout-- If (LEqual(Local0, 0)) { Return (1) } } Else { Store (0, Local0) // We're ready } } Store (4000, Local0) // Timeout 200ms (50us * 4000) While (Local0) { If (And (HSTS, 0x01)) { // Host Busy? Stall(50) // Wait 50us Decrement(Local0) // timeout-- If (LEqual(Local0, 0)) { KILL() } } Else { Return (0) // Success } } Return (1) // Failure } After: Method (SRDY, 0, Serialized) { Local0 = 0xC8 While (Local0) { If (HSTS & 0x40) { Sleep (0x01) Local0-- If (Local0 == 0x00) { Return (0x01) } } Else { Local0 = 0x00 } } Local0 = 0x0FA0 While (Local0) { If (HSTS & 0x01) { Stall (0x32) Local0-- If (Local0 == 0x00) { KILL () } } Else { Return (0x00) } } Return (0x01) } Thanks Rudolf [1] https://acpica.org/sites/acpica/files/ASL2.0Overview.pdf

2 1

Re: [coreboot] hackaton in Berlin?
by Peter Stuge 20 Sep '16

20 Sep '16

echelon(a)free.fr wrote: > Is it still relevant? It's still relevant. Registration page is in the works. //Peter

1 0

fsp_baytrail smi_lock bit set
by John Fastabend 20 Sep '16

20 Sep '16

Hi, I'm using the fsp_baytrail (minnowboard-max) code base with the Intel provided FSP Gold4 binary for the platform. Everything boots fine but I was looking at the SMI/smm code paths and wanted to trigger an SMI from an I/O port write. It appears this is being disabled the GBL_SMI_EN bit is disabled and can not be set because the SMI_LOCK bit is being set. I read through some of the code and it looks like other platforms such as skylake have explicit control over this bit and clear/set it in the coreboot source code. Even the baytrail platform (sans fsp) seems to set/clear it directly. For fsp_baytrail I don't see any coreboot code setting the SMI_LOCK bit at all and some tracing seems to indicate it is being set in the FSP parts of the code. So two questions, 1) Is my reading of the fsp_baytrail code correct and the SMI_LOCK bit is really being set by the FSP code paths. 2) Anyone know how to _not_ set the bit either via coreboot change or FSP configuration maybe via BCT? Sorry if this is really an FSP question I didn't see any good FSP mailing list to CC or just send its own mail to. For reference the SMI_LOCK bit is in this register, General PM Configuration 2 (GEN_PMCON2)—Offset 24h at bit 4, and the GBL_SMI_EN is in this register, SMI_EN - SMI Control and Enable (SMI_EN)—Offset 30h at bit 0. I use the following code snippets to add debugging into the coreboot code paths, + pmc = inl(PMC_BASE_ADDRESS + 0x24); + printk(BIOS_INFO, "SMI# : PMC: 0x08x\n", pmc) to read the smi_lock bit and the following to read/set the smi_enable bit which fails due to the above bit being set, + outl(smi_en | 0x1, get_pmbase() + SMI_EN); + smi_en = inl(get_pmbase() + SMI_EN); + printk(BIOS_INFO, "post write SMI# : 0x08x\n", smi_en); Any hints, help, comments would be appreciated at the moment I'm just sort of scanning the FSP spec to try and glean something useful. Thanks, John

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2016