| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Presence detection for opencapi adapters was broken for ZZ planars v3
and below. All ZZ systems currently used in the lab have had their
planar upgraded, so we can now remove the override we had to force
presence and activate presence detection. Which should improve boot
time.
Considering the state of opal support on ZZ, this is really only for
lab usage on BML. The opencapi enablement team has okay'd the
change. In the unlikely case somebody tries opencapi on an old ZZ, the
presence detection through i2c will show that no adapter is present
and skiboot won't try to access or train the link.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Users see these when loading an OS from Petitboot:
[ 119.486794100,5] OPAL: Switch to big-endian OS
[ 120.022302604,5] OPAL: Switch to little-endian OS
Which is expected and doesn't provide any information the user can act
on. Switch them to PR_INFO so they still appear in the log, but not on
the serial console.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Add a --skip=N option to pflash to skip N number of bytes when reading.
This would allow users to print the VERSION partition without the STB
header by specifying the --skip=4096 argument, and it's a more generic
solution rather than making pflash depend on secure/trusted boot code.
Signed-off-by: Adriana Kobylak <anoo@linux.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
[stewart: fix up pflash test]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Commit cb835dbdf875 ('external/mambo: conditionally source qtrace script')
added qtrace_utils.tcl sourcing in skiboot.tcl without a check to see
whether it exists in the current directory. This broke running mambo from
another directory using skiboot.tcl. Patch adds a check.
Fixes: cb835dbdf875 ('external/mambo: conditionally source qtrace script')
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Implements sending a list of installed PCI devices through IPMI protocol.
Each PCI device description is sent as a standalone IPMI message.
A list of devices can be gathered from separate messages using the
session identifier. The session Id is an incremental counter that is
updated at the start of synchronization session.
Signed-off-by: Artem Senichev <a.senichev@yadro.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Artem Senichev reported[1] his P8 platform was failing to boot from
a43e9a66aae9 ("astbmc: Fail SFC init if SIO is unavailable") with the
following error:
[ 110.097168975,3] PLAT: Failed to open PNOR flash controller
I reproduced this behaviour on a Palmetto; we need to ensure the state
of the no-response error bit is clear before proceding with the presence
test.
The fix appears to resolve the failure to open the PNOR flash controller
on Palmetto and doesn't change the expected behaviour on Witherspoon.
[1] https://github.com/open-power/skiboot/issues/197
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Tested-by: Artem Senichev <a.senichev@yadro.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This was caught with unmapped memory dereference page faults.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
These were caught with unmapped memory dereference page faults.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Commit accomplishes following:
- Implementation of new self restore region memory layout
- Restore of SPRs pertaining to SMF
- Self save of SPRs
- Backward compatibility with old self restore layout
Key_Cronus_Test=PM_REGRESS
Change-Id: I11359e392102d32896251225907eb95a43ba6f78
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/66212
Reviewed-by: RANGANATHPRASAD G. BRAHMASAMUDRA <prasadbgr@in.ibm.com>
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: HWSV CI <hwsv-ci+hostboot@us.ibm.com>
Tested-by: Cronus HW CI <cronushw-ci+hostboot@us.ibm.com>
Tested-by: Hostboot CI <hostboot-ci+hostboot@us.ibm.com>
Reviewed-by: Gregory S. Still <stillgs@us.ibm.com>
Reviewed-by: Jennifer A. Stofer <stofer@us.ibm.com>
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/66216
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Commit addresses a situation where STOP API is new and HB is
old. It detects the siutation and retains legacy behavior.
This situation can arise if PHYP tries to use SCOM restore
changes of STOP API with older fipsdriver or OPAL does the
same on older HB binaries.
Key_Cronus_Test=PM_REGRESS
Change-Id: Iaaa866169904a47e10c79ae4894d2eedccfafe53
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/62610
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: Hostboot CI <hostboot-ci+hostboot@us.ibm.com>
Tested-by: Cronus HW CI <cronushw-ci+hostboot@us.ibm.com>
Reviewed-by: RANGANATHPRASAD G. BRAHMASAMUDRA <prasadbgr@in.ibm.com>
Reviewed-by: AMIT J. TENDOLKAR <amit.tendolkar@in.ibm.com>
Reviewed-by: Gregory S. Still <stillgs@us.ibm.com>
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/62614
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com>
[build fixes for OPAL : Akshay Adiga]
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Qemu has evolved since this text was written. We can now run skiboot on
upstream Qemu.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Do not add unknown I2C devices to device tree.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We have a hack in the I2C device parser to fix up entries generated by
hostboot for the DIMM SPD devices. For some reason they get reported as
128Kbit EEPROMs which is bad since those have a different I2C interface
to an actual SPD device.
Oddly enough, the FSP also gets this wrong in a slightly different way.
In the FSP case they are reported as a at24c04 (4Kbit) EEPROM, which
also has a different I2C interface.
To fix both these problems for any eeprom we find on that bus to have
the compatible string of "spd".
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Many of the devices that we get information about through HDAT are for
use by firmware rather than the host operating system. This patch adds
a boolean flag to hdat_i2c_info structure that indicates whether devices
with a given purpose should be reserved for use inside of OPAL (or some
other firmware component, such as the OCC).
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
When stop state 5 is enabled, reading the core_fir during an HMI can
result in a xscom read error with xscom_read() returning an
OPAL_XSCOM_PARTIAL_GOOD error code and core_fir value of all FFs. At
present this return error code is not handled in decode_core_fir()
hence the invalid core_fir value is sent to the kernel where it
interprets it as a FATAL hmi causing a system check-stop.
This can be prevented by forcing the core to wake-up using before
reading the core_fir. Hence this patch wraps the call to
read_core_fir() within calls to dctl_set_special_wakeup() and
dctl_clear_special_wakeup().
Suggested-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
Acked-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Reviewed-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Presently phb4_probe_stack() will always enable PHB MMIO0/1 windows
even if they doesn't exist in phy_map. Hence we do some minor shuffling
in the phb4_probe_stack() so that MMIO-0/1 Bars are only enabled if
there corresponding MMIO window exists in the phy_map. In case phy_map
for an mmio window is '0' we set the corresponding BAR register to
'0'.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently on a FSP based P9 system load_capp_code() expects CAPP ucode
lid header to have eye-catcher magic of 'CAPPPSLL'. However skiboot
currently supports CAPP ucode only lids that have a eye-catcher magic
of 'CAPPLIDH'. This prevents skiboot from loading the ucode with this
error message:
CAPP: ucode header invalid
We fix this issue by updating load_capp_ucode() to use the eye-catcher
value of 'CAPPLIDH' instead of 'CAPPPSLL'.
Cc: stable
Fixes: e50764d4f2b1("capi: Load capp microcode")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Update phb4_init_capp_regs() to allocates STQ Engines to CAPP/PEC2
based on link width instead of always assuming it to x8.
Also re-factor the function slightly to evaluate the link-width only
once and cache it so that it can also be used to allocate DMA read
engines.
Cc: stable
Fixes: 47c09cdfe7a3("phb4/capp: Calculate STQ/DMA read engines based on link-width for PEC")
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The Skiboot version can include a "skiboot-" prefix if built with
something like Buildroot. The property being compared against won't
include this so ignore it.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If SuperIO is unavailable then the driver cannot perform accesses on
which it currently depends. Test for SuperIO availability during
initialsation and bail out immediately if it is absent.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Segregate the BMC platform configuration into hardware and software
components. This allows population of platform default values for
hardware configuration that may no-longer be accessible by the host.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: fixup pci-quirk unit test]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Avoid the probabilistic approach and use a deterministic one instead.
The probe calls use a slow, synchronous method to capture the the state
of the target device, so it is used sparingly (only on first access).
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Introduce generic read and write probe functions that allow detection of
valid addresses by way of synchronous testing for the SYNC no-response
state. If the no-response state is detected the probe functions will
return an error to the caller, who can do with it what they wish.
In the process, rip out the naive mechanism for muting the equivalent
asynchronous error logging (regretfully introduced recently by yours
truly).
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If the IPMI command is not available, fall back to the mailbox
interface.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: fix up mbox test]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
ipmi-hiomap implements the PNOR access control protocol formerly known
as "the mbox protocol" but uses IPMI instead of the AST LPC mailbox as a
transport. As there is no-longer any mailbox involved in this alternate
implementation the old protocol name is quite misleading, and so it has
been renamed to "the hiomap protoocol" (Host I/O Mapping protocol). The
same commands and events are used though this client-side implementation
assumes v2 of the protocol is supported by the BMC.
The code is a heavily-reworked copy of the mbox-flash source and is
introduced this way to allow for the mbox implementation's eventual
removal.
mbox-flash should in theory be renamed to mbox-hiomap for consistency,
but as it is on life-support effective immediately we may as well just
remove it entirely when the time is right.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[stewart: prlog debug over prerror for mbox fallback, fix indent]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This ensures progress when we don't have interrupts available for IPMI.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Previously in flash_register() held flash_lock across ffs_init(), which
calls through the blocklevel layer to read the flash. This is unhelpful
with the IPMI HIOMAP protocol transport as LPC interrupts have not yet
been enabled and we are relying on polling to progress. The held lock
stalls the boot as we take the nopoll path in time_wait() while
completing ipmi_queue_msg_sync() in libflash/ipmi-flash.c
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Otherwise we can get reports of core/lock.c owning the lock, which is
not helpful when tracking down ownership issues.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
bust_locks is a big hammer that guarantees a mess if it's set while
all other threads are not stopped.
I propose removing this in the lock error paths. In debugging the
previous deadlock false positive, none of the error messages printed,
and the in-memory console was totally garbled due to lack of locking.
I think it's generally better for debugging and system integrity to
keep locks held when lock errors occur. Lock busting should be used
carefully, just to allow messages to be printed out or machine to be
restarted, probably when the whole system is single-threaded.
Skiboot is slowly working toward that being feasible with co-operative
debug APIs between firmware and host, but for the time being,
difficult lock crashes are better not to corrupt everything by
busting locks.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If a lock waiter exceeds the warning timeout, it prints a message
while still registered as requesting the lock. Printing the message
can take locks, so if one is held when the owner of the original
lock tries to print a message, it will get a false positive deadlock
detection, which brings down the system.
This can easily be hit when there is a lot of HMI activity from a
KVM guest, where the timebase was not returned to host timebase
before calling the HMI handler.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
On DD2.0 parts, PCIe ECC protection is not warranted in the response
data path. Thus, for these parts, we need to flag any ECC errors
detected from the adjacent AIB RX Data path so the part can be
replaced.
This patch configures the FIRs so that we escalate these AIB ECC
errors to a checkstop so the parts can be replaced.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently if we try to run a raw/stripped binary kernel (ie. without
the elf header) we crash with:
[ 0.008757768,5] INIT: Waiting for kernel...
[ 0.008762937,5] INIT: platform wait for kernel load failed
[ 0.008768171,5] INIT: Assuming kernel at 0x20000000
[ 0.008779241,3] INIT: ELF header not found. Assuming raw binary.
[ 0.017047348,5] INIT: Starting kernel at 0x0, fdt at 0x3044b230 14339 bytes
[ 0.017054251,0] FATAL: Kernel is zeros, can't execute!
[ 0.017059054,0] Assert fail: core/init.c:590:0
[ 0.017065371,0] Aborting!
This is because we haven't set kernel_entry correctly in this path.
This fixes it.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
When primary thread receives a CORE level HMI for timer facility errors
while secondaries are still in OPAL, thread 0 ends up in rendez-vous
waiting for secondaries to get into hmi handling. This is because OPAL
runs with MSR(EE=0) and hence HMIs are delayed on secondary threads until
they are given to Linux OS. Fix this by adding a check for secondary
state and force them in hmi handling by queuing job on secondary threads.
I have tested this by injecting HDEC parity error very early during Linux
kernel boot. Recovery works fine for non-TB errors. But if TB is bad at
this very eary stage we already doomed.
Without this patch we see:
[ 285.046347408,7] OPAL: Start CPU 0x0843 (PIR 0x0843) -> 0x000000000000a83c
[ 285.051160609,7] OPAL: Start CPU 0x0844 (PIR 0x0844) -> 0x000000000000a83c
[ 285.055359021,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 285.055361439,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:0: TFMR(2e12002870e14000) Timer Facility Error
[ 286.232183823,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc1)
[ 287.409002056,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc1)
[ 289.073820164,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc1)
[ 290.250638683,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc2)
[ 291.427456821,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc2)
[ 293.092274807,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc2)
[ 294.269092904,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 1 (sptr=0000ccc3)
[ 295.445910944,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 2 (sptr=0000ccc3)
[ 297.110728970,3] HMI: Rendez-vous stage 1 timeout, CPU 0x844 waiting for thread 3 (sptr=0000ccc3)
After this patch:
[ 259.401719351,7] OPAL: Start CPU 0x0841 (PIR 0x0841) -> 0x000000000000a83c
[ 259.406259572,7] OPAL: Start CPU 0x0842 (PIR 0x0842) -> 0x000000000000a83c
[ 259.410615534,7] OPAL: Start CPU 0x0843 (PIR 0x0843) -> 0x000000000000a83c
[ 259.415444519,7] OPAL: Start CPU 0x0844 (PIR 0x0844) -> 0x000000000000a83c
[ 259.419641401,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419644124,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:0: TFMR(2e12002870e04000) Timer Facility Error
[ 259.419650678,7] HMI: Sending hmi job to thread 1
[ 259.419652744,7] HMI: Sending hmi job to thread 2
[ 259.419653051,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419654725,7] HMI: Sending hmi job to thread 3
[ 259.419654916,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419658025,7] HMI: Received HMI interrupt: HMER = 0x0840000000000000
[ 259.419658406,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:2: TFMR(2e12002870e04000) Timer Facility Error
[ 259.419663095,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:3: TFMR(2e12002870e04000) Timer Facility Error
[ 259.419655234,7] HMI: [Loc: U78D3.ND1.WZS004A-P1-C48]: P:8 C:17 T:1: TFMR(2e12002870e04000) Timer Facility Error
[ 259.425109779,7] OPAL: Start CPU 0x0845 (PIR 0x0845) -> 0x000000000000a83c
[ 259.429870681,7] OPAL: Start CPU 0x0846 (PIR 0x0846) -> 0x000000000000a83c
[ 259.434549250,7] OPAL: Start CPU 0x0847 (PIR 0x0847) -> 0x000000000000a83c
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Rename and set it as a pre_pci_fixup platform function. The indirect
call doesn't make a whole of of sense IMO.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Vague documentation is about as annoying as no documentation.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Commit eb146fac9685 ("core/i2c: Move the timeout field into
i2c_request") simplified a bit how a request timeout is
handled. However there's now some confusion between milliseconds and
timebase increments when defining or using the timeout values, which
breaks i2c requests made for opencapi, and probably others too.
This patch declares all the timeout in milliseconds and just converts
to timebase at the end of the chain, as needed.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
There are patches that will go into dtc to fix the issues we hit, but
for the moment let's just build and use a slightly older version.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Below message is confusing. Lets make it clear.
FSP sends "R/R complete notification" whenever there is a dump. We use `flag`
to identify whether its its R/R completion -OR- just new dump notification.
[ 483.406351956,6] FSP: SP says Reset/Reload complete
[ 483.406354278,5] DUMP: FipS dump available. ID = 0x1a00001f [size: 6367640 bytes]
[ 483.406355968,7] A Reset/Reload was NOT done
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
PMEM_VOLATILE and PMEM_DISK can't be used together and are basically
copies of the same code.
This merges the two and allows them used together. Same API is kept.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Couple of places in 'phb4.c' where we may want to dump the PEC's error
registers. Hence we introduce a phb4_dump_pec_err_regs() that dumps
all the PEC error registers and also update phb4->nfir_cache &
phb4->pfir_cache for later use.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
During fast-reboot new PEC errors can be latched even after ETU-Reset
is asserted. This will result in values of variables nfir_cache and
pfir_cache to be out of sync.
During step-2 of CRESET nfir_cache and pfir_cache values are used to
bring the PHB out of reset state. However if these variables are out
as noted above of date the nfir/pfir registers are never reset
completely and ETU still remains frozen.
Hence this patch updates step-2 of phb4_creset to re-read the values of
nfir/pfir registers to check if any new errors were reported after
ETU-reset was asserted, report these new errors and reset the
nfir/pfir registers. This should bring the ETU out of reset
successfully.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-By: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Allow specifying a file on the command line to read OCC SRAM data into.
If no file is specified then we print it to stdout as text. This is a
bit inconsistent, but it retains compatibility with the existing tool.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
