[OpenPower-Firmware] A few questions about early hostboot

Tue Sep 10 16:56:49 AEST 2019

On Tuesday, 10 September 2019 4:46:13 PM AEST Sachin Gupta24 wrote:
> Allistair
>  
> This branch should also have address translation code which is required to 
put breakpoint. Address translation logic is different between HYP/Hostboot. 

Ok. In the ideal world we would have code to actually go and walk the HW page 
tables if required rather than hard coded translations based on specific 
projects. Obviously that requires a fair bit of work to make happen though.

It also reminds me of the hack we had on P8 to make this function. On P8 we 
were able to ram memory access instructions into the core which allowed us to 
use the HW itself to do the address translation and memory access (or generate 
a fault). However ramming memory access instructions isn't supported on P9 so 
it doesn't work there. Although in any case it was still a hack - best to be 
walk the tables in SW rather than risk generating a fault and possibly 
crashing the host process.

- Alistair

> Regards
> Sachin
>  
> ----- Original message -----
> From: "Alistair Popple" <apopple at linux.ibm.com>
> To: Sachin Gupta24/India/IBM at IBMIN
> Cc: "Dean Sanner" <dsanner at us.ibm.com>, Amit J Tendolkar/India/IBM at IBMIN, 
Raja Das1/India/IBM at IBMIN, hanetzer at startmail.com, openpower-
firmware at lists.ozlabs.org, alistair at ozlabs.au.ibm.com
> Subject: Re: A few questions about early hostboot
> Date: Tue, Sep 10, 2019 12:10 PM
>  
> 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.
> 
> 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
> 
> 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
> >
> >
> > 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
> >  
> >
> > 
> 
> 
> 
>  
>  
> 
> 