[Skiboot] [PATCH v2 09/12] opal: Inform fsp about the topology switch.
Patrick Williams III
iawillia at us.ibm.com
Thu Jul 9 21:17:41 AEST 2015
I don't think we have all the code to rebuild a TOD topology in hbrt today, but it probably could be added. The FIR bit to indicate to PRD is still appropriate. We would need an opal interface to indicate "done".
It might be easier to just make "create new topology" a HBRT interface so you clearly know when it is done. This avoids the FIR and mailbox replacement.
Sent from my iPhone
> On Jul 9, 2015, at 1:24 AM, Stewart Smith <stewart at linux.vnet.ibm.com> wrote:
> Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> writes:
>> From: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
>> After the topology switch, we may have a non-functional backup topology.
>> This means, we won't be able to recover from future TOD errors that
>> requires topology switch. Someone needs to either fix it OR configure
>> new functional backup topology.
>> Bit 18 of the Pervasive local FIR (SCOM: EH.TPCHIP.TPC.LOCAL_FIR: 0x0104000C)
>> is used to signal that TOD error analysis needs to be performed. This
>> allows FSP/PRD to investigate and re-configure new backup topology if
>> required. Once new backup topology is configured and ready, FSP sends a
>> mailbox command xE6, s/c 0x06, mod 0, to enable the backup topology.
>> This isn't documented anywhere. This info is provided by FSP folks.
>> This patch implements setting of bit 18 in Pervasive local FIR. The next
>> patch will handle FSP mailbox command xE6, s/c 0x06, mod 0.
> What should we do on OpenPower? Should this be something we signal
> opal-prd to deal with?
> I'm okay with merging this as is, but would like to know what we should
> do on OpenPower if we want to handle this case.
> Skiboot mailing list
> Skiboot at lists.ozlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Skiboot