[OpenPower-Firmware] A few questions about early hostboot

Alistair Popple apopple at linux.ibm.com
Tue Sep 10 16:40:32 AEST 2019


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






More information about the OpenPower-Firmware mailing list