Age | Commit message (Collapse) | Author | Files | Lines |
|
Below are the in-memory console log messages observed with error level(PR_ERROR)
[54460318,3] HBRT: Mem region 'ibm,homer-image' not found !
[54465404,3] HBRT: Mem region 'ibm,homer-image' not found !
[54470372,3] HBRT: Mem region 'ibm,homer-image' not found !
[54475369,3] HBRT: Mem region 'ibm,homer-image' not found !
[11540917382,3] NVRAM: Layout appears sane
[11694529822,3] OPAL: Trying a CPU re-init with flags: 0x2
[61291003267,3] OPAL: Trying a CPU re-init with flags: 0x1
[61394005956,3] OPAL: Trying a CPU re-init with flags: 0x2
Lowering the log level of mem region not found messages to PR_WARNING and remaining messages to PR_INFO level
[54811683,4] HBRT: Mem region 'ibm,homer-image' not found !
[10923382751,6] NVRAM: Layout appears sane
[55533988976,6] OPAL: Trying a CPU re-init with flags: 0x1
Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Modify the OCC reset order such that master OCC is reset after the
slave OCCs are reset. In Tuleta/Alpine systems 'proc0' will always be
the master OCC, which has to be stopped last when FSP sends OCC_RESET
command to Opal.
This fixes BZ 119718, SW289036
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
See https://github.com/lucasdemarchi/codespel
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This means VPD LID is already loaded before we start preloading
kernel and initramfs LIDs, thus ensuring VPD doesn't have to wait
for them to finish being read from FSP.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Call abort if OCC LID preload fails.
Related discussion:
https://lists.ozlabs.org/pipermail/skiboot/2015-March/000636.html
Suggested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This moves away from using fsp_sync_msg in fsp_fetch_data and instead
using the platform hooks for start_preload_resource() to actually queue
up a load and having the plumbing for checking if a resource is loaded yet.
This gets rid of the "pollers called with locks held" warning we got
heaps of previously. You can now boot some FSP systems without getting
this warning at all.
This also sets the stage for starting load of LIDs much earlier to when
they're needed, improving boot time.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There is no guarantee that a hostservices lid load request will arrive
after we have cached the required lids. For such cases, queue the
request and service them after caching.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Fix the loop iterator to not miss a lid
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
... to prevent any potential poller recursions during lid load.
With this change:
...
[10810950484,5] CUPD: P side ML Keyword = FW830.00
[10832756491,6] HBRT: 1 lids to load
[10832762732,7] FSP: Fetch data id: 05 sid: 81e00430 to 0x306cf500(0x100000
bytes)
[10832766825,7] FSP: 0x00100000 bytes balign=306cf000 boff=500 bsize=101000
[10857829395,5] CUPD: Marker LID id : size : status = 0x80a08001 : 0x5d0 : 0x0
[10966464432,7] FSP: -> rc=0x00 off: 00000000 twritten: 0007fb80
[10966468418,7] HBRT: LID 0x81e00430 successfully loaded, len=0x31b83db8
...
[19485180658,7] HBRT: stopOCCs() rc = 0
[19582727570,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x10
[19582732660,7] HBRT: OCC Load requested
[19582734678,7] HBRT: Calling loadOCC() homer 0000000401400000, occ_common_area
0000000400800000, chip 0000
[19582803643,6] HBRT: Lid load request for 0x81e00430
[19582806532,7] HBRT: Serviced from cache, len=0x7fb80
[19582996931,7] HBRT: -> rc = 0
[19582999113,7] HBRT: Calling loadOCC() homer 0000000401c00000, occ_common_area
0000000400800000, chip 0001
[19583097594,6] HBRT: Lid load request for 0x81e00430
[19583100343,7] HBRT: Serviced from cache, len=0x7fb80
[19583274638,7] HBRT: -> rc = 0
[19583277114,6] HBRT: OCC Start requested
V2:
Address Vasant's comments (bz reference and OPAL_NO_MEM)
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Use the _nopoll variant of nanosleep from hostservices, to avoid potential
poller recursion.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
printing timebase is redundant, prlog does that for us.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
|
|
OPAL is expected to leave OCC stopped after receiving reset OCC
message from FSP. FSP will send this either at boot before
a load/start, or during runtime before load/start. If there
is no subsequent load/start command, the OCC can be left stopped.
After few attempts (runtime reset), FSP can just send reset and
expect OPAL to leave OCC in stopped state.
Call HBRT to stop OCC on FSP reset OCC command and acknowledge.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
A line was way too long...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Many things can just be PR_DEBUG, a few PR_INFO
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
(PR_CRIT and PR_ERR respectively)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|