[OpenPower-Firmware] Further information about hostboot

Daniel M Crowell dcrowell at us.ibm.com
Fri Aug 23 00:10:32 AEST 2019


> src/bootloader is what produces the hostboot bootloader image
Correct, plus it pulls in a couple shared files from elsewhere, e.g. a
couple kernel files and some pnor utilities.

> src/kernel is what produces the HBB partition
The kernel is a piece of HBB, but not all of it.  Basically HBB is all the
code required to get access to the PNOR and be able to page in the rest of
the code.  Everything in HBB is non-pageable, everything in HBI is
pageable.

> kernel_dispatch_task() which is marked as having 'no return',
Correct, that call ends by jumping to a real worker task.  After that point
the scheduler handles moving things around.

> how one reads/writes the scom on a power9 system?
The complication is due to the fact that there are many ways to do a scom,
depending on where you are executing from and the current state of the
system, and also which target you are trying to access.  The native method
on the processor is called xscom.  This is simply a memory-mapped space
(BAR is written by SBE) that you do loads/stores to and then look at the
HMER for status.  See src/usr/xscom/xscom.C :: xScomDoOp() for the bottom
of the stack.  However, a core can only issue xscoms to processors that are
currently part of the SMP fabric since the request flows around the power
bus.  That means it cannot access anything on the second processor until
after istep10.  Before that point, you need to use some kind of sideband
interface, which is where FSI shows up.  If you disable security, you can
use the fsi2pib engine in the CFAM logic to do scoms (see
src/usr/fsiscom/).  Wither security enabled (which is the default), that
path is disabled so you have to go through the SBE code to do the scoms.
There is a FIFO engine on the FSI bus where we send commands over to the
SBE code.  All of that logic is in src/usr/sbeio/.  Then you can add
another layer of confusion when you start accessing the non-processor chips
on the system.  The code in src/usr/scom/ basically routes a generic 'scom'
request to the appropriate low-level transport layer.

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com



From:	"Marty E. Plummer" <hanetzer at startmail.com>
To:	openpower-firmware at lists.ozlabs.org
Date:	08/21/2019 06:25 PM
Subject:	[EXTERNAL] [OpenPower-Firmware] Further information about
            hostboot
Sent by:	"OpenPower-Firmware" <openpower-firmware-bounces
            +dcrowell=us.ibm.com at lists.ozlabs.org>



Hello.

After making some progress coreboot-side on being able to enter their
code path using 'stock' seeprom images (I've hopefully put together a
way to wrap coreboot.rom in ffs style headers to make hostboot bootloader
load our bootblock) I was hoping for some more information on various
things.

So, if I understand correctly, the directory src/bootloader is what
produces the hostboot bootloader image on the seeprom, and src/kernel
is what produces the HBB partition on the pnor, right? (I've marked the
bootblock in coreboot as HBB to make hbbl load it).

In addition, I'm not sure how src/kernel/kernel.C:106's main function
carries on as the last instruction is kernel_dispatch_task() which is
marked as having 'no return', am I misunderstanding something?

Also, could someone elaborate how one reads/writes the scom on a power9
system? I'm having trouble following the c++ code involved due to all
the indirection. A simple assembly or c example would be quite helpful.

Regards,
Marty
_______________________________________________
OpenPower-Firmware mailing list
OpenPower-Firmware at lists.ozlabs.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_listinfo_openpower-2Dfirmware&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=mCj3CQvqek9g0fdziO-GEHyU1m9T3SAh0ZPd5s_AGpo&m=xSaQFcrdTnipy7kX4DAsywXOhCQCfQ0buWB51So_6qo&s=T9z-jG8diKlH_ji0pJJgOr83MDYNdPWcrmsJEeI02Cg&e=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20190822/7adc7edd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20190822/7adc7edd/attachment.gif>


More information about the OpenPower-Firmware mailing list