phosphor-isolation

phosphor-isolation

[James Feist]

I enabled phosphor-isolation on my system and noticed that kcs no longer 
worked afterwards. Commenting out this section:

https://github.com/openbmc/meta-phosphor/blob/a1cee09419cb1467c3d2b7bf996b40089f0d06f4/aspeed-layer/recipes-bsp/u-boot/files/0001-aspeed-Disable-unnecessary-features.patch#L230

+	/* 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. Do we need this part set? If so, should we 
create a phosphor-isolation-kcs and phosphor-isolation-bt?


Thanks

-James

Re: phosphor-isolation

[Andrew Jeffery]

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:
> 
> https://github.com/openbmc/meta-phosphor/blob/a1cee09419cb1467c3d2b7bf996b40089f0d06f4/aspeed-layer/recipes-bsp/u-boot/files/0001-aspeed-Disable-unnecessary-features.patch#L230
> 
> +	/* 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 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?

> 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

Re: phosphor-isolation

[James Feist]

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:
>>
>> https://github.com/openbmc/meta-phosphor/blob/a1cee09419cb1467c3d2b7bf996b40089f0d06f4/aspeed-layer/recipes-bsp/u-boot/files/0001-aspeed-Disable-unnecessary-features.patch#L230
>>
>> +	/* 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 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.


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

RE: 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

Re: phosphor-isolation

[James Feist]

On 9/20/19 9:20 AM, Milton Miller II wrote:
> 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?

Attempting to send ipmi commands from uefi/linux stopped working. Linux 
driver on host reported issues communicating to bmc.

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

There is a driver and kcsbridged.
> 
> (3) Will the host try to use the KCS even though it can
>      not find the superio to choose the port and interrupt?

Yes.

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

RE: phosphor-isolation

[Milton Miller II]

Around 09/20/2019 01:16PM in some timezone James Feist wrote:>On 9/20/19 9:20 AM, Milton Miller II wrote:
>> 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?
>
>Attempting to send ipmi commands from uefi/linux stopped working.
>Linux 
>driver on host reported issues communicating to bmc.
>
>> 
>> (2) Is there code to enable the KCS peripheral from the bmc
>
>There is a driver and kcsbridged.

Those are probably drivers to respond to data sent 
over the bridge.  I was looking more to "is the KCS 
peripherial enabled on the LPC bus at the expected 
address?"

If you add mem.devmem=y [1] to the kernel command line 
you can use devmem at runtime to reverse that bit via 
/dev/mem and then use an sio configuration tool from 
the host to query how its configured.  


There is probably another way to do it from the bmc 
side but I don't know where to start looking (probably 
somewhere in the lpc space).


[1] https://github.com/openbmc/linux/blob/707b68f43a8cc94fe5dcc4e35dad778828ca9cc9/drivers/char/mem.c#L921

>> 
>> (3) Will the host try to use the KCS even though it can
>>      not find the superio to choose the port and interrupt?
>
>Yes.
>
>> 
>> 
>> 
>> 
>> 
>>>>>
>>>>> 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

milton

RE: phosphor-isolation

[Ryan Chen]

Hello James,
	This patch is just enable LPC decode for 0x2e/0x4e. also not effect KCS. 
	Could you check the SCU0c[8] disable or not?
Ryan

-----Original Message-----
From: James Feist [mailto:james.feist@linux.intel.com] 
Sent: Saturday, September 21, 2019 2:17 AM
To: Milton Miller II <miltonm@us.ibm.com>
Cc: Andrew Jeffery <andrew@aj.id.au>; OpenBMC Maillist <openbmc@lists.ozlabs.org>; Ryan Chen <ryan_chen@aspeedtech.com>
Subject: Re: phosphor-isolation

On 9/20/19 9:20 AM, Milton Miller II wrote:
> 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?

Attempting to send ipmi commands from uefi/linux stopped working. Linux driver on host reported issues communicating to bmc.

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

There is a driver and kcsbridged.
> 
> (3) Will the host try to use the KCS even though it can
>      not find the superio to choose the port and interrupt?

Yes.

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