[OpenPower-Firmware] LPC Address space questions

Marty E. Plummer hanetzer at startmail.com
Thu Oct 8 23:37:26 AEDT 2020


On Wed, Oct 07, 2020 at 03:55:09AM +0000, Daniel M Crowell wrote:
> On Tue, Oct 06, 2020 at 06:41:00AM, Marty E. Plummer wrote:
>> Hello again.
>> POWER9 Processor Registers Specification v1 specifies
>> BRIDGE.AD.LPC_BASE_REG (SCOM 0x90040) as setting the base address for
>> lpc. Using pdbg getscom I was able to see it mapped to the following:
>> pdbg -a getscom 0x90040
>> p0:0x90040 = 0x0006030000000000
>> p1:0x90040 = 0x0006230000000000
>> So in theory, you *could* put it anywhere. My question is, in practice,
>> is anything other than 0x0006030000000000 used for the first processor?
>> I'm probably going to hard-code it for now, but if it can/does change it
>> would be good to know and be able to config it.
>> Regards,
>> Marty
> If there is no functional memory behind proc0 we will remap the fabric id to maintain memory at
> physical address zero.  This results in the entire MMIO space to be remapped as well, including
> the LPC space.  Check out targetservicestart.C for some of the logic.  That should give a basic
> idea of all of the attributes involved.  It is the SBE logic that sets up the LPC and XSCOM BAR,
> the values to use are customized into the SEEPROM by Hostboot based on the attributes that exist
> there.  The SBE pushes the BAR values up as part of the communication area it leaves around for
> HBBL to consume.  HBBL then pushes it to HB.
> 
> https://github.com/open-power/hostboot/blob/master/src/include/arch/memorymap.H has some more
> information on how the memory map is organized.
> https://github.com/open-power/hostboot/blob/master/src/usr/targeting/common/processMrw.pl#L1442
> shows some computation to set the values.
So the SBE sets it up at 0x0006030000000000, and if needed hostboot will
move it? What would a situation 'no functional memory behind proc0' look
like in practice? No dram plugged into the proc0 sockets, or busted
dram? I'm getting close to having something half-working on the qemu
powernv target, which is quite nice. There are a lot of endian issues to
be worked out, though.


More information about the OpenPower-Firmware mailing list