[OpenPower-Firmware] A few questions about early hostboot

[Marty E. Plummer]

On Thu, Sep 26, 2019 at 08:52:36AM +1000, Alistair Popple wrote:
> 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).
> 
Your core/thread numbering is a bit odd from what I'm expecting. system
in question has double p9 nimbus cpus, 18c/72t each. I also don't get
the dots. My output (stock hostboot somewhere along the boot path) is:
p0t: 0 1 2 3 4 5 6 7
c23: A A A A        
c22: A A A A        
c19: A A A A        
c18: A A A A        
c17: A A A A        
c16: A A A A        
c15: A A A A        
c14: A A A A        
c13: A A A A        
c12: A A A A        
c11: A A A A        
c10: A A A A        
c09: A A A A        
c08: A A A A        
c03: A A A A        
c02: A A A A        
c01: A A A A        
c00: A A A A        

p1t: 0 1 2 3 4 5 6 7
c23: A A A A        
c22: A A A A        
c21: A A A A        
c20: A A A A        
c19: A A A A        
c18: A A A A        
c17: A A A A        
c16: A A A A        
c09: A A A A        
c08: A A A A        
c07: A A A A        
c06: A A A A        
c05: A A A A        
c04: A A A A        
c03: A A A A        
c02: A A A A        
c01: A A A A        
c00: A A A A        

BMC is running raptor-v1.07 tag of their openbmc tree for the talos.

To be frank atm I only have _start and _startpostmsr, almost 1:1 with
the hostboot src/kernel/start.S code and a handful of intvects which are
single ops (mostly I'm just trying to check that the code is even
getting loaded; so far I've tried trap, b ., and nap lol, same effect).
I assume after the enterHBB/switchToHBB rfid it starts executing at
_start, right? I notice that intvect_inst_start just b _start, so I have
that exactly the same in case that's the place. Perhaps there is some
issue with my linker script (I notice that hbibl.elf starts at 0x3000
and hbicore.elf starts at 0x0, so perhaps there is some issue there?).

Honestly if there was some opcode I could slap in just after _start to
halt it all just so I can check that its where it should be that would
be very useful.
> 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
> 
Yeah, I got that generally speaking. Though
> (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
> > 
> 
> 
> 
>