summaryrefslogtreecommitdiffstats
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
...
* Add PVR_TYPE_P9PReza Arbab2019-02-102-1/+10
| | | | | | | Enable a new PVR to get us running on another p9 variant. Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* cpufeatures: Always advertise POWER8NVL as DD2Alexey Kardashevskiy2019-02-101-4/+5
| | | | | | | | | | | | | | | | Despite the major version of PVR being 1 (0x004c0100) for POWER8NVL, these chips are functionally equalent to P8/P8E DD2 levels. This advertises POWER8NVL as DD2. As the result, skiboot adds ibm,powerpc-cpu-features/processor-control-facility for such CPUs and the linux kernel can use hypervisor doorbell messages to wake secondary threads; otherwise "KVM: CPU %d seems to be stuck" would appear because of missing LPCR_PECEDH. Fixes: 7f4c8e8ce0b "dt: add /cpus/ibm, powerpc-cpu-features device tree bindings" Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/opal: Print PIR value in exit pathVasant Hegde2019-02-041-2/+2
| | | | | | | | Useful for debugging. CC: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/ipmi: Improve error messageVasant Hegde2019-02-041-1/+2
| | | | | | | Useful for debugging. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/lock: Stop drop_my_locks() from always causing abortReza Arbab2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The loop in drop_my_locks() looks like this: while((l = list_pop(&this_cpu()->locks_held, struct lock, list)) != NULL) { if (warn) prlog(PR_ERR, " %s\n", l->owner); unlock(l); } Both list_pop() and unlock() call list_del(). This means that on the last iteration of the loop, the list will be empty when we get to unlock_check(), causing this: LOCK ERROR: Releasing lock we don't hold depth @0x30493d20 (state: 0x0000000000000001) [13836.000173140,0] Aborting! CPU 0000 Backtrace: S: 0000000031c03930 R: 000000003001d840 ._abort+0x60 S: 0000000031c039c0 R: 000000003001a0c4 .lock_error+0x64 S: 0000000031c03a50 R: 0000000030019c70 .unlock+0x54 S: 0000000031c03af0 R: 000000003001a040 .drop_my_locks+0xf4 To fix this, change list_pop() to list_top(). Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Remove POWER9N DD1 supportNicholas Piggin2019-01-253-21/+6
| | | | | | | | This is not a shipping product and is no longer supported by Linux or other firmware components. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/pci: Introduce a new pci_slot_op named completed_sm_run()Vaibhav Jain2019-01-161-1/+5
| | | | | | | | | | | | | | | | | | | | | | | At times we need to perform some cleanup activities when the Opal PCI state machine that perform creset/freset/hreset (driven by pci_slot_ops->run_sm which) of a slot completes. One example can be to mark CAPP attached to a PHB, as deactivated when creset/freset of a CAPI card slot is completed. However the calls to pci_slot_ops->run_sm() is scattered through out the code and patching each call site to check for the return value and perform custom cleanup tacks is difficult. Hence this patch introduces a new pci_slot_ops named completed_sm_run() which should be called when pci_slot_ops->run_sm() determines that the reset state machine is complete. This provides a more centralized way to handle slot related cleanup activities. Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal: Update opal_del_host_sync_notifier() to accept 'void *data'Vaibhav Jain2019-01-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | Current implementation of opal_del_host_sync_notifier() will only delete the first entry of the 'notify' callback found from opal_syncers list irrespective of the 'data' of list-node. This is problematic when multiple notifiers with same callback function but different 'data' are registered. In this case when the cleanup code will call opal_del_host_sync_notifier() it cannot be sure if correct opal_syncer is removed. Hence this patch updates the function to accept a new argument named 'void *data' which is then used to iterates over the opal_syncers list and only remove the first node node having the matching value for 'notify' callback as 'data'. Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* i2c: Fix i2c request hang during opal init if timers are not checkedFrederic Barrat2018-12-111-0/+16
| | | | | | | | | | | | | | | | | | If an i2c request cannot go through the first time, because the bus is found in error and need a reset or it's locked by the OCC for example, the underlying i2c implementation is using timers to manage the request. However during opal init, opal pollers may not be called, it depends in the context in which the i2c request is made. If the pollers are not called, the timers are not checked and we can end up with an i2c request which will not move foward and skiboot hangs. Fix it by explicitly checking the timers if we are waiting for an i2c request to complete and it seems to be taking a while. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* vpd: Force static analysis to not think about NULL term stringsStewart Smith2018-12-101-1/+1
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal_sync_host_reboot: clarify when we return OPAL_BUSY_EVENTStewart Smith2018-12-101-6/+4
| | | | | | | Basically to shut up static analysis of using a boolean in a non-boolean context (bitwise). Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* opal_trace_entry: Move ifdef around to shut up static analysisStewart Smith2018-12-101-2/+4
| | | | | | | Again, this makes things look slightly different so I don't keep seeing the static analysis warning. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* mem_region.c: Move ifdef for MEM_POISON to shut up static analysisStewart Smith2018-12-101-2/+6
| | | | | | | | | The static analysis tool is arguably wrong and should go away. But... I'm sick of keeping coming back to it and reviewing the false positives enough to make a slight change to where ifdefs are. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Change ifdef around dump_fdt() to shut up static analysisStewart Smith2018-12-101-2/+2
| | | | | | | | | | | | This is a dumb warning from a certain static analysis tool that a function has no effect when the ifdef that would make it have an effect isn't defined and we replace it with a no-op impl. Putting the #ifdef around the call just so I don't have to discount this damn static analysis false positive every time I go and look at the results. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/cpu.c: avoid container_of(NULL) in next_cpu()Stewart Smith2018-12-101-5/+5
| | | | | | | | | | | | A certain finicky static analysis tool did point out that we were operating on a value that could be null (and since first_cpu() calls next_cpu(NULL) to get the first one, it also gets to be complained about as next_cpu() could act on that NULL pointer). So, rework things to shut the static analysis tool up, when in fact this was never a problem. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Don't warn on "long" OPAL_RESYNC_TIMEBASE callsStewart Smith2018-11-281-1/+1
| | | | | | | | | On P8 this is called when we exit fastsleep, and we shouldn't measure the "time" spent in the call for what (in retrospect) is an obvious reason. Fixes: 50ea35c2d07874755c03e6ae2bdf7a33ad2c768a Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Warn on long OPAL callsStewart Smith2018-11-211-0/+9
| | | | | | | | Measure entry/exit time for OPAL calls and warn appropriately if the calls take too long (>100ms gets us a DEBUG log, > 1000ms gets us a warning). Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* ipmi: Reduce ipmi_queue_msg_sync() polling loop time to 10msStewart Smith2018-11-191-1/+1
| | | | | | | | | | | | | | On a plain boot, this reduces the time spent in OPAL by ~170ms on p9dsu. This is due to hiomap (currently) using synchronous IPMI messages. It will also *significantly* reduce latency on runtime flash operations, as we'll spend typically 10-20ms in OPAL rather than 100-200ms. It's not an ideal solution to that, but it's a quick and obvious win for jitter. Cc: stable Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/flash: Log return code when ffs_init() failsAndrew Jeffery2018-11-011-1/+1
| | | | | | | | Knowing the return code is at least better than not knowing the return code. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Run pollers in time_wait() when not bootingStewart Smith2018-10-311-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This only bit us hard with hiomap in one scenario. Our OPAL API has been OPAL_POLL_EVENTS may be needed to make forward progress on ongoing operations, and the internal to skiboot API has been that time_wait() of a suitable time will run pollers (on at least one CPU) to help ensure forward progress can be made. In a perfect world, interrupts are used but they may a) be disabled, or b) the thing we're doing can't use interrupts because computers are generally terrible. Back in 3db397ea5892a (circa 2015), we changed skiboot so that we'd run pollers only on the boot CPU, and not if we held any locks. This was to reduce the chance of programming code that could deadlock, as well as to ensure that we didn't just thrash all the cachelines for running pollers all over a large system during boot, or hard spin on the same locks on all secondary CPUs. The problem arises if the OS we're booting makes an OPAL call early on, with interrupts disabled, that requires a poller to run to make forward progress. An example of this would be OPAL_WRITE_NVRAM early in Linux boot (where Linux sets up the partitions it wants) - something that occurs iff we've had to reformat NVRAM this boot (i.e. first boot or corrupted NVRAM). The hiomap implementation should arguably *not* rely on synchronous IPMI messages, but this is a future improvement (as was for mbox before it). The mbox-flash code solved this problem by spinning on check_timers(). More generically though, the approach of running the pollers when no longer booting means we behave more in line with what the API is meant to be, rather than have this odd case of "time_wait() for a condition that could also be tripped by an interrupt works fine unless the OS is up and running but hasn't set interrupts up yet". Fixes: 529bdca0bc546a7ae3ecbd2c3134b7260072d8b0 Fixes: 3db397ea5892a8b348cf412739996731884561b3 Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Revert "TEMPORARY HACK: Disable verifying VERSION"Stewart Smith2018-10-251-6/+1
| | | | | | This reverts commit f835684365273c5ff1b7c700ddc0f9c1a859363f. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Quieten 'warnings' now that SIO is disabledStewart Smith2018-10-251-1/+2
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* npu2-opencapi: Enable presence detection on ZZFrederic Barrat2018-10-251-6/+0
| | | | | | | | | | | | | | | | | | 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>
* cpu: Quieten OS endian switch messagesJoel Stanley2018-10-251-2/+2
| | | | | | | | | | | | | | 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>
* core/device: NULL pointer dereference fixNicholas Piggin2018-10-231-1/+4
| | | | | | | 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>
* core/flash: NULL pointer dereference fixesNicholas Piggin2018-10-232-7/+14
| | | | | | | 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>
* opal/hmi: Wakeup the cpu before reading core_firVaibhav Jain2018-10-161-6/+15
| | | | | | | | | | | | | | | | | | | | | 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>
* core/flash: Ignore prefix when comparing versions.Samuel Mendoza-Jonas2018-10-161-2/+16
| | | | | | | | | 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>
* core/device: Test dt_new_check()Stewart Smith2018-10-161-2/+4
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/device: increase test coverage for dt_new_addr and dt_new_2addrStewart Smith2018-10-161-0/+2
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/device: add test for dt_new() a duplicate nodeStewart Smith2018-10-161-0/+1
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/device: Add test for duplicate nodes with dt_attach_root()Stewart Smith2018-10-161-1/+8
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* gcov: Fix building with GCC8Stewart Smith2018-10-162-7/+8
| | | | Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* platform: Restructure bmc_platform typeAndrew Jeffery2018-10-112-4/+25
| | | | | | | | | | 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>
* core/flash: Unlock around blocklevel calls in NVRAM accessorsAndrew Jeffery2018-10-101-0/+11
| | | | | | | 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>
* core/flash: Only lock around flashes update in flash_register()Andrew Jeffery2018-10-101-6/+2
| | | | | | | | | | | | 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>
* core/lock: Use try_lock_caller() in lock_caller() to capture ownerAndrew Jeffery2018-10-101-1/+1
| | | | | | | | 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>
* core/lock: don't set bust_locks on lock errorNicholas Piggin2018-10-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | 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>
* core/lock: fix timeout warning causing a deadlock false positiveNicholas Piggin2018-10-101-6/+15
| | | | | | | | | | | | | | | 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>
* init: Fix starting stripped kernelMichael Neuling2018-09-271-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
* opal/hmi: Handle early HMIs on thread0 when secondaries are still in OPAL.Mahesh Salgaonkar2018-09-271-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* fast-reboot: verify firmware "romem" checksumNicholas Piggin2018-09-202-0/+52
| | | | | | | | | | | | | | | | This takes a checksum of skiboot memory after boot that should be unchanged during OS operation, and verifies it before allowing a fast reboot. This is not read-only memory from skiboot's point of view, beause it includes things like the opal branch table that gets populated during boot. This helps to improve the integrity of firmware against host and runtime firmware memory scribble bugs. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* skiboot.lds.S: move read-write data after the end of symbol mapNicholas Piggin2018-09-201-2/+0
| | | | | | | | This also tidies up linker script symbol declarations and adds _rodata_mem symbol for the next change to use. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/mem_region: mambo reserve kernel payload areasNicholas Piggin2018-09-2011-3/+40
| | | | | | | | | | Mambo image payloads get overwritten by the OS and by fast reboot memory clearing because they have no region defined. Add them, which allows fast reboot to work. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [stewart: fix up 'make check'] Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* core/fast-reboot: print the fast reboot disable reasonNicholas Piggin2018-09-191-5/+7
| | | | | | | | | | Once things start to go wrong, disable_fast_reboot can be called a number of times, so make the first reason sticky, and also print it to the console at disable time. This helps with making sense of fast reboot disables. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Actually add /ibm,opal/fast-reboot propertyStewart Smith2018-09-181-0/+11
| | | | | | | | I missed a hunk when merging :( Reported-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Fixes: 7c8e1c6f89f3aac77661cfcee75ab515bd053d75 Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* Add fast-reboot property to /ibm,opal DT nodeStewart Smith2018-09-181-0/+2
| | | | | | | this means that if it's permanently disabled on boot, the test suite can pick that up and not try a fast reboot test. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* nvram: Fix wait-for-nvram messageOliver O'Halloran2018-09-171-2/+3
| | | | | | | | | | | We print a message when nvram_query() needs to wait for the NVRAM to be loaded from the BMC/FSP. Currently this is printed at PR_WARNING which is excessive since this doesn't actually indicate that anything is wrong. There's also nothing that we can really do about loading the NVRAM being slow, so just print this at PR_DEBUG. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* nvram: Print how long we waited for nvramOliver O'Halloran2018-09-172-0/+11
| | | | | | | | Print how long we had to wait for NVRAM to become available if we needed to wait. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
* nvram: Fix a possible NULL pointer de-ref in nvram_query_eq()Vaibhav Jain2018-09-171-0/+9
| | | | | | | | | | | | | | A fault will occur if 'value == NULL' is passed to nvram_query_eq() to check if a given key doesn't exists in nvram partition. This is an invalid use of the API as its only supposed to be used for keys that exist in nvram and 'value == NULL' is never possible. Hence this patch adds an assert to the function to flag such a use and also prevent NULL being passed as an argument to strcmp(). Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Suggested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
OpenPOWER on IntegriCloud