[OpenPower-Firmware] A few questions about early hostboot

Tue Nov 12 02:01:27 AEDT 2019

> a machine after Hostboot has started running as I _think_ it activates
all the
> cores.
The bootloader only runs on a single thread.  When HB userspace begins we
start up the other 3 threads on the master core.  The other cores/threads
don't run until istep16.

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com

From:	Alistair Popple <apopple at linux.ibm.com>
To:	"Marty E. Plummer" <hanetzer at startmail.com>, Amit J Tendolkar
            <amit.tendolkar at in.ibm.com>
Cc:	Raja Das1 <rajadas2 at in.ibm.com>,
            openpower-firmware at lists.ozlabs.org, Dean Sanner
            <dsanner at us.ibm.com>, Sachin Gupta24 <sgupta2m at in.ibm.com>
Date:	11/10/2019 11:54 AM
Subject:	[EXTERNAL] Re: [OpenPower-Firmware] A few questions about early
            hostboot
Sent by:	"OpenPower-Firmware" <openpower-firmware-bounces
            +dcrowell=us.ibm.com at lists.ozlabs.org>

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

_______________________________________________
OpenPower-Firmware mailing list
OpenPower-Firmware at lists.ozlabs.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_listinfo_openpower-2Dfirmware&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=mCj3CQvqek9g0fdziO-GEHyU1m9T3SAh0ZPd5s_AGpo&m=1PBZziA03UvrJuE4kpvKc9bRApC6qP9O4QIXdikvcTg&s=pigPsNBEAyOo-XUdLwi6E0M1hOfoALBNR1SNt2hfeGA&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20191111/0e0b03cf/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20191111/0e0b03cf/attachment.gif>