MCTP LPC FW binding

MCTP LPC FW binding

[Govert Overgaauw]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hello,

I was wondering if anyone is/was successful in using the MCTP over LPC binding with an intel platform? I read through the documents, it seems to me the binding was designed to use LPC firmware cycles. To me it is unclear if the ast2500 supports memory cycles on the LPC2AHB bridge (datasheet seems to list it in the features, not much explanation).  The problem is that the C620 chipset doesn't support firmware cycles (only memory and I/O cycles). And having a properly mapped window in the C620 chipset and reserved memory in Linux. Writing and Reading to it only returns ('1s').

Writing a simple test on x86 that keeps writing a value to the mapped registers, seems to trigger LAD[3:1] = 0xF readout on the BMC LPC host controller register 0 (that has some debug registers to see the state of the LPC bus). 0xF is the stop frame of a standard LPC memory cycle.

Kind Regards,

Govert Overgaauw


[-- Attachment #2: Type: text/html, Size: 2293 bytes --]

Re: MCTP LPC FW binding

[Andrew Jeffery]

On Sat, 12 Mar 2022, at 00:32, Govert Overgaauw wrote:
> Hello,
>
> I was wondering if anyone is/was successful in using the MCTP over LPC 
> binding with an intel platform? I read through the documents, it seems 
> to me the binding was designed to use LPC firmware cycles. To me it is 
> unclear if the ast2500 supports memory cycles on the LPC2AHB bridge 
> (datasheet seems to list it in the features, not much explanation).  
> The problem is that the C620 chipset doesn't support firmware cycles 
> (only memory and I/O cycles). And having a properly mapped window in 
> the C620 chipset and reserved memory in Linux. Writing and Reading to 
> it only returns ('1s').
>
> Writing a simple test on x86 that keeps writing a value to the mapped 
> registers, seems to trigger LAD[3:1] = 0xF readout on the BMC LPC host 
> controller register 0 (that has some debug registers to see the state 
> of the LPC bus). 0xF is the stop frame of a standard LPC memory cycle.

As one of the authors of the binding, I just wanted to note that it was 
developed for IBM's Power systems (which support FW cycles). I haven't 
tried memory cycles, however there are other conditions under which you 
might get 0xF, such as if the LPC2AHB isn't enabled. The BMC 
aspeed-lpc-ctrl kernel driver should take care of this for you, however 
it only does so once you open the character device. From there you'll 
need to use the ioctl()s to switch the bridge to use the reserved 
memory rather than the default mapping of the host SPI-NOR.

Andrew

Re: MCTP LPC FW binding

[Andrew Jeffery]

On Fri, 18 Mar 2022, at 02:12, Govert Overgaauw wrote:
>>> Hello,
>>>
>>> I was wondering if anyone is/was successful in using the MCTP over LPC 
>>> binding with an intel platform? I read through the documents, it seems 
>>> to me the binding was designed to use LPC firmware cycles. To me it is 
>>> unclear if the ast2500 supports memory cycles on the LPC2AHB bridge 
>>> (datasheet seems to list it in the features, not much explanation).  
>>> The problem is that the C620 chipset doesn't support firmware cycles 
>>> (only memory and I/O cycles). And having a properly mapped window in 
>>> the C620 chipset and reserved memory in Linux. Writing and Reading to 
>>> it only returns ('1s').
>>>
>>> Writing a simple test on x86 that keeps writing a value to the mapped 
>>> registers, seems to trigger LAD[3:1] = 0xF readout on the BMC LPC host 
>>> controller register 0 (that has some debug registers to see the state 
>>> of the LPC bus). 0xF is the stop frame of a standard LPC memory cycle.
>>
>> As one of the authors of the binding, I just wanted to note that it was 
>> developed for IBM's Power systems (which support FW cycles). I haven't 
>> tried memory cycles, however there are other conditions under which you 
>> might get 0xF, such as if the LPC2AHB isn't enabled. The BMC 
>> aspeed-lpc-ctrl kernel driver should take care of this for you, however 
>> it only does so once you open the character device. From there you'll 
>> need to use the ioctl()s to switch the bridge to use the reserved 
>> memory rather than the default mapping of the host SPI-NOR.
>>
>> Andrew
>
> I can confirm that the BMC works with memory cycles on the LPC bus 
> using this binding. There was a misconfiguration on the x86 side 
> resulting
> in it not generating memory cycles on the bus.

Ah, great. Happy to look at whatever patches it took to get it going.

Andrew

Re: MCTP LPC FW binding

[Govert Overgaauw]

>> Hello,
>>
>> I was wondering if anyone is/was successful in using the MCTP over LPC 
>> binding with an intel platform? I read through the documents, it seems 
>> to me the binding was designed to use LPC firmware cycles. To me it is 
>> unclear if the ast2500 supports memory cycles on the LPC2AHB bridge 
>> (datasheet seems to list it in the features, not much explanation).  
>> The problem is that the C620 chipset doesn't support firmware cycles 
>> (only memory and I/O cycles). And having a properly mapped window in 
>> the C620 chipset and reserved memory in Linux. Writing and Reading to 
>> it only returns ('1s').
>>
>> Writing a simple test on x86 that keeps writing a value to the mapped 
>> registers, seems to trigger LAD[3:1] = 0xF readout on the BMC LPC host 
>> controller register 0 (that has some debug registers to see the state 
>> of the LPC bus). 0xF is the stop frame of a standard LPC memory cycle.
>
> As one of the authors of the binding, I just wanted to note that it was 
> developed for IBM's Power systems (which support FW cycles). I haven't 
> tried memory cycles, however there are other conditions under which you 
> might get 0xF, such as if the LPC2AHB isn't enabled. The BMC 
> aspeed-lpc-ctrl kernel driver should take care of this for you, however 
> it only does so once you open the character device. From there you'll 
> need to use the ioctl()s to switch the bridge to use the reserved 
> memory rather than the default mapping of the host SPI-NOR.
>
> Andrew

I can confirm that the BMC works with memory cycles on the LPC bus using this binding. There was a misconfiguration on the x86 side resulting
in it not generating memory cycles on the bus.

Govert