<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >Allistair</div>
<div dir="ltr" > </div>
<div dir="ltr" >This branch should also have address translation code which is required to put breakpoint. Address translation logic is different between HYP/Hostboot. </div>
<div dir="ltr" > </div>
<div dir="ltr" >Regards</div>
<div dir="ltr" >Sachin</div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Alistair Popple" <apopple@linux.ibm.com><br>To: Sachin Gupta24/India/IBM@IBMIN<br>Cc: "Dean Sanner" <dsanner@us.ibm.com>, Amit J Tendolkar/India/IBM@IBMIN, Raja Das1/India/IBM@IBMIN, hanetzer@startmail.com, openpower-firmware@lists.ozlabs.org, alistair@ozlabs.au.ibm.com<br>Subject: Re: A few questions about early hostboot<br>Date: Tue, Sep 10, 2019 12:10 PM<br>
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >On Tuesday, 10 September 2019 4:20:26 PM AEST Sachin Gupta24 wrote:<br>> Yeah. This was done using remote gdb support in pdbg. We did this using fsp<br>variant of sbe chipops. SBE chipop code for this went in pdbg repo <https://<br>github.rtp.raleigh.ibm.com/shakeebbk-in/pdbg-sbe/commits/master>. It is<br>internal repo as at that time pdbg was not part of openbmc. If you want to<br>access code, Alistair should be able to help in that.<br><br>Some of the SBE Chipop code should be upstream now. However it's still a work<br>in progress as we don't yet have full support for register access, etc. That<br>said you also shouldn't *need* to use the chip-ops to do this - the<br>implementation we have in pdbg should work and once the chip-op support is<br>available things will switch to that transparently.<br><br>> Hi Marty,<br>><br>> > I have a few additional questions about early hostboot on the power9<br>> > platform.<br>> ><br>> > I know pdbg has a gdbserver which currently only works on p8 and linux<br>> > kernel (though I may be misinterpreting the latter half). I assume the<br>> > lack of power9 support is just some missing code for now, but I wonder<br>> > about only supporting the linux kernel. Is there some deep-seated reason<br>> > one could not use gbdserver on hostboot itself? It could be very useful<br>> > for early debugging.<br><br>It should support P9 as well, although it's fair to say it doesn't get a whole<br>lot of testing (at least as far as I know).<br> <br>> Stewart is correct -- there is just a different way of accessing the memory<br>> (getmempba versus getmemproc). I know that the IBM's SBE team had a<br>> prototype of gdbg working against hostboot a while back. I've copied<br>> them on this email to see if it is still viable (there were some issues<br>> with the virtual pages for the extended image, but if you are only<br>> using it for early debug -- might not be an issue).<br><br>There is nothing that ties pdbg specifically to debugging the kernel (for<br>example it can equally be used to debug skiboot as well). For Hostboot there<br>are a couple of things needed though:<br><br>1. As Stewart/Dean said - an implementation of getmempba and the option to use<br>it instead of getmemproc<br><br>2. Page table walking code to convert virtual to physical addresses based on<br>CPU context. This problem exists equally for Linux debugging, except that for<br>the kernel we can just mask the top two bits (0xC....) to get the real<br>address. Obviously this doesn't work so well for userspace although there may<br>be some similar hack we could apply for Hostboot debugging.<br><br>- Alistair<br><br>> ><br>> > Power9 processors are able to operate in both BE and LE mode, and I am<br>> > having a bit of issue following this idea. Is there some register one<br>> > sets to switch mode I'm missing, or does the processor just 'know' that<br>> > 0xdeadbeef and 0xefbeadde are the same? Forgive me if this is a bad<br>> > example but hopefully it gets my point across. In addition, is there any<br>> > reason that hostboot couldn't be ran in either big or little endian<br>> > (after endian specific code is fixed, obviously)?<br>><br>> 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://github.com/open-power/hostboot/blob/master/src/" target="_blank" >https://github.com/open-power/hostboot/blob/master/src/</a><br>kernel/start.S<br>> (note that this part would need to be BE, all code after _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>> Or you can write the MSR in the SBE code where it manipulates<br>> the starting threads architected state:<br>> <a href="https://github.com/open-power/sbe/blob/master/src/import/chips/p9/" target="_blank" >https://github.com/open-power/sbe/blob/master/src/import/chips/p9/</a><br>procedures/hwp/nest/p9_sbe_load_bootloader.C<br>><br>><br>> Dean Sanner<br>> dsanner@us.ibm.com<br>> <br>><br>> </font><br><br><br><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>