summaryrefslogtreecommitdiffstats
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
...
* core/cpufeatures: Fix setting DARN and SCV HWCAP feature bitsNicholas Piggin2018-04-051-2/+2
| | | | | | | | | | | | | DARN and SCV has been assigned AT_HWCAP2 (32-63) bits: #define PPC_FEATURE2_DARN 0x00200000 /* darn random number insn */ #define PPC_FEATURE2_SCV 0x00100000 /* scv syscall */ A cpufeatures-aware OS will not advertise these to userspace without this patch. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/cpu: Prevent clobbering of stack guard for boot-cpuVaibhav Jain2018-04-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 90d53934c2da ("core/cpu: discover stack region size before initialising memory regions") introduced memzero for struct cpu_thread in init_cpu_thread(). This has an unintended side effect of clobbering the stack-guard cannery of the boot_cpu stack. This results in opal failing to init with this failure message: CPU: P9 generation processor (max 4 threads/core) CPU: Boot CPU PIR is 0x0004 PVR is 0x004e1200 Guard skip = 0 Stack corruption detected ! Aborting! CPU 0004 Backtrace: S: 0000000031c13ab0 R: 0000000030013b0c .backtrace+0x5c S: 0000000031c13b50 R: 000000003001bd18 ._abort+0x60 S: 0000000031c13be0 R: 0000000030013bbc .__stack_chk_fail+0x54 S: 0000000031c13c60 R: 00000000300c5b70 .memset+0x12c S: 0000000031c13d00 R: 0000000030019aa8 .init_cpu_thread+0x40 S: 0000000031c13d90 R: 000000003001b520 .init_boot_cpu+0x188 S: 0000000031c13e30 R: 0000000030015050 .main_cpu_entry+0xd0 S: 0000000031c13f00 R: 0000000030002700 boot_entry+0x1c0 So the patch provides a fix by tweaking the memset() call in init_cpu_thread() to skip over the stack-guard cannery. Fixes:90d53934c2da("core/cpu: discover stack region size before initialising memory regions") Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/lock.c: ensure valid start value for lock spin duration warningStewart Smith2018-04-031-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous fix in a8e6cc3f4 only addressed half of the problem, as we could also get an invalid value for start, causing us to fail in a weird way. This was caught by the testcases.OpTestHMIHandling.HMI_TFMR_ERRORS test in op-test-framework. You'd get to this part of the test and get the erroneous lock spinning warnings: PATH=/usr/local/sbin:$PATH putscom -c 00000000 0x2b010a84 0003080000000000 0000080000000000 [ 790.140976993,4] WARNING: Lock has been spinning for 790275ms [ 790.140976993,4] WARNING: Lock has been spinning for 790275ms [ 790.140976918,4] WARNING: Lock has been spinning for 790275ms This patch checks the validity of timebase before setting start, and only checks the lock timeout if we got a valid start value. Fixes: a8e6cc3f47525f86ef1d69d69a477b6264d0f8ee Fixes: 84186ef0944c9413262f0974ddab3fb1343ccfe8 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Fix 'make check' compile for mem_clear_rangeStewart Smith2018-03-281-2/+3
| | | | | | | | We play funny business with printf format specifiers because of how we do unit tests. Fixes: c32943bfc1e254176ecab564fdb4752403a48cab Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/cpu: discover stack region size before initialising memory regionsNicholas Piggin2018-03-273-39/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stack allocation first allocates a memory region sized to hold stacks for all possible CPUs up to the maximum PIR of the architecture, zeros the region, then initialises all stacks. Max PIR is 32768 on POWER9, which is 512MB for stacks. The stack region is then shrunk after CPUs are discovered, but this is a bit of a hack, and it leaves a hole in the memory allocation regions as it's done after mem regions are initialised. 0x000000000000..00002fffffff : ibm,os-reserve - OS 0x000030000000..0000303fffff : ibm,firmware-code - OPAL 0x000030400000..000030ffffff : ibm,firmware-heap - OPAL 0x000031000000..000031bfffff : ibm,firmware-data - OPAL 0x000031c00000..000031c0ffff : ibm,firmware-stacks - OPAL *** gap *** 0x000051c00000..000051d01fff : ibm,firmware-allocs-memory@0 - OPAL 0x000051d02000..00007fffffff : ibm,firmware-allocs-memory@0 - OS 0x000080000000..000080b3cdff : initramfs - OPAL 0x000080b3ce00..000080b7cdff : ibm,fake-nvram - OPAL 0x000080b7ce00..0000ffffffff : ibm,firmware-allocs-memory@0 - OS This change moves zeroing into the per-cpu stack setup. The boot CPU stack is set up based on the current PIR. Then the size of the stack region is set, by discovering the maximum PIR of the system from the device tree, before mem regions are intialised. This results in all memory being accounted within memory regions, and less memory fragmentation of OPAL allocations. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* nvram: run nvram_validate() after nvram_reformat()Nicholas Piggin2018-03-272-3/+8
| | | | | | | | | | nvram_reformat() sets nvram_valid = true, but it does not set skiboot_part_hdr. Call nvram_validate() instead, which sets everything up properly. Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/fast-reboot: zero memory after fast rebootNicholas Piggin2018-03-272-0/+82
| | | | | | | | | | | | | | | | | | This improves the security and predictability of the fast reboot environment. There can not be a secure fence between fast reboots, because a malicious OS can modify the firmware itself. However a well-behaved OS can have a reasonable expectation that OS memory regions it has modified will be cleared upon fast reboot. The memory is zeroed after all other CPUs come up from fast reboot, just before the new kernel is loaded and booted into. This allows image preloading to run concurrently, and will allow parallelisation of the clearing in future. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* mem-map: Use a symbolic constant for exception vector sizeNicholas Piggin2018-03-271-8/+10
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/fast-reboot: verify mem regions before fast rebootNicholas Piggin2018-03-273-7/+35
| | | | | | | | | | | | | Run the mem_region sanity checkers before proceeding with fast reboot. This is the beginning of proactive sanity checks on opal data for fast reboot (with complements the reactive disable_fast_reboot cases). This is encouraged to re-use and share any kind of debug code and unit test code. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* NPU2: dump NPU2 registers on npu2 HMIStewart Smith2018-03-271-2/+73
| | | | | | | | | | | Due to the nature of debugging npu2 issues, folk are wanting the full list of NPU2 registers dumped when there's a problem. We have to list out each register as traversing the range triggers FIR bits that confuse PRD. Suggested-by: Ryan Black <rblack@us.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Revert "NPU2 HMIs: dump out a *LOT* of npu2 registers for debugging"Stewart Smith2018-03-271-37/+1
| | | | | | | | | | | | | This reverts commit fbdc91e693fc3103f7e2a65054ed32bfb26a2e17. We don't need this as we need to do it a different way, with a explicit set of registers as otherwise we trip other random FIR bits and everything becomes even more terrible. I suggest alcohol. Cc: stable Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/fast-reboot: disable fast reboot upon fundamental entry/exit/locking errorsNicholas Piggin2018-03-222-0/+3
| | | | | | | | This disables fast reboot in several more cases where serious errors like lock corruption or call re-entrancy are detected. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/opal: allow some re-entrant callsNicholas Piggin2018-03-221-3/+16
| | | | | | | | | | | | | | | This allows a small number of OPAL calls to succeed despite re-entering the firmware, and rejects others rather than aborting. This allows a system reset interrupt that interrupts OPAL to do something useful. Sreset other CPUs, use the console, which allows xmon to work or stack traces to be printed, reboot the system. Use OPAL_INTERNAL_ERROR when rejecting, rather than OPAL_BUSY, which is used for many other things that does not mean a serious permanent error. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/opal: abort in case of re-entrant OPAL callNicholas Piggin2018-03-221-1/+1
| | | | | | | | The stack is already destroyed by the time we get here, so there is not much point continuing. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* dts: spl_wakeup: Remove all workarounds in the spl wakeup logicShilpasri G Bhat2018-03-141-30/+29
| | | | | | | | | | | | We coded few workarounds in special wakeup logic to handle the buggy firmware. Now that is fixed remove them as they break the special wakeup protocol. As per the spec we should not de-assert beofre assert is complete. So follow this protocol. Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Tested-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Don't detect lock timeouts when timebase is invalidStewart Smith2018-03-091-0/+7
| | | | | | | | | | | | | | We can have threads waiting on hmi_lock who have an invalid timebase. Because of this, we want to go poke the register directly rather than rely on this_cpu()->tb_invalid (which won't have been set yet). Without this patch, you get something like this when you're injecting timebase errors: [10976.202052846,4] WARNING: Lock has been spinning for 10976394ms Fixes: 84186ef0944c9413262f0974ddab3fb1343ccfe8 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* cpu_idle_job: relax a bitStewart Smith2018-03-081-0/+1
| | | | | | | | | This *dramatically* improves kernel boot time with GCOV builds from ~3minutes between loading kernel and switching the HILE bit down to around 10 seconds. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* gcov: Add gcov data struct to sysfsMatt Brown2018-03-082-1/+4
| | | | | | | | | | | | Extracting the skiboot gcov data is currently a tedious process which involves taking a mem dump of skiboot and searching for the gcov_info struct. This patch adds the gcov struct to sysfs under /opal/exports. Allowing the data to be copied directly into userspace and processed. Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com> [stewart: refactor to dump out whole skiboot area, as gcov data is all over] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/lock: Add lock timeout warningsMatt Brown2018-03-071-0/+27
| | | | | | | | | | | | | | | | There are currently no timeout warnings for locks in skiboot. We assume that the lock will eventually become free, which may not always be the case. This patch adds timeout warnings for locks. Any lock which spins for more than 5 seconds will throw a warning and stacktrace for that thread. This is useful for debugging siturations where a lock which hang, waiting for the lock to be freed. Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com> Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com> [stewart: make code match comment, have 5s timeout] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/lock: Add deadlock detectionMatt Brown2018-03-072-1/+84
| | | | | | | | | | | | | This adds simple deadlock detection. The detection looks for circular dependencies in the lock requests. It will abort and display a stack trace when a deadlock occurs. The detection is enabled by DEBUG_LOCKS (enabled by default). While the detection may have a slight performance overhead, as there are not a huge number of locks in skiboot this overhead isn't significant. Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com> [stewart: fix build with DEBUG_LOCKS off] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Revert "console(lpc/fsp-console): Use only stdout-path property on P9 and above"Stewart Smith2018-03-062-13/+8
| | | | | | | | | | | | | This reverts commit 20f685a3627a2a522c465716377561a8fbcc608f. We've hit problems on Zaius machines and the needed petitboot changes haven't made it upstream yet. Let's revert for the time being while we sort everything out. We probably have to keep both around for a few years. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Reduce log level of error messageMichael Neuling2018-03-061-1/+1
| | | | | | | | | | | | | | | | | If a link doesn't train, we can end up with error messages like this: [ 63.027261959,3] PHB#0032[8:2]: LINK: Timeout waiting for electrical link [ 63.027265573,3] PHB#0032:00:00.0 Error -6 resetting The first message is useful but the second message is just debug from the core PCI code and is confusing to print to the console. This reduces the second print to debug level so it's not seen by the console by default. Signed-off-by: Michael Neuling <mikey@neuling.org> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Tie tm-suspend fw-feature and opal_reinit_cpus() togetherMichael Neuling2018-03-041-5/+22
| | | | | | | | | | | | | | | | | | | | | | | Currently opal_reinit_cpus(OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED) always returns OPAL_UNSUPPORTED. This ties the tm suspend fw-feature to the opal_reinit_cpus(OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED) so that when tm suspend is disabled, we correctly report it to the kernel. For backwards compatibility, it's assumed tm suspend is available if the fw-feature is not present. Currently hostboot will clear fw-feature(TM_SUSPEND_ENABLED) on P9N DD2.1. P9N DD2.2 will set fw-feature(TM_SUSPEND_ENABLED). DD2.0 and below has TM disabled completely (not just suspend). We are using opal_reinit_cpus() to determine this setting (rather than the device tree/HDAT) as some future firmware may let us change this dynamically after boot. That is not the case currently though. Signed-off-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* fast-reboot: enable by default for POWER9Stewart Smith2018-03-011-5/+0
| | | | | | Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Acked-By: Michael Neuling <mikey@neuling.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* phb4: set PBCQ Tunnel BAR for tunneled operationsPhilippe Bergheaud2018-03-011-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | P9 supports PCI tunneled operations (atomics and as_notify) that are initiated by devices. A subset of the tunneled operations require a response, that must be sent back from the host to the device. For example, an atomic compare and swap will return the compare status, as swap will only performed in case of success. Similarly, as_notify reports if the target thread has been woken up or not, because the operation may fail. To enable tunneled operations, a device driver must tell the host where it expects tunneled operation responses, by setting the PBCQ Tunnel BAR Response register with a specific value within the range of its BARs. This register is currently initialized by enable_capi_mode(). But, as tunneled operations may also operate in PCI mode, a new API is required to set the PBCQ Tunnel BAR Response register, without switching to CAPI mode. This patch provides two new OPAL calls to get/set the PBCQ Tunnel BAR Response register. Note: as there is only one PBCQ Tunnel BAR register, shared between all the devices connected to the same PHB, only one of these devices will be able to use tunneled operations, at any time. Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/hmi: report processor recovery reason from core FIR bits on P9Nicholas Piggin2018-03-011-3/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an error is encountered that causes processor recovery, HMI is generated if the recovery was successful. The reason is recorded in the core FIR, which gets copied into the WOF. In this case dump the WOF register and an error string into the OPAL msglog. A broken init setting led to HMIs reported in Linux as: [ 3.591547] Harmless Hypervisor Maintenance interrupt [Recovered] [ 3.591648] Error detail: Processor Recovery done [ 3.591714] HMER: 2040000000000000 This patch would have been useful because it tells us exactly that the problem is in the d-side ERAT: [ 414.489690798,7] HMI: Received HMI interrupt: HMER = 0x2040000000000000 [ 414.489693339,7] HMI: [Loc: UOPWR.0000000-Node0-Proc0]: P:0 C:1 T:1: Processor recovery occurred. [ 414.489699837,7] HMI: Core WOF = 0x0000000410000000 recovered error: [ 414.489701543,7] HMI: LSU - SRAM (DCACHE parity, etc) [ 414.489702341,7] HMI: LSU - ERAT multi hit In future it will be good to unify this reporting, so Linux could print something more useful. Until then, this gives some good data. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/ipmi-opal: Add interrupt-parent property for ipmi node on P9 and above.Pridhiviraj Paidipeddi2018-03-011-1/+7
| | | | | | | | | | | | | dtc complains below warning with newer 4.2+ kernels. dts: Warning (interrupts_property): Missing interrupt-parent for /ibm,opal/ipmi This fix adds interrupt-parent property under /ibm,opal/ipmi DT node on P9 and above, which allows ipmi-opal to properly use the OPAL irqchip. Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> [stewart: fix indentation] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* console(lpc/fsp-console): Use only stdout-path property on P9 and abovePridhiviraj Paidipeddi2018-03-012-8/+13
| | | | | | | | | | | | | | | | | | | dtc tool complaining about below warning as usage of linux,stdout-path property under /chosen node is deprecated. dts: Warning (chosen_node_stdout_path): Use 'stdout-path' instead of 'linux,stdout-path' So this patch fix this by using stdout-path property on all the systems and keep linux,stdout-path only on P8 and before. This property refers to a node which represents the device to be used for boot console output. Verified boot on both P8 and P9 systems with new and older kernels. And also verified dtc warnings got fixed in both P8 and P9. Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> [stewart: simplify logic] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* platforms: Add OpenCAPI platform data and device tree nodesAndrew Donnellan2018-03-011-0/+11
| | | | | | | | | | | | | | | | Add OpenCAPI platform data for the zaius and zz platforms, as well as the generic platform that's used for BML boots. Currently, all three platforms are identical, but that won't always be the case (e.g. Witherspoon). Additionally, for Zaius, hardcode link information and the I2C bus that's required to reset OpenCAPI devices, because this currently can't be extracted from HDAT. Eventually this will go away once Hostboot adds the relevant data in HDAT. A later patch will add this for ZZ once we've done more testing. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* npu2-opencapi: Train OpenCAPI links and setup devicesAndrew Donnellan2018-03-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Scan the OpenCAPI links under the NPU, and for each link, reset the card, set up a device, train the link and register a PHB. Implement the necessary operations for the OpenCAPI PHB type. For bringup, test and debug purposes, we allow an NVRAM setting, "opencapi-link-training" that can be set to either disable link training completely or to use the prbs31 test pattern. To disable link training: nvram -p ibm,skiboot --update-config opencapi-link-training=none To use prbs31: nvram -p ibm,skiboot --update-config opencapi-link-training=prbs31 Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* npu2-opencapi: Configure NPU for OpenCAPIAndrew Donnellan2018-03-011-0/+2
| | | | | | | | | | | | | Scan the device tree for NPUs with OpenCAPI links and configure the NPU per the initialisation sequence in the NPU OpenCAPI workbook. Training of individual links and setup of per-AFU/link configuration will be in a later patch. Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* NPU2 HMIs: dump out a *LOT* of npu2 registers for debuggingStewart Smith2018-02-281-1/+37
| | | | | | | | | | This is not the way we want to end up doing this. This is a hack to make folk happy and not require crondump to debug nvidia/npu2 issues. Cc: stable Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/init: Assert when kernel not foundMichael Neuling2018-02-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the kernel doesn't load out of flash or there is nothing at KERNEL_LOAD_BASE, we end up with an esoteric message as we try to branch to out of skiboot into nothing [ 0.007197688,3] INIT: ELF header not found. Assuming raw binary. [ 0.014035267,5] INIT: Starting kernel at 0x0, fdt at 0x3044ad90 13029 [ 0.014042254,3] *********************************************** [ 0.014069947,3] Fatal Exception 0xe40 at 0000000000000000 [ 0.014085574,3] CFAR : 00000000300051c4 [ 0.014090118,3] SRR0 : 0000000000000000 SRR1 : 0000000000000000 [ 0.014096243,3] HSRR0: 0000000000000000 HSRR1: 9000000000001000 [ 0.014102546,3] DSISR: 00000000 DAR : 0000000000000000 [ 0.014108538,3] LR : 00000000300144c8 CTR : 0000000000000000 [ 0.014114756,3] CR : 40002202 XER : 00000000 [ 0.014120301,3] GPR00: 000000003001447c GPR16: 0000000000000000 This improves the message and asserts in this case: [ 0.014042685,5] INIT: Starting kernel at 0x0, fdt at 0x3044ad90 13049 bytes) [ 0.014049556,0] FATAL: Kernel is zeros, can't execute! [ 0.014054237,0] Assert fail: core/init.c:566:0 [ 0.014060472,0] Aborting! Signed-off-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Tested-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core: Fix 'opal-runtime-size' propertyVasant Hegde2018-02-281-5/+5
| | | | | | | | | | | | | We are populating 'opal-runtime-size' before calculating actual stack size. Hence we endup having wrong runtime size (ex: on P9 it shows ~540MB while actual size is around ~40MB). Note that only device tree property is shows wrong value, but reserved-memory reflects correct size. init_all_cpus() calculates and updates actual stack size. Hence move this function call before add_opal_node(). Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* build: use thin archives rather than incremental linkingNicholas Piggin2018-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | This changes to build system to use thin archives rather than incremental linking for built-in.o, similar to recent change to Linux. built-in.o is renamed to built-in.a, and is created as a thin archive with no index, for speed and size. All built-in.a are aggregated into a skiboot.tmp.a which is a thin archive built with an index, making it suitable or linking. This is input into the final link. The advantags of build size and linker code placement flexibility are not as great with skiboot as a bigger project like Linux, but it's a conceptually better way to build, and is more compatible with link time optimisation in toolchains which might be interesting for skiboot particularly for size reductions. Size of build tree before this patch is 34.4MB, afterwards 23.1MB. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* direct-controls: mambo fix for multiple chipsNicholas Piggin2018-02-281-2/+8
| | | | | Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Make fast reboot creset PHBs in parallelMichael Neuling2018-02-281-30/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In this patch, we added a creset to the fast reboot path: commit a1eba9d29d17ff44fca1293b071023a9fbf4b938 Author: Andrew Donnellan <andrew.donnellan@au1.ibm.com> fast-reboot: creset PHBs on fast reboot Unfortunately, this does the creset in serial rather than in parallel. This patch changes the creset on fast reboot to operate in parallel. It simplifies the code by abstracting pci_init_slots() so that it can be used on boot and fast reboot to perform all the PCI retraining. This improves fast reboot PCI training on a dual chip P9 from ~12 seconds down to ~2 seconds. Similar improvements for P8 are achieved as well. This means the time to download the BOOTKERNEL is the bottleneck for fast reboot. Signed-off-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Russell Currey <ruscur@russell.cc> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* pci: Move code aroundMichael Neuling2018-02-281-63/+63
| | | | | | | | | | | This just moves some functions around. A future patch will reuse some of these in different locations, so the order needs to change. No code or functional changes Signed-off-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/pci-dt-slot: Fix booting with no slot mapMichael Neuling2018-02-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently if you don't have a slot map in the device tree in /ibm,pcie-slots, you can crash with a back trace like this: CPU 0034 Backtrace: S: 0000000031cd3370 R: 000000003001362c .backtrace+0x48 S: 0000000031cd3410 R: 0000000030019e38 ._abort+0x4c S: 0000000031cd3490 R: 000000003002760c .exception_entry+0x180 S: 0000000031cd3670 R: 0000000000001f10 * S: 0000000031cd3850 R: 00000000300b4f3e * cpu_features_table+0x1d9e S: 0000000031cd38e0 R: 000000003002682c .dt_node_is_compatible+0x20 S: 0000000031cd3960 R: 0000000030030e08 .map_pci_dev_to_slot+0x16c S: 0000000031cd3a30 R: 0000000030091054 .dt_slot_get_slot_info+0x28 S: 0000000031cd3ac0 R: 000000003001e27c .pci_scan_one+0x2ac S: 0000000031cd3ba0 R: 000000003001e588 .pci_scan_bus+0x70 S: 0000000031cd3cb0 R: 000000003001ee74 .pci_scan_phb+0x100 S: 0000000031cd3d40 R: 0000000030017ff0 .cpu_process_jobs+0xdc S: 0000000031cd3e00 R: 0000000030014cb0 .__secondary_cpu_entry+0x44 S: 0000000031cd3e80 R: 0000000030014d04 .secondary_cpu_entry+0x34 S: 0000000031cd3f00 R: 0000000030002770 secondary_wait+0x8c [ 73.016947149,3] Fatal MCE at 0000000030026054 .dt_find_property+0x30 [ 73.017073254,3] CFAR : 0000000030026040 [ 73.017138048,3] SRR0 : 0000000030026054 SRR1 : 9000000000201000 [ 73.017198375,3] HSRR0: 0000000000000000 HSRR1: 0000000000000000 [ 73.017263210,3] DSISR: 00000008 DAR : 7c7b1b7848002524 [ 73.017352517,3] LR : 000000003002602c CTR : 000000003009102c [ 73.017419778,3] CR : 20004204 XER : 20040000 [ 73.017502425,3] GPR00: 000000003002682c GPR16: 0000000000000000 [ 73.017586924,3] GPR01: 0000000031c23670 GPR17: 0000000000000000 [ 73.017643873,3] GPR02: 00000000300fd500 GPR18: 0000000000000000 [ 73.017767091,3] GPR03: fffffffffffffff8 GPR19: 0000000000000000 [ 73.017855707,3] GPR04: 00000000300b3dc6 GPR20: 0000000000000000 [ 73.017943944,3] GPR05: 0000000000000000 GPR21: 00000000300bb6d2 [ 73.018024709,3] GPR06: 0000000031c23910 GPR22: 0000000000000000 [ 73.018117716,3] GPR07: 0000000031c23930 GPR23: 0000000000000000 [ 73.018195974,3] GPR08: 0000000000000000 GPR24: 0000000000000000 [ 73.018278350,3] GPR09: 0000000000000000 GPR25: 0000000000000000 [ 73.018353795,3] GPR10: 0000000000000028 GPR26: 00000000300be6fb [ 73.018424362,3] GPR11: 0000000000000000 GPR27: 0000000000000000 [ 73.018533159,3] GPR12: 0000000020004208 GPR28: 0000000030767d38 [ 73.018642725,3] GPR13: 0000000031c20000 GPR29: 00000000300b3dc6 [ 73.018737925,3] GPR14: 0000000000000000 GPR30: 0000000000000010 [ 73.018794428,3] GPR15: 0000000000000000 GPR31: 7c7b1b7848002514 This has been seen in the lab on a witherspoon using the device tree entry point (ie. no HDAT). This fixes the null pointer deref. Signed-off-by: Michael Neuling <mikey@neuling.org> Tested-by: Reza Arbab <arbab@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core: Fix mismatched names between reserved memory nodes & propertiesJeremy Kerr2018-02-212-15/+24
| | | | | | | | | | | | | | | | | | | OPAL exposes reserved memory regions through the device tree in both new (nodes) and old (properties) formats. However, the names used for these don't match - we use a generated cell address for the nodes, but the plain region name for the properties. This change, heavily based on code from Oliver O'Halloran <oohall@gmail.com>, reworks the dt-generation code to firstly generate the new-format nodes, then uses those same names to generate the property data. Reported-by: Deb McLemore <debmc@linux.vnet.ibm.com> CC: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> [stewart: fix test case] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* sensor-groups: occ: Add support to disable/enable sensor groupShilpasri G Bhat2018-02-211-1/+13
| | | | | | | | | | This patch adds a new opal call to enable/disable a sensor group. This call is used to select the sensor groups that needs to be copied to main memory by OCC at runtime. Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> [stewart: rebase and bump OPAL API number] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* sensors: Support reading u64 sensor valuesShilpasri G Bhat2018-02-211-2/+76
| | | | | | | | | | | | | This patch adds support to read u64 sensor values. This also adds changes to the core and the backend implementation code to make this API as the base call. Host can use this new API to read sensors upto 64bits. This adds a list to store the pointer to the kernel u32 buffer, for older kernels making async sensor u32 reads. Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* dt: add /cpus/ibm, powerpc-cpu-features device tree bindingsNicholas Piggin2018-02-214-1/+931
| | | | | | | | | | | | This is a new CPU feature advertising interface that is fine-grained, extensible, aware of privilege levels, and gives control of features to all levels of the stack (firmware, hypervisor, and OS). The design and binding specification is described in detail in doc/. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [stewart: fix maybe-uninitialized warning from older GCC, doc cleanup] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Revert "pci: Shared slot state synchronisation for hot reset"Russell Currey2018-02-201-14/+0
| | | | | | | | | | An issue was found in shared slot reset where the system can be stuck in an infinite loop, pull the code out until there's a proper fix. This reverts commit 1172a6c57ff3c66f6361e572a1790cbcc0e5ff37. Signed-off-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* increase log verbosity in debug buildsStewart Smith2018-02-181-1/+1
| | | | Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* Add -debug to version on DEBUG buildsStewart Smith2018-02-191-1/+7
| | | | Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* cpu_wait_job: Correctly report time spent waiting for jobStewart Smith2018-02-191-3/+3
| | | | | | | | Way back when, we got confused between timebase and ms, so let's just use ms and be done with it. Fixes: 514406fa44279996bfc9c85c1e4e53689d375e64 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* DT: Add "version" property under ibm, firmware-versions nodeVasant Hegde2018-02-141-0/+20
| | | | | | | | | | | | | | | | First line of VERSION section in PNOR contains firmware version. Use that to add "version" property under firmware versions dt node. Sample output: -------------- root@xxx2:/proc/device-tree/ibm,firmware-versions# lsprop version "witherspoon-ibm-OP9_v1.19_1.94" .... ... Suggested-by: Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core: hostservices: Remove redundant special wakeup codeShilpasri G Bhat2018-02-131-161/+3
| | | | | | | | | Use the generic dctl_{set/clear}_special_wakeup() in hostservices to assert and de-assert core special wakeup for P8 and remove the duplicated code. Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
* core/device.c: Fix dt_find_compatible_nodeAlistair Popple2018-02-132-11/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | dt_find_compatible_node() and dt_find_compatible_node_on_chip() are used to find device nodes under a parent/root node with a given compatible property. dt_next(root, prev) is used to walk the child nodes of the given parent and takes two arguments - root contains the parent node to walk whilst prev contains the previous child to search from so that it can be used as an iterator over all children nodes. The first iteration of dt_find_compatible_node(root, prev) calls dt_next(root, root) which is not a well defined operation as prev is assumed to be child of the root node. The result is that when a node contains no children it will start returning the parent nodes siblings until it hits the top of the tree at which point a NULL derefence is attempted when looking for the root nodes parent. Dereferencing NULL can result in undesirable data exceptions during system boot and untimely non-hilarious system crashes. dt_next() should not be called with prev == root. Instead we add a check to dt_next() such that passing prev = NULL will cause it to start iterating from the first child node (if any). Also add a unit test for this case to run-device.c. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
OpenPOWER on IntegriCloud