[coreboot] fsp_baytrail smi_lock bit set

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Tue Sep 20 16:00:20 CEST 2016


Hello John,

After bit a googling on the open net, looking into coreboot tree:
[zoran at localhost coreboot]$ git describe
4.4-1345-g62d1313

And searching through it, and bit thinking, I would suggest you the
following:



*> 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?*

You should inspect very carefully two files in the following directory:
[zoran at localhost sch]$ pwd
/home/zoran/projects/coreboot/coreboot/src/soc/intel/sch
[zoran at localhost sch]$ ls -al smi*
-rw-rw-r--. 1 zoran zoran 10411 Aug 31 03:29 *smi.c*
-rw-rw-r--. 1 zoran zoran 11558 Aug 31 03:29 *smihandler.c*
[zoran at localhost sch]$

All the answers on your two questions you'll find there. ;-)

Regards,
Zoran

On Mon, Sep 19, 2016 at 6:38 PM, John Fastabend <john.fastabend at gmail.com>
wrote:

> 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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160920/2bb92bb0/attachment.html>


More information about the coreboot mailing list