phosphor-isolation

[Milton Miller II]

On September 20, 2019, around 10:56AM in some timezone, James Feist wrote:
>On 9/19/19 8:47 PM, Andrew Jeffery wrote:
>> On Fri, 20 Sep 2019, at 03:03, James Feist wrote:
>>> I enabled phosphor-isolation on my system and noticed that kcs no
>>>longer
>>> worked afterwards. Commenting out this section:
>>>
>>>

>>>
>>> +	/* iLPC2AHB */
>>> +	val = readl(AST_SCU_BASE + AST_SCU_HW_STRAP1);
>>> +	val |= SCU_HW_STRAP_LPC_DEC_SUPER_IO;
>>> +	writel(val, AST_SCU_BASE + AST_SCU_HW_STRAP1);
>>>
>>>
>>> Seems to make KCS work again.

That configuration is disabling superio decoding, which means the host
will no longer be able to configure the superio hardware on the LPC bus.

>> 
>> That is an unexpected result. Have you asked ASPEED about it? I've
>> added
>> Ryan to Cc. I must admit I didn't test the patch with systems that
>> use KCS
>> because OpenPOWER exclusively uses BT for IPMI (though we're
>> starting
>> to exploit the KCS interfaces for an LPC MCTP binding).
>> 
>> Having said that, the systems that we're testing our LPC MCTP
>> binding on
>> would have this patch applied, so presumably we're not seeing the
>> same
>> effect there. They're 2500-based systems, is that what you're
>> testing with?
>
>Yes I am.
>

As an outside observer without hardware, can you check:

(1) Did you check from the OS or just from a BIOS inventory?

(2) Is there code to enable the KCS peripheral from the bmc

(3) Will the host try to use the KCS even though it can
    not find the superio to choose the port and interrupt?





>>> 
>>> Do we need this part set? If so, should we
>>> create a phosphor-isolation-kcs and phosphor-isolation-bt?
>> 
>> I hope not, given that leaving the SuperIO decoding enable allows
>the
>> host to (slowly) scrape BMC memory (or if iLPC2AHB writes are
>> allowed,
>> open faster backdoors). We should root-cause the issue before
>> exploring this path.
>> 
>> Andrew