<html><body><p><tt><font size="2">> a machine after Hostboot has started running as I _think_ it activates all the <br>> cores.<br></font></tt><font size="2">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.</font><br><br><font size="2"><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</font><br><br><img width="16" height="16" src="cid:1__=09BB0E3CDFC1D5788f9e8a93df938690918c09B@" border="0" alt="Inactive hide details for Alistair Popple ---11/10/2019 11:54:06 AM---On Thursday, 26 September 2019 9:11:15 AM AEST Marty E. P"><font size="2" color="#424282">Alistair Popple ---11/10/2019 11:54:06 AM---On Thursday, 26 September 2019 9:11:15 AM AEST Marty E. Plummer wrote: > On Thu, Sep 26, 2019 at 08:</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Alistair Popple <apopple@linux.ibm.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"Marty E. Plummer" <hanetzer@startmail.com>, Amit J Tendolkar <amit.tendolkar@in.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Raja Das1 <rajadas2@in.ibm.com>, openpower-firmware@lists.ozlabs.org, Dean Sanner <dsanner@us.ibm.com>, Sachin Gupta24 <sgupta2m@in.ibm.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">11/10/2019 11:54 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [OpenPower-Firmware] A few questions about early hostboot</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"OpenPower-Firmware" <openpower-firmware-bounces+dcrowell=us.ibm.com@lists.ozlabs.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">On Thursday, 26 September 2019 9:11:15 AM AEST Marty E. Plummer wrote:<br>> On Thu, Sep 26, 2019 at 08:52:36AM +1000, Alistair Popple wrote:<br>> > On Thursday, 26 September 2019 7:11:55 AM AEST Marty E. Plummer wrote:<br>> > > On Wed, Sep 25, 2019 at 12:05:08PM -0500, Dean Sanner wrote:<br>> > > > > > I would recommend that you do a "pdbg -p0 -c4 -t0 hrmor" to <br>determine<br>> > > > > > the memory location where the HBBL is loaded (usually 0x08200000 <br>or<br>> > > > > > 0xF8200000 -- depends on where you started in op-build)<br>> > > > > ><br>> > > > > Forgive me if I'm missing something simple, but I can't find any<br>> > > > > reference to a hrmor command in the pdbg source or by strings'ing <br>the<br>> > > > > binaries.<br>> > > > <br>> > > > erm -- not sure that pdbg supports it... but would be a getspr like <br>this:<br>> > > > "pdbg -p0 -c4 -t0 gethrmor"<br>> > > Checking the source code seems to indicate that getspr 313 should<br>> > > return it; on stock hostboot it pops out xome 0x8xxxx address. However I<br>> > > can't get my cooked image to quiesce all the threads; ends up showing<br>> > > threads 0-3 on core 3 being 'A' according to threadstatus... Is there a<br>> > > 'quiesce' opcode one can use, like the nap one?<br>> > > > <br>> > > > Alistair -- does that exist?<br>> > <br>> > Yes, but we don't have a parser to convert friendly SPR names to numbers <br>> > (patches welcome though :-P) so as Marty points out using getspr 313 <br>works.<br>> > <br>> > I am not sure why you would end up with all 4 threads being active though. <br>On <br>> > my machine I get this for pdbg -a threadstatus:<br>> > <br>> > p0t: 0 1 2 3<br>> > c04: A.. ASQ ASQ ASQ <br>> > c05: .S. .S. .S. ... <br>> > c06: .S. .S. .S. ... <br>> > c07: .S. .S. .S. ... <br>> > c08: .S. .S. .S. ... <br>> > c09: .S. .S. .S. ... <br>> > c12: .S. .S. .S. ... <br>> > c13: .S. .S. .S. ..Q <br>> > c14: .S. .S. .S. ... <br>> > c15: .S. .S. .S. ... <br>> > c20: .S. .S. .S. ... <br>> > c21: .S. .S. .S. ... <br>> > <br>> > Hence I just have to stop thread 0 as threads 1-3 are not started by the <br>SBE. <br>> > You could try stopping all the threads on the core by passing -t0-3 but it <br>> > seems a bit strange. What does pdbg report when trying to stop a single <br>> > thread? If it says something like "Unable to queisce thread" it may be <br>that <br>> > the box has already crashed due to a bad memory access outside the cache <br>> > (which is easy to do).<br>> > <br>> Your core/thread numbering is a bit odd from what I'm expecting. system<br>> in question has double p9 nimbus cpus, 18c/72t each. I also don't get<br>> the dots. My output (stock hostboot somewhere along the boot path) is:<br><br>The machine I have is subjected to my abuses so some of my cores get guarded <br>unnecessarily guarded out. The output below is what I would expect to see from <br>a machine after Hostboot has started running as I _think_ it activates all the <br>cores.<br><br>> p0t: 0 1 2 3 4 5 6 7<br>> c23: A A A A <br>> c22: A A A A <br>> c19: A A A A <br>> c18: A A A A <br>> c17: A A A A <br>> c16: A A A A <br>> c15: A A A A <br>> c14: A A A A <br>> c13: A A A A <br>> c12: A A A A <br>> c11: A A A A <br>> c10: A A A A <br>> c09: A A A A <br>> c08: A A A A <br>> c03: A A A A <br>> c02: A A A A <br>> c01: A A A A <br>> c00: A A A A <br>> <br>> p1t: 0 1 2 3 4 5 6 7<br>> c23: A A A A <br>> c22: A A A A <br>> c21: A A A A <br>> c20: A A A A <br>> c19: A A A A <br>> c18: A A A A <br>> c17: A A A A <br>> c16: A A A A <br>> c09: A A A A <br>> c08: A A A A <br>> c07: A A A A <br>> c06: A A A A <br>> c05: A A A A <br>> c04: A A A A <br>> c03: A A A A <br>> c02: A A A A <br>> c01: A A A A <br>> c00: A A A A <br>> <br>> BMC is running raptor-v1.07 tag of their openbmc tree for the talos.<br>> <br>> To be frank atm I only have _start and _startpostmsr, almost 1:1 with<br>> the hostboot src/kernel/start.S code and a handful of intvects which are<br>> single ops (mostly I'm just trying to check that the code is even<br>> getting loaded; so far I've tried trap, b ., and nap lol, same effect).<br>> I assume after the enterHBB/switchToHBB rfid it starts executing at<br>> _start, right? I notice that intvect_inst_start just b _start, so I have<br>> that exactly the same in case that's the place. Perhaps there is some<br>> issue with my linker script (I notice that hbibl.elf starts at 0x3000<br>> and hbicore.elf starts at 0x0, so perhaps there is some issue there?).<br><br>The SBE seems to start the host boot bootloader at offset 0x3000 (I guess to <br>avoid exception vectors). I am not sure where it loads Hostboot itself though.<br><br>> Honestly if there was some opcode I could slap in just after _start to<br>> halt it all just so I can check that its where it should be that would<br>> be very useful.<br><br>"b ." (0x48000000) is my go to op-code (pun intended?) for stopping things so <br>I can debug/figure out what is going on so I'm not sure why it wouldn't be <br>working for you. If you have just that as your _start what does threadstatus <br>tell you?<br><br>- Alistair<br><br>> > Sorry if this is obvious to you, but for the getmem commands you will also <br>> > need to make sure you add hrmor to the address. Eg: If hrmor = 0x08200000 <br>> > (which seem likely based on your comments) then you should be able to read <br>> > memory from CPU address 0 like so:<br>> > <br>> > pdbg -p0 getmem 0x08200000 0x10 | hexdump -C<br>> > <br>> Yeah, I got that generally speaking. Though<br>> > (depending on which version you have it may or may not do a hexdump <br>itself, <br>> > but there were some bugs there).<br>> > <br>> > - Alistair<br>> > <br>> > > > <br>> > > > Dean Sanner<br>> > > > dsanner@us.ibm.com<br>> > > <br>> > <br>> > <br>> > <br>> > <br>> <br><br><br><br><br>_______________________________________________<br>OpenPower-Firmware mailing list<br>OpenPower-Firmware@lists.ozlabs.org<br><a href="https://lists.ozlabs.org/listinfo/openpower-firmware">https://lists.ozlabs.org/listinfo/openpower-firmware</a> <br><br></font></tt><br><br><BR>
</body></html>