[OpenPower-Firmware] A few questions about early hostboot

[Dean Sanner]

> > Actually it turns on P9 the existing pdbg getmem will work just fine in
the
> > early cache-contained mode. What wont work is putmem.
> >
> Is that pdbg getmem addr size or pdbg getmem -ci addr size? (or getmemio
> in later versions iiuc).

getmem addr size

The -ci says to do it cache inhibited (for MMIOs) -- since you want
to read out of cache... don't use this option :)


> > I should also note that there commands to manipulate thread
> registers as well
> > that should work in this environment. Eg:
> >
> > root at witherspoon:~# pdbg -p0 -c4 -t0 stop
> > root at witherspoon:~# pdbg -p0 -c4 -t0 getnia
> > p0:c4:t0: nia: 0x00000000082031b8
> > root at witherspoon:~# pdbg -p0 -c4 -t0 putnia 0x0000000008204000
> > p0:c4:t0: nia: 0x0000000008204000
> > root at witherspoon:~# pdbg -p0 -c4 -t0 start
> > root at witherspoon:~# pdbg -p0 -c4 -t0 stop
> > root at witherspoon:~# pdbg -p0 -c4 -t0 getnia
> > p0:c4:t0: nia: 0x000000000820d708
> >
> I assume here you're stopping/starting the process and reading the
> changed memory inside it?


This is stopping the executing thread and then getting the NIA SPR
from the HW, modifying and starting (think poor man's gdb).  There is
no memory modification, and that won't work with the "pdbg -p0 putmem"
due to HW limitations -- but you should be able to use "pdbg -p0 getmem"
to examine memory.

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)


> > > > > 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://urldefense.proofpoint.com/v2/
> url?
>
u=https-3A__github.com_open-2Dpower_hostboot_blob_master_&d=DwIBAg&c=jf_iaSHvJObTbx-

> siA1ZOg&r=hzmireE4QdtO-
>
sY4loLtQZfNF8nMdijKXQSf17Wwhnw&m=LDGE47walYMdU_gf7UTbjQwRE9nwgfA2gdE_Ox0nmzo&s=6VjnaXWAbM4B6WEv6Yun9D72wYr0Xomhon2y9J5w0VA&e=

> > 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
> > > > >
> > > > >
> > > Yeah about this, I have another question. The switchToHBB assembly in
> > > bl_start.S does something similar to here, mtsrr0 r4, rfid. I know
this
> > > means move the contents of that register to a given spr (855 being
the
> > > psscr reg and srr0 being, well, srr0) and then return from interrupt
> > > double, and I don't quite understand why that is done rather than
b/blr.
> > > I've been reading the ISA docs and I can't seem to find any
indication
> > > that mtspr triggers an interrupt, or does calling rfid without an
actual
> > > interrupt execute say system_reset or inst_start?
> >
> > The rfid instruction does exactly what it says in the ISA doc.
> That is it will
> > copy some of the contents of srr1 to the MSR and then set the next
> instruction
> > address to srr0.
> Oh, so 'set the next isntruction address to srr0' doesn't mean 'figure
> out the next instruction address and put it in srr0' but rather 'start
> executing again at the address in srr0'.

Exactly -- start executing again at address in srr0 with MSR in srr1.  This
allows
the code to start in BE, and then do a clean switch to LE.

> > Sometimes it is used like this for context synchronisation
> > such as when switching endian, however I'm not sure why
> specifically it's being
> > used here.
> >
> > FWIW skiboot does just do a mtmsr to clear MSR[TA] so perhaps it isn't
> > actually necessary, although I'm not sure it would ever be set entering

> > Skiboot anyway.
> >
> > > And one other thing, do you need to get to a certain istep before
pdbg
> > > starts to work? I've figured out (hopefully) a way to get the
existing
> > > hbbl to load my code path, and while right now its very much a stub
I'd
> > > like to at least try to read the cache memory to see if it actually
got
> > > in there (btw, the cache that hbb runs in, is that l1,2,3?) Or is
there
> > > some other thing I'm missing?
> >
> > I believe it runs out of L3. pdbg should work once you are past istep5
(ie.
> > one the Hostboot boot loader is running). For context what are
youtrying to
> > to load here? I missed the start of this thread, but I have played
> around with
> > altering the HBBL in the past and it is possible to do without
> breaking things
> > (if not a little involved).
> >

Correct, runs out of L3.


> Coreboot, actually. I've got some very stub code, and I think if I use
> the fpart utility to insert the headers it expects I can have hbbl load
> the coreboot bootblock. Problem is all the getmem variants I've tried
> are not pulling back anything. In fact it appears to hang forever until
> I ctrl+c the pdbg command, which is why I was wondering if there had to
> be more isteps done before I could use pdbg. Perhaps at that point it
> locked up because of a lack of ecc on the bootblock...

First thing is to figure out where HBBL gets loaded via the HRMOR pdbg
command
above.  Once you have this then you can read the right address.

>
> Related to all this, I see that hostboot bootloader has some
> BOOTLOADER_TRACE stuff. I think I see that the simics-debug-framework in
> the debug dir can read and interpret that data; how am I to use this?
> obmc doesn't ship with perl and I only have 32mb of flash to work with
> for the bmc.

You can manually read the data out with pdbg getmem at address of:
HRMOR + 0x8000 for 64 bytes.  Then each byte is a trace point that can be
looked up in "my %traceText" from the perl file (not elegant, but you can
at least get some data)


Dean Sanner
dsanner at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20190925/1a2ae850/attachment-0001.htm>