[OpenPower-Firmware] A few questions about early hostboot

[Marty E. Plummer]

On Fri, Sep 27, 2019 at 07:28:03AM -0500, Dean Sanner wrote:
> > > This is the output from Cronus when Hostboot is running:
> > > p9n.c   k0:n0:s0:p00:c2    0000000000000000: 686F7374 626F6F74
> [hostboot]
> > >
> > Ok cool. This returns 'starthbb' at the point I was at. Question, is
> > there some way to translate MMIO_SCRATCH_HOSTBOOT_ACTIVE = 0x18 to that
> > scom address, or is it one of those things you 'just know' from a table
> > or something?
> 
> Little of both :(  Technically it used to be documented in the Chip
> Pervasive
> spec -- however I couldn't find it in P8 or P9 pervasive specs.
> 
> The scom def however has just enough information to piece it together:
> 
> From src/kernel/misc.C, updateScratchReg:
> 
> // See EX07.EC.CC.PCC0.COMMON.SPR_COMMON.SCOMC in scomdef for
> // info on this offset - MODE_CX_SCOMC: 0000xxx = SCRATCH xx SPR
> // It's 0 for P9 so just pass through scratch reg offset
> 
> From the scomdef:
>
And what is the scomdef? Some documentation file?
>  Addr:  0000000020010A80 (SCOM)                         
>                                                         
>  Name:  EXP.EC.CC.PCC0.COMMON.SPR_COMMON.SCOMC          
>                                                         
> 
> 
> Bits 54:60
> 	MODE_CX_SCOMC:
> 	0000xxx = SCRATCH xx SPR   <-------------- This one
> 	0001xxx = TFMR xx SPR
> 	0010xxx = PURR xx SPR
> 	0011xxx = SPURR xx SPR
> 	0100xxx = DEC xx SPR
> 	0111000 = SPR_MODE
> 	0111001 = AVP Output Pin
> 	0111010 = Core Checkstop req
> 	0111011 = SPATTN SPR
> 	0111100 = Core Thread State
> 	1xxxxxx = Emmpath Counters
> 
> The Scomdef "Scratch Register 0" has the SPRD value of:
> Scratch Register 0  == 0000000020000000 (SPRD)
> Scratch Register 1  == 0000000020000001 (SPRD)
> Scratch Register 2  == 0000000020000002 (SPRD)
> Scratch Register 3  == 0000000020000003 (SPRD)
> 
> The scratch reg constants are 0x0, 0x8, 0x10, 0x18 and in BE
> that is counting bit 59:60 through 0, 1, 2, 3:
> 
>           1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123
> 0000000000000000000000000000000000000000000000000000000000011000
> 0   0   0   0   0   0   0   0   0   0   0   0   0   0   1   8
> 
> 
> So what is happening is the scratch reg number is being set into
> SPRC bits 54:60, which correlates to the 0000xxx, which ties to
> the SPRD value in the scomdef.
> 
> 
> Absolutely crystal clear -- not!  :(
> 
Yeh, this is a very 'fun' architecture, to say the least.
> Does that make sense?
> 

On an unrelated note, I've a bit of a question about CpuManager::cv_cpus's
use in src/kernel/start.S; this segment of assembly/c++ interaction is a
bit difficult for me to understand what's going on:

# easy enough, get the address of the array
lis r2, _ZN10CpuManager7cv_cpusE at h
ori r2, r2, _ZN10CpuManager7cv_cpusE at l

# also easy, get the pir reg into a usable reg, r1
mfspr r1, PIR

# not quite sure what's going on here. 'Match PIR format(KERNEL_MAX_SUPPORTED_CPUS_PER_NODE)'
extrwi r1, r1, 3, 18
sldi r1, r1, 3
ldx r2, r1, r2 // r2 has CpuManager::cv_cpus address, r1 has manipulated PIR
cmpwi cr0, r2, 0 // comparison of some sort, 'check for NULL node array'
beq- _start // go back to _start if the comparison succeeds?

# get the pir again 'extract on-node cpu id'
mfspr r1, PIR
clrlslwi, r1, r1, 22, 3
ldx r2, r1, r2 // load cpu object
....
And so on. I  assume there is some bitshifting/bitmasking here to get
the pir output into a 'normalized' state for comparisons but I'm not
certain 'what it should look like'.
> Dean Sanner
> dsanner at us.ibm.com