<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><font size="2" face="Default Monospace,Courier New,Courier,monospace" >> What would a situation 'no functional memory behind proc0' look<br>> like in practice? No dram plugged into the proc0 sockets, or busted<br>> dram?</font></div>
<div class="mail-signature-container" dir="ltr" >Yes, either case could cause it.  Either nothing is installed or we find errors and deconfigure/gard what is installed.</div>
<div class="mail-signature-container" dir="ltr" ><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" data-history-expanded="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Marty E. Plummer" <hanetzer@startmail.com><br>To: Daniel M Crowell <dcrowell@us.ibm.com><br>Cc: openpower-firmware@lists.ozlabs.org<br>Subject: [EXTERNAL] Re: [OpenPower-Firmware] LPC Address space questions<br>Date: Thu, Oct 8, 2020 7:37 AM<br> 
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >On Wed, Oct 07, 2020 at 03:55:09AM +0000, Daniel M Crowell wrote:<br>> On Tue, Oct 06, 2020 at 06:41:00AM, Marty E. Plummer wrote:<br>>> Hello again.<br>>> POWER9 Processor Registers Specification v1 specifies<br>>> BRIDGE.AD.LPC_BASE_REG (SCOM 0x90040) as setting the base address for<br>>> lpc. Using pdbg getscom I was able to see it mapped to the following:<br>>> pdbg -a getscom 0x90040<br>>> p0:0x90040 = 0x0006030000000000<br>>> p1:0x90040 = 0x0006230000000000<br>>> So in theory, you *could* put it anywhere. My question is, in practice,<br>>> is anything other than 0x0006030000000000 used for the first processor?<br>>> I'm probably going to hard-code it for now, but if it can/does change it<br>>> would be good to know and be able to config it.<br>>> Regards,<br>>> Marty<br>> If there is no functional memory behind proc0 we will remap the fabric id to maintain memory at<br>> physical address zero.  This results in the entire MMIO space to be remapped as well, including<br>> the LPC space.  Check out targetservicestart.C for some of the logic.  That should give a basic<br>> idea of all of the attributes involved.  It is the SBE logic that sets up the LPC and XSCOM BAR,<br>> the values to use are customized into the SEEPROM by Hostboot based on the attributes that exist<br>> there.  The SBE pushes the BAR values up as part of the communication area it leaves around for<br>> HBBL to consume.  HBBL then pushes it to HB.<br>><br>> <a href="https://github.com/open-power/hostboot/blob/master/src/include/arch/memorymap.H" target="_blank">https://github.com/open-power/hostboot/blob/master/src/include/arch/memorymap.H</a>  has some more<br>> information on how the memory map is organized.<br>> <a href="https://github.com/open-power/hostboot/blob/master/src/usr/targeting/common/processMrw.pl#L1442" target="_blank">https://github.com/open-power/hostboot/blob/master/src/usr/targeting/common/processMrw.pl#L1442</a> <br>> shows some computation to set the values.<br>So the SBE sets it up at 0x0006030000000000, and if needed hostboot will<br>move it? What would a situation 'no functional memory behind proc0' look<br>like in practice? No dram plugged into the proc0 sockets, or busted<br>dram? I'm getting close to having something half-working on the qemu<br>powernv target, which is quite nice. There are a lot of endian issues to<br>be worked out, though.</font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>