<html><body><p><tt><font size="2">> > Actually it turns on P9 the existing pdbg getmem will work just fine in the <br>> > early cache-contained mode. What wont work is putmem.<br>> > <br>> Is that pdbg getmem addr size or pdbg getmem -ci addr size? (or getmemio<br>> in later versions iiuc).<br></font></tt><br><tt><font size="2">getmem addr size</font></tt><br><br><tt><font size="2">The -ci says to do it cache inhibited (for MMIOs) -- since you want</font></tt><br><tt><font size="2">to read out of cache... don't use this option :)</font></tt><br><br><br><tt><font size="2">> > I should also note that there commands to manipulate thread <br>> registers as well <br>> > that should work in this environment. Eg:<br>> > <br>> > root@witherspoon:~# pdbg -p0 -c4 -t0 stop<br>> > root@witherspoon:~# pdbg -p0 -c4 -t0 getnia<br>> > p0:c4:t0: nia: 0x00000000082031b8<br>> > root@witherspoon:~# pdbg -p0 -c4 -t0 putnia 0x0000000008204000<br>> > p0:c4:t0: nia: 0x0000000008204000<br>> > root@witherspoon:~# pdbg -p0 -c4 -t0 start<br>> > root@witherspoon:~# pdbg -p0 -c4 -t0 stop<br>> > root@witherspoon:~# pdbg -p0 -c4 -t0 getnia<br>> > p0:c4:t0: nia: 0x000000000820d708<br>> > <br>> I assume here you're stopping/starting the process and reading the<br>> changed memory inside it?<br></font></tt><br><br><tt><font size="2">This is stopping the executing thread and then getting the NIA SPR</font></tt><br><tt><font size="2">from the HW, modifying and starting (think poor man's gdb). There is</font></tt><br><tt><font size="2">no memory modification, and that won't work with the "pdbg -p0 putmem" </font></tt><br><tt><font size="2">due to HW limitations -- but you should be able to use "pdbg -p0 getmem" </font></tt><br><tt><font size="2">to examine memory.</font></tt><br><br><tt><font size="2">I would recommend that you do a "pdbg -p0 -c4 -t0 hrmor" to determine</font></tt><br><tt><font size="2">the memory location where the HBBL is loaded (usually 0x08200000 or</font></tt><br><tt><font size="2">0xF8200000 -- depends on where you started in op-build)</font></tt><br><br><br><tt><font size="2">> > > > > There is nothing that prevents Hostboot from running LE mode -- just <br>> > > > > the amount of work to port it :)<br>> > > > > <br>> > > > > MSR bit 63 controls the LE/BE mode (where 0b0 is BE, 0b1 is LE). If<br>> > > > > you want to trampoline early in HB to switch you can setup the srr0/1<br>> > > > > and then rfid to make it take effect. You could hook it into the <br>> > > > > following code from <a href="https://urldefense.proofpoint.com/v2/">https://urldefense.proofpoint.com/v2/</a><br>> url?<br>> u=https-3A__github.com_open-2Dpower_hostboot_blob_master_&d=DwIBAg&c=jf_iaSHvJObTbx-<br>> siA1ZOg&r=hzmireE4QdtO-<br>> sY4loLtQZfNF8nMdijKXQSf17Wwhnw&m=LDGE47walYMdU_gf7UTbjQwRE9nwgfA2gdE_Ox0nmzo&s=6VjnaXWAbM4B6WEv6Yun9D72wYr0Xomhon2y9J5w0VA&e=<br>> > src/<br>> > > > kernel/start.S<br>> > > > > (note that this part would need to be BE, all code after <br>> _start_postmsr<br>> > > > > would need to be LE)<br>> > > > > <br>> > > > > .global _start<br>> > > > > _start:<br>> > > > > ;// Set thread priority high.<br>> > > > > or 2,2,2<br>> > > > > <br>> > > > > ;// Clear MSR[TA] (bit 1)<br>> > > > > mfmsr r2<br>> > > > > rldicl r2,r2,1,1 ;// Clear bit 1 - result [1-63,0]<br>> > > > > rotrdi r2,r2,1 ;// Rotate right 1 - result [0,63]<br>> > > > > ;// Set up SRR0 / SRR1 to enable new MSR.<br>> > > > > mtsrr1 r2<br>> > > > > li r2, _start_postmsr@l<br>> > > > > mtsrr0 r2<br>> > > > > lis r9,49 ;// Want to default the NAP value<br>> > > > > ori r9,r9,1 ;// Value is 0x0000000000310001<br>> > > > > mtspr 855,r9 ;// set actual PSSCR<br>> > > > > rfid<br>> > > > > <br>> > > > > <br>> > > Yeah about this, I have another question. The switchToHBB assembly in<br>> > > bl_start.S does something similar to here, mtsrr0 r4, rfid. I know this<br>> > > means move the contents of that register to a given spr (855 being the<br>> > > psscr reg and srr0 being, well, srr0) and then return from interrupt<br>> > > double, and I don't quite understand why that is done rather than b/blr.<br>> > > I've been reading the ISA docs and I can't seem to find any indication<br>> > > that mtspr triggers an interrupt, or does calling rfid without an actual<br>> > > interrupt execute say system_reset or inst_start?<br>> > <br>> > The rfid instruction does exactly what it says in the ISA doc. <br>> That is it will <br>> > copy some of the contents of srr1 to the MSR and then set the next<br>> instruction <br>> > address to srr0.<br>> Oh, so 'set the next isntruction address to srr0' doesn't mean 'figure<br>> out the next instruction address and put it in srr0' but rather 'start<br>> executing again at the address in srr0'.<br></font></tt><br><tt><font size="2">Exactly -- start executing again at address in srr0 with MSR in srr1. This allows</font></tt><br><tt><font size="2">the code to start in BE, and then do a clean switch to LE.</font></tt><br><br><tt><font size="2">> > Sometimes it is used like this for context synchronisation <br>> > such as when switching endian, however I'm not sure why <br>> specifically it's being <br>> > used here.<br>> > <br>> > FWIW skiboot does just do a mtmsr to clear MSR[TA] so perhaps it isn't <br>> > actually necessary, although I'm not sure it would ever be set entering <br>> > Skiboot anyway.<br>> > <br>> > > And one other thing, do you need to get to a certain istep before pdbg<br>> > > starts to work? I've figured out (hopefully) a way to get the existing<br>> > > hbbl to load my code path, and while right now its very much a stub I'd<br>> > > like to at least try to read the cache memory to see if it actually got<br>> > > in there (btw, the cache that hbb runs in, is that l1,2,3?) Or is there<br>> > > some other thing I'm missing?<br>> > <br>> > I believe it runs out of L3. pdbg should work once you are past istep5 (ie. <br>> > one the Hostboot boot loader is running). For context what are youtrying to <br>> > to load here? I missed the start of this thread, but I have played<br>> around with <br>> > altering the HBBL in the past and it is possible to do without <br>> breaking things <br>> > (if not a little involved).<br>> > <br></font></tt><br><tt><font size="2">Correct, runs out of L3.</font></tt><br><br><br><tt><font size="2">> Coreboot, actually. I've got some very stub code, and I think if I use<br>> the fpart utility to insert the headers it expects I can have hbbl load<br>> the coreboot bootblock. Problem is all the getmem variants I've tried<br>> are not pulling back anything. In fact it appears to hang forever until<br>> I ctrl+c the pdbg command, which is why I was wondering if there had to<br>> be more isteps done before I could use pdbg. Perhaps at that point it<br>> locked up because of a lack of ecc on the bootblock...<br></font></tt><br><tt><font size="2">First thing is to figure out where HBBL gets loaded via the HRMOR pdbg command</font></tt><br><tt><font size="2">above. Once you have this then you can read the right address.</font></tt><br><br><tt><font size="2">> <br>> Related to all this, I see that hostboot bootloader has some<br>> BOOTLOADER_TRACE stuff. I think I see that the simics-debug-framework in<br>> the debug dir can read and interpret that data; how am I to use this?<br>> obmc doesn't ship with perl and I only have 32mb of flash to work with<br>> for the bmc.<br></font></tt><br><tt><font size="2">You can manually read the data out with pdbg getmem at address of:<br>HRMOR + 0x</font></tt><tt><font size="2">8000 for 64 bytes. Then each byte is a trace point that can be </font></tt><br><tt><font size="2">looked up in </font></tt><tt><font size="2">"my %traceText" from the perl file (not elegant, but you can</font></tt><br><tt><font size="2">at least get some data)</font></tt><br><br><br><font size="2">Dean Sanner<br>dsanner@us.ibm.com<br></font><BR>
</body></html>