[OpenPower-Firmware] SBE questions

[Marty E. Plummer]

On Thu, Jul 25, 2019 at 01:27:57PM -0500, Dean Sanner wrote:
> Hi Marty,
> 
> > Very cool tricks, thanks. One(?) more question: I assume that
> > Kernel Address     : 0xfffe8998
> > is where jump_to_kernel executes; I can't quite locate this entry point
> > in the disassembly (obviously this address exists but it doesn't appear
> > to be an entry point/function start). I'm interested in this bit as it
> 
> The OTPROM (burnt into the chip, can't change -- src/boot/otprom_init.S)
Yeah, even if its not modifiable its good to have the source. I recall
reading at some point that an end user can read back this burned image
to verify it, do you happen to know the technique offhand?
> will read the start of the XIP image, check the magic and jump to the
> address listed in next 8 bytes (here it is 0xFF800244):
> 00000000  58 49 50 20 53 45 50 4d  00 00 00 00 ff 80 02 44  |XIP
> SEPM.......D|
> 
Yeah, I figured out that far. If I do end up making an entire rewrite/etc
of the current sbe code I figure that's as far as I have to implement to
get the sbe to execute my code, the 'XIP SEPM' header + the entry point
address. After that I'd be relatively free to do whatever I want.
> This lines up with the L1 loader:
> > L1 Loader Address  : 0xff800244
> >    .loader_text     4       0    0x00000200   0x0000039b   0x0000019c (412)
> 
See, I'm wondering how the 0xff800244 mapps to the addresses next to
.loader_text and so on. I would have never drawn a connection between
the __pk_boot address and the .base section because there doesn't appear
to be any mapping between the two.
> 
> ==========
> The L1 loader (src/boot/loader_l1.S) will load the PIBMEM (SBE RAM) repairs
> and then copies the L2 Loader from seeprom into PIBMEM.  Note that this
> runs without a stack.   The load address is hardcoded:
Hardcoded in modifiable sbe firmware and not hardware, right?
> 
>  _liw     %r3, SBE_LOADER_BASE_SECTION   # Source on SEEPROM: 0xF80000B8
>  _liw     %r4, SBE_LOADER_BASE_ORIGIN    # dest in PIBMEM
> ///  Each section table entry is 12 bytes(SIZE_OF_SBE_XIP_SECTION) size,
> //   Base Loader is 10 th (P9_XIP_SECTION_BASELOADER) section
> #define SBE_LOADER_BASE_SECTION  SBE_SEEPROM_BASE_ORIGIN +
> SBE_XIP_TOC_OFFSET \
>                                   + 120
> #define SBE_LOADER_BASE_ORIGIN 0xFFFFE400
> > L2 Loader Address  : 0xffffe400
> >    .baseloader      8       0    0x0001f820   0x0001fb2f   0x00000310 (784)
> 000000b0  00 01 03 b3 04 00 00 00  00 01 f8 20 00 00 03 10 |........... ....|
> 
> 
> ===========
> The L2 loader (src/boot/loader_l2_setup.S, src/boot/loader_l2.c) then loads
> the SBE kernel/payload proper while running in PIBMEM, where it can have
> a stack.
> 
> loadSection(&(hdr->iv_section[P9_XIP_SECTION_SBE_BASE]), pibMemAddr);
>     // Set the IVPR register. This is required so that interrupt vector
> table
>     // points to pk interfaces.
>     uint64_t data = (uint64_t)(SBE_BASE_ORIGIN) << 32;
>     PPE_STVD(g_ivprLoc, data);
>     // Jump to pk boot function
>     uint32_t addr = hdr->iv_kernelAddr;
>     JUMP_TO_ADDR(addr);
> 
> 000000a0  00 00 00 00 00 00 00 00  08 00 00 00 00 01 fb 30 |...............0|
> 000000b0  00 01 03 b3 04 00 00 00  00 01 f8 20 00 00 03 10 |........... ....|
> >    .base            4       0    0x0001fb30   0x0002fee2   0x000103b3
> (66483)
> The hdr is the XIP TOC header so the jump point is here:
> > Kernel Address     : 0xfffe8998
> which can be found in output/build/sbe-<commit
> number>/images/sbe_seeprom_DD2.dis
> as fffe8998 <__pk_boot>:
> 
Ok, cool. strangely enough my dumped seeprom has a different address, I
suppose that is due to being the talos firmware rather upstream, but the
entry point is __pk_boot which is deep under the imports dir.
> this is added to the sbe.bin xip file with:
> output/build/sbe-<commit>/src/build/Makefile:   $(P9_XIP_TOOL) $(IMG_DIR)/$
> (IMAGE_NAME).bin \
>         set kernelAddr 0x`nm $(IMG_DIR)/$(IMAGE_NAME).out | grep __pk_boot
> | cut -f 1 -d " "`
> 
> 
> > (if I understand correctly) is the actual sbe code running (the stuff
> > prior is just setting up stuff for it to run) and contains the meat of
> > the code which I'd have to understand for a coreboot port.
> 
> I think we might be talking past each other :) The above information goes
> into details on how the SBE operates, but from what I understand you want
> to
> put the coreboot file system on the PNOR?  The SBE proper _never_ accesses
Correct. Though I do intend on the sbe firmware to be placed into the
cbfs and written to the seeprom in a manner similar to current hostboot(?)
> the
> PNOR directly.  The first thing that touches the PNOR is the Hostboot boot
> loader
> (which is loaded by the SBE into the P9 cache and is executed by the P9
> core itself).
Oh, I was under the impression that hbbl was run on the sbe using that
modified power core. This is still BE code, correct? Another question
then, could you point out where the sbe firmware->hbbl handoff happens,
then? I'm mostly interested in the ppe42->p9 execution switch happens.
> 
> Unless you want to run coreboot _from_ the SBE (limited environment and I
Not coreboot proper per se. The primary thing wrt modifying the sbe
itself is (imo) c++ in this low-level firmware is really difficult to
track as compared to plain c/assembly.
> don't see
> the value?)  I would recommend focusing on modifications to the Hostboot
> bootloader.
Yeah, with this information I think I can hook in at the hbbl stage so I
don't have to rewrite everything from the ground up.
> The Hostboot bootloader (HBBL) is part of the SBE SEEPROM customized in by
> Hostboot --
> but it doesn't execute on the SBE.  It is the first thing the P9 core
> executes.
> That seems like the logical hook point to me?
> 
> Dean Sanner
> dsanner at us.ibm.com
>