[OpenPower-Firmware] A few questions about early hostboot

[Marty E. Plummer]

On Tue, Sep 10, 2019 at 04:40:13PM +1000, Alistair Popple wrote:
> On Tuesday, 10 September 2019 4:20:26 PM AEST Sachin Gupta24 wrote:
> > Yeah. This was done using remote gdb support in pdbg. We did this using fsp 
> variant of sbe chipops.  SBE chipop code for this went in pdbg repo <https://
> github.rtp.raleigh.ibm.com/shakeebbk-in/pdbg-sbe/commits/master>. It is 
> internal repo as at that time pdbg was not part of openbmc. If you want to 
> access code, Alistair should be able to help in that.
> 
That would be of use eventually, though I'm trying to run against
unmodified SBE and hbbl code.
> Some of the SBE Chipop code should be upstream now. However it's still a work 
> in progress as we don't yet have full support for register access, etc. That 
> said you also shouldn't *need* to use the chip-ops to do this - the 
> implementation we have in pdbg should work and once the chip-op support is 
> available things will switch to that transparently.
> 
> > Hi Marty,
> > 
> > > I have a few additional questions about early hostboot on the power9
> > > platform.
> > >
> > > I know pdbg has a gdbserver which currently only works on p8 and linux
> > > kernel (though I may be misinterpreting the latter half). I assume the
> > > lack of power9 support is just some missing code for now, but I wonder
> > > about only supporting the linux kernel. Is there some deep-seated reason
> > > one could not use gbdserver on hostboot itself? It could be very useful
> > > for early debugging.
> 
> It should support P9 as well, although it's fair to say it doesn't get a whole 
> lot of testing (at least as far as I know).
>  
> > Stewart is correct -- there is just a different way of accessing the memory
> > (getmempba versus getmemproc).  I know that the IBM's SBE team had a 
> > prototype of gdbg working against hostboot a while back.  I've copied
> > them on this email to see if it is still viable (there were some issues
> > with the virtual pages for the extended image, but if you are only 
> > using it for early debug -- might not be an issue).
> 
> 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.
> 2. Page table walking code to convert virtual to physical addresses based on 
> CPU context. This problem exists equally for Linux debugging, except that for 
> the kernel we can just mask the top two bits (0xC....) to get the real 
> address. Obviously this doesn't work so well for userspace although there may 
> be some similar hack we could apply for Hostboot debugging.
> 
> - Alistair
> 
> > > 
> > > Power9 processors are able to operate in both BE and LE mode, and I am
> > > having a bit of issue following this idea. Is there some register one
> > > sets to switch mode I'm missing, or does the processor just 'know' that
> > > 0xdeadbeef and 0xefbeadde are the same? Forgive me if this is a bad
> > > example but hopefully it gets my point across. In addition, is there any
> > > reason that hostboot couldn't be ran in either big or little endian
> > > (after endian specific code is fixed, obviously)?
> > 
> > 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?

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?
> > 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
> >  
> > 
> > 
> 
> 
> 
>