[OpenPower-Firmware] A few questions about early hostboot

Alistair Popple apopple at linux.ibm.com
Thu Sep 26 08:52:56 AEST 2019


On Thursday, 26 September 2019 7:11:55 AM AEST Marty E. Plummer wrote:
> On Wed, Sep 25, 2019 at 12:05:08PM -0500, Dean Sanner wrote:
> > > > I would recommend that you do a "pdbg -p0 -c4 -t0 hrmor" to determine
> > > > the memory location where the HBBL is loaded (usually 0x08200000 or
> > > > 0xF8200000 -- depends on where you started in op-build)
> > > >
> > > Forgive me if I'm missing something simple, but I can't find any
> > > reference to a hrmor command in the pdbg source or by strings'ing the
> > > binaries.
> > 
> > erm -- not sure that pdbg supports it... but would be a getspr like this:
> > "pdbg -p0 -c4 -t0 gethrmor"
> Checking  the source code seems to indicate that getspr 313 should
> return it; on stock hostboot it pops out xome 0x8xxxx address. However I
> can't get my cooked image to quiesce all the threads; ends up showing
> threads 0-3 on core 3 being 'A' according to threadstatus... Is there a
> 'quiesce' opcode one can use, like the nap one?
> > 
> > Alistair -- does that exist?

Yes, but we don't have a parser to convert friendly SPR names to numbers 
(patches welcome though :-P) so as Marty points out using getspr 313 works.

I am not sure why you would end up with all 4 threads being active though. On 
my machine I get this for pdbg -a threadstatus:

p0t:   0   1   2   3
c04:  A.. ASQ ASQ ASQ 
c05:  .S. .S. .S. ... 
c06:  .S. .S. .S. ... 
c07:  .S. .S. .S. ... 
c08:  .S. .S. .S. ... 
c09:  .S. .S. .S. ... 
c12:  .S. .S. .S. ... 
c13:  .S. .S. .S. ..Q 
c14:  .S. .S. .S. ... 
c15:  .S. .S. .S. ... 
c20:  .S. .S. .S. ... 
c21:  .S. .S. .S. ... 

Hence I just have to stop thread 0 as threads 1-3 are not started by the SBE. 
You could try stopping all the threads on the core by passing -t0-3 but it 
seems a bit strange. What does pdbg report when trying to stop a single 
thread? If it says something like "Unable to queisce thread" it may be that 
the box has already crashed due to a bad memory access outside the cache 
(which is easy to do).

Sorry if this is obvious to you, but for the getmem commands you will also 
need to make sure you add hrmor to the address. Eg: If hrmor = 0x08200000 
(which seem likely based on your comments) then you should be able to read 
memory from CPU address 0 like so:

pdbg -p0 getmem 0x08200000 0x10 | hexdump -C

(depending on which version you have it may or may not do a hexdump itself, 
but there were some bugs there).

- Alistair

> > 
> > Dean Sanner
> > dsanner at us.ibm.com
> 






More information about the OpenPower-Firmware mailing list