[OpenPower-Firmware] A few questions about early hostboot

[Marty E. Plummer]

On Wed, Sep 25, 2019 at 10:39:11PM +1000, Alistair Popple wrote:
> > > 
> > > There is nothing that ties pdbg specifically to debugging the kernel (for 
> > > example it can equally be used to debug skiboot as well). For Hostboot 
> there 
> > > are a couple of things needed though:
> > > 
> > > 1. As Stewart/Dean said - an implementation of getmempba and the option to 
> use 
> > > it instead of getmemproc
> > > 
> > Ok, interesting.
> 
> Actually it turns on P9 the existing pdbg getmem will work just fine in the 
> early cache-contained mode. What wont work is putmem.
> 
Is that pdbg getmem addr size or pdbg getmem -ci addr size? (or getmemio
in later versions iiuc).
> I should also note that there commands to manipulate thread registers as well 
> that should work in this environment. Eg:
> 
> root at witherspoon:~# pdbg -p0 -c4 -t0 stop
> root at witherspoon:~# pdbg -p0 -c4 -t0 getnia
> p0:c4:t0: nia: 0x00000000082031b8
> root at witherspoon:~# pdbg -p0 -c4 -t0 putnia 0x0000000008204000
> p0:c4:t0: nia: 0x0000000008204000
> root at witherspoon:~# pdbg -p0 -c4 -t0 start
> root at witherspoon:~# pdbg -p0 -c4 -t0 stop
> root at witherspoon:~# pdbg -p0 -c4 -t0 getnia
> p0:c4:t0: nia: 0x000000000820d708
> 
I assume here you're stopping/starting the process and reading the
changed memory inside it?
> > > > There is nothing that prevents Hostboot from running LE mode -- just 
> > > > the amount of work to port it :)
> > > > 
> > > > MSR bit 63 controls the LE/BE mode (where 0b0 is BE, 0b1 is LE).  If
> > > > you want to trampoline early in HB to switch you can setup the srr0/1
> > > > and then rfid to make it take effect.   You could hook it into the 
> > > > following code from https://github.com/open-power/hostboot/blob/master/
> src/
> > > kernel/start.S
> > > > (note that this part would need to be BE, all code after _start_postmsr
> > > > would need to be LE)
> > > > 
> > > > .global _start
> > > > _start:
> > > >     ;// Set thread priority high.
> > > >     or 2,2,2
> > > > 
> > > >     ;// Clear MSR[TA] (bit 1)
> > > >     mfmsr r2
> > > >     rldicl r2,r2,1,1    ;// Clear bit 1 - result [1-63,0]
> > > >     rotrdi r2,r2,1      ;// Rotate right 1 - result [0,63]
> > > >     ;// Set up SRR0 / SRR1 to enable new MSR.
> > > >     mtsrr1 r2
> > > >     li r2, _start_postmsr at l
> > > >     mtsrr0 r2
> > > >     lis     r9,49      ;// Want to default the NAP value
> > > >     ori     r9,r9,1    ;// Value is 0x0000000000310001
> > > >     mtspr   855,r9     ;// set actual PSSCR
> > > >     rfid
> > > > 
> > > > 
> > Yeah about this, I have another question. The switchToHBB assembly in
> > bl_start.S does something similar to here, mtsrr0 r4, rfid. I know this
> > means move the contents of that register to a given spr (855 being the
> > psscr reg and srr0 being, well, srr0) and then return from interrupt
> > double, and I don't quite understand why that is done rather than b/blr.
> > I've been reading the ISA docs and I can't seem to find any indication
> > that mtspr triggers an interrupt, or does calling rfid without an actual
> > interrupt execute say system_reset or inst_start?
> 
> The rfid instruction does exactly what it says in the ISA doc. That is it will 
> copy some of the contents of srr1 to the MSR and then set the next instruction 
> address to srr0.
Oh, so 'set the next isntruction address to srr0' doesn't mean 'figure
out the next instruction address and put it in srr0' but rather 'start
executing again at the address in srr0'.
> Sometimes it is used like this for context synchronisation 
> such as when switching endian, however I'm not sure why specifically it's being 
> used here.
> 
> FWIW skiboot does just do a mtmsr to clear MSR[TA] so perhaps it isn't 
> actually necessary, although I'm not sure it would ever be set entering 
> Skiboot anyway.
>  
> > And one other thing, do you need to get to a certain istep before pdbg
> > starts to work? I've figured out (hopefully) a way to get the existing
> > hbbl to load my code path, and while right now its very much a stub I'd
> > like to at least try to read the cache memory to see if it actually got
> > in there (btw, the cache that hbb runs in, is that l1,2,3?) Or is there
> > some other thing I'm missing?
> 
> I believe it runs out of L3. pdbg should work once you are past istep5 (ie. 
> one the Hostboot boot loader is running). For context what are you trying to 
> to load here? I missed the start of this thread, but I have played around with 
> altering the HBBL in the past and it is possible to do without breaking things 
> (if not a little involved).
> 
Coreboot, actually. I've got some very stub code, and I think if I use
the fpart utility to insert the headers it expects I can have hbbl load
the coreboot bootblock. Problem is all the getmem variants I've tried
are not pulling back anything. In fact it appears to hang forever until
I ctrl+c the pdbg command, which is why I was wondering if there had to
be more isteps done before I could use pdbg. Perhaps at that point it
locked up because of a lack of ecc on the bootblock...

Related to all this, I see that hostboot bootloader has some
BOOTLOADER_TRACE stuff. I think I see that the simics-debug-framework in
the debug dir can read and interpret that data; how am I to use this?
obmc doesn't ship with perl and I only have 32mb of flash to work with
for the bmc.
> - Alistair
> 
> > > > Or you can write the MSR in the SBE code where it manipulates 
> > > > the starting threads architected state:
> > > > https://github.com/open-power/sbe/blob/master/src/import/chips/p9/
> > > procedures/hwp/nest/p9_sbe_load_bootloader.C
> > > > 
> > > > 
> > > > Dean Sanner
> > > > dsanner at us.ibm.com
> > > >  
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 
>