[OpenPower-Firmware] A few questions about early hostboot

Thu Sep 26 02:09:47 AEST 2019

On Wed, Sep 25, 2019 at 10:39:38AM -0500, Dean Sanner wrote:
> > > 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.
> 
Ah, ok, that's useful.
> 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.
> 
> > > > > > 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)
> 
Ok, that's what I was thinkingish, and I was fairly certain I was right
about it being 64 bytes large.
> 
> Dean Sanner
> dsanner at us.ibm.com