[OpenPower-Firmware] A few questions about early hostboot

[Alistair Popple]

On Thursday, 26 September 2019 9:11:15 AM AEST Marty E. Plummer wrote:
> 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:

The machine I have is subjected to my abuses so some of my cores get guarded 
unnecessarily guarded out. The output below is what I would expect to see from 
a machine after Hostboot has started running as I _think_ it activates all the 
cores.

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

The SBE seems to start the host boot bootloader at offset 0x3000 (I guess to 
avoid exception vectors). I am not sure where it loads Hostboot itself though.

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

"b ." (0x48000000) is my go to op-code (pun intended?) for stopping things so 
I can debug/figure out what is going on so I'm not sure why it wouldn't be 
working for you. If you have just that as your _start what does threadstatus 
tell you?

- Alistair

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