aboutsummaryrefslogtreecommitdiff
path: root/core
AgeCommit message (Collapse)AuthorFilesLines
2020-03-10mpipl: Rework memory reservation for OPAL dumpVasant Hegde2-23/+37
[ Upstream commit b0e024216a3b1d35aa2273b6f64742db7ae49861 ] During boot, OPAL reserves memory required to capture OPAL dump and architected register data. During MPIPL, hostboot will copy OPAL dump to this memory. Post MPIPL kernel will use this memory to create opalcore. We use mem_reserve_fw() for this reservation. At present this reservation happens late in the init path. It may clash with memory allocated by local_alloc(). We have two option to fix above issue: - Use local_alloc() for allocating memory for OPAL dump This works fine on first boot. We can use this method to reserve memory. But Post MPIPL we still want to reserve destination memory to make sure no one is stomping this area. Also this reservation might have happened in between other local_allocations. So in Post MPIPL boot allocator may not find enough memory in first region for other local_alloc() requests and may throw mem_alloc() error before trying to allocate from other regions. - Early memory reservation for OPAL dump Allocate and reserve memory just after memory region init. This patch uses second approach to fix reservation issue. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-10xscom: Don't log xscom errors caused by OPAL callsOliver O'Halloran1-0/+3
[ Upstream commit 80fd2e963bd4364ee8c3b5a06215d8cbdfe04fcb ] The XSCOM read/write OPAL calls are largely there to support running PRD in the OS. PRD itself handles submitting error logs (if needed) when a XSCOM operation fails so there's no need to send an error log from inside of OPAL. Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-03-09mpipl: Disable fast-reboot during post MPIPL bootVasant Hegde1-0/+2
[ Upstream commit b858aef5210e98b19419ad4dc347cf96d89cbf85 ] Otherwise device tree will continue to have `mpipl-boot` and kernel may think its MPIPL boot. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Stewart Smith <stewart@flamingspork.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2019-10-23core/ipmi: Fix use-after-freeVasant Hegde1-3/+11
[ Upstream commit d75e82dbfbb9443efeb3f9a5921ac23605aab469 ] Commit f01cd77 introduced backend poller() for ipmi message. But in some corner cases its possible that we endup calling poller() after freeing ipmi message. Thread 1 : ipmi_queue_msg_sync() Waiting for ipmi sync message to complete Thread 2 : bt_poll() -> ipmi_cmd_done() -> callback handler -> free message Oliver hit this issue during fast-reboot test with skiboot DEBUG build. In debug build we poision the memory after free. That helped us to catch this issue. [ 460.295570781,3] *********************************************** [ 460.295773157,3] Fatal MCE at 0000000030035cb4 .ipmi_queue_msg_sync+0x110 MSR 9000000000201002 [ 460.295887496,3] CFAR : 0000000030035ce8 MSR : 9000000000000000 [ 460.295956419,3] SRR0 : 0000000030035cb4 SRR1 : 9000000000201002 [ 460.296035015,3] HSRR0: 0000000030012624 HSRR1: 9000000002803002 [ 460.296102413,3] DSISR: 00000008 DAR : 99999999999999d1 [ 460.296169710,3] LR : 0000000030035ce4 CTR : 0000000030002880 [ 460.296248482,3] CR : 28002422 XER : 20040000 [ 460.296336621,3] GPR00: 0000000030035ce4 GPR16: 00000000301d36d8 [ 460.296415449,3] GPR01: 0000000031c133d0 GPR17: 00000000300f5cd8 [ 460.296482811,3] GPR02: 0000000030142700 GPR18: 0000000030407ff0 [ 460.296550265,3] GPR03: 0000000000000100 GPR19: 0000000000000000 [ 460.296629041,3] GPR04: 0000000028002424 GPR20: 0000000000000000 [ 460.296696369,3] GPR05: 0000000020040000 GPR21: 0000000030121d73 [ 460.296820977,3] GPR06: c000001fffffd480 GPR22: 0000000030121dd2 [ 460.296888226,3] GPR07: c000001fffffd480 GPR23: 0000000030613400 [ 460.296978218,3] GPR08: 0000000000000001 GPR24: 0000000000000001 [ 460.297056871,3] GPR09: 9999999999999999 GPR25: 0000000031c13960 [ 460.297124647,3] GPR10: 0000000000000000 GPR26: 0000000000000004 [ 460.297203811,3] GPR11: 0000000000000000 GPR27: 0000000000000003 [ 460.297271250,3] GPR12: 0000000028002424 GPR28: 0000000030613400 [ 460.297339026,3] GPR13: 0000000031c10000 GPR29: 0000000030406b50 [ 460.297417605,3] GPR14: 00000000300f58f8 GPR30: 0000000030406b40 [ 460.297485176,3] GPR15: 00000000300f58d8 GPR31: 00000000309249c8 Reported-by: Oliver O'Halloran <oohall@gmail.com> Fixes: f01cd77 (ipmi: ensure forward progress on ipmi_queue_msg_sync()) Cc: skiboot-stable@lists.ozlabs.org # v6.3+ Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2019-10-23core/platform: Actually disable fast-reboot on P8Oliver O'Halloran1-3/+5
[ Upstream commit 923b5a5342a7a37bd376327e35c7fcb98138d41c ] There was an attempt. It was not successful. Fixes: 14f709b8eeda ("Disable fast-reset for POWER8") Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2019-10-23core/flash: Validate secure boot content sizeOliver O'Halloran1-0/+11
[ Upstream commit e2018d2a3d46491dc2abd758c67c1937910b3a67 ] Currently we don't check if the secure boot payload size fits within the partition that we are reading it from. This results in strange failures later on in boot if we cross the boundary between an ECCed and a non-ECCed partition since libflash does not support reading from regions with mixed ECC status. Without this patch: blocklevel_read: Can't cope with partial ecc FLASH: failed to read content size 15728640 BOOTKERNEL partition, rc 3 With: FLASH: Cannot load BOOTKERNEL. Content is larger than the partition Cc: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Acked-by: Stewart Smith <stewart@flamingspork.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2019-08-16pci: Use a macro for accessing PCI BDF Function NumberJordan Niethe1-3/+3
Currently when the Function Number bits of a BDF are needed the bit operations to get it are free coded. There are many places where the Function Number is used, so make a macro to use instead of free coding it everytime. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-16pci: Use a macro for accessing PCI BDF Device NumberJordan Niethe2-4/+4
Currently when the Device Number bits of a BDF are needed the bit operations to get it are free coded. There are many places where the Device Number is used, so make a macro to use instead of free coding it everytime. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-16pci: Use a macro for accessing PCI BDF Bus NumberJordan Niethe1-1/+1
Currently when the Bus Number bits of a BDF are needed the bit operations to get it are free coded. There are many places where the Bus Number is used, so make a macro to use instead of free coding it everytime. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-16core/pci-dt-slots: Remove duplicate PCIDBG() definitionJordan Niethe1-6/+0
PCIDBG() is already defined in pci.h, which is included by pci-dt-slot.c. It should not be defined again so remove this definition. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Prepare architected registers data tagVasant Hegde1-0/+37
Post MPIPL kernel needs saved CPU register details to create vmcore/opalcore. This patch prepares CPU register data tag and add it to tags list. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Reserve memory to capture architected registers dataVasant Hegde1-0/+28
- Split SPIRAH memory to accommodate architected register ntuple. Today we have 1K memory for SPIRAH and it uses 288 bytes. Lets split this into two parts : SPIRAH (756 bytes) architected register memory (256 bytes) - Update SPIRAH architected register ntuple - Calculate memory required to capture architected registers data Ideally we should use HDAT provided data (proc_dump_area->thread_size). But we are not getting this data during boot. Hence lets reserve fixed memory for architected registers data collection. - Add architected registers destination memory to reserve-memory DT node. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Clear tags and metadataVasant Hegde1-0/+6
Post dump process, kernel sends FREE_PRESERVE_MEMEORY notification to OPAL. OPAL will clear metadata section and tags. Subsequent opal_mpipl_query_tag() call will return OPAL_EMPTY. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Add OPAL API to query saved tagsVasant Hegde1-1/+41
Pre-MPIPL kernel saves various information required to create vmcore in metadata area and passes metadata area pointer to OPAL. OPAL will preserve this pointer across MPIPL. Post MPIPL kernel will request for saved tags via this API. Kernel also needs below tags: - Saved CPU registers data to access CPU registers - OPAL metadata area to create opalcore Format: opal_mpipl_query_tag(enum opal_mpipl_tags tag, uint64_t *tag_val) tag : OPAL_MPIPL_TAG_CPU Pointer to CPU register data content metadata area OPAL_MPIPL_TAG_OPAL Pointer to OPAL metadata area OPAL_MPIPL_TAG_KERNEL During first boot, kernel will setup its metadata area and asks OPAL to preserve metadata area pointer across MPIPL. Post MPIPL kernel calls this API to get metadata pointer and it will use that pointer to retrieve metadata and create dump. OPAL_MPIPL_TAG_BOOT_MEM During MPIPL registration kernel will specify how much memory firmware can use for Post MPIPL load. Post MPIPL petitboot kernel will query for this tag to get boot memory size. Return values: OPAL_SUCCESS : Operation success OPAL_PARAMETER : Invalid parameter Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Prepare OPAL data tagVasant Hegde1-0/+61
Post MPIPL kernel needs OPAL metadata to create opalcore. This patch sets up OPAL metadata tag. Next patch will add API to pass metadata pointer to kernel. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15platform: Introduce new reboot typeVasant Hegde1-0/+6
Enhance reboot2 call to support MPIPL. Payload will call this interface to initiate MPIPL. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15HIOMAP: Reset bmc mbox in MPIPL pathVasant Hegde1-0/+12
During boot SBE and early hostboot does not use HIOMAP protocol to get image from PNOR. Instead it expects PNOR TOC and Hostboot Boot Loader to be available at particular address in LPC bus. mbox daemon in BMC side takes care of this during normal boot. Once boot is complete mbox daemon switches to normal mode. During normal reboot, BMC side mbox daemon gets notification and takes care of loading PNOR TOC and HBBL to LPC bus again. In MPIPL path, OPAL calls SBE S0 interrupt to initiate MPIPL. BMC will not be aware of this. But SBE expects PNOR TOC and HBBL to be available in LPC bus at predefined address. Hence call HIOMAP Reset from OPAL in assert path. This needs working LPC and IPMI driver in OPAL. If we have issue in these drivers then we may not be able to reset BMC MBOX properly. Hence MPIPL may fail. We have to live with this until we find a way to intiate BMC on MPIPL. CC: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Save crashing PIRVasant Hegde1-0/+7
Crashing CPU PIR is required to get proper backtrace from core file. Save crashing CPU PIR before triggering MPIPL. Post MPIPL OPAL will pass saved PIR to kernel and kernel will use that to create OPAL dump. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15SBE: Send OPAL relocated base address to SBEVasant Hegde1-0/+4
OPAL relocates itself during boot. During memory preserving IPL hostboot needs to access relocated OPAL base address to get MDST, MDDT tables. Hence send relocated base address to SBE via 'stash MPIPL config' chip-op. During next IPL SBE will send stashed data to hostboot... so that hostboot can access these data. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Add OPAL API to register tagsVasant Hegde1-0/+29
This patch adds new API to register tags. opal_mpipl_register_tag(enum opal_mpipl_tags tag, uint64_t tag_val) tag: OPAL_MPIPL_TAG_KERNEL During first boot, kernel will setup its metadata area and asks OPAL to preserve metadata area pointer across MPIPL. Post MPIPL kernel requests OPAL to provide metadata pointer and it will use that pointer to retrieve metadata and create dump. OPAL_MPIPL_TAG_BOOT_MEM During MPIPL registration kernel will specify how much memory firmware can use for Post MPIPL load. Post MPIPL petitboot kernel will query for this tag to get boot memory size. Return values: OPAL_SUCCESS : Operation success OPAL_PARAMETER : Payload passed invalid tag Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Add OPAL API to register for dump regionVasant Hegde1-0/+181
This patch add new API to register for dump region. u64 opal_mpipl_update(u8 ops, u64 src, u64 dest, u64 size) ops : OPAL_MPIPL_ADD_RANGE Add new entry to MPIPL table. Kernel will send src, dest and size. During MPIPL content from source address is moved to destination address. src = Source start address dest = Destination start address size = size OPAL_MPIPL_REMOVE_RANGE Remove kernel requested entry from MPIPL table. src = Source start address dest = Destination start address size = ignore OPAL_MPIPL_REMOVE_ALL Remove all kernel passed entry from MPIPL table. src = ignore dest = ignore size = ignore OPAL_MPIPL_FREE_PRESERVED_MEMORY Post MPIPL, kernel will indicate OPAL that it has processed dump and it can clear/release metadata area. src = ignore dest = ignore size = ignore Return values: OPAL_SUCCESS : Operation success OPAL_PARAMETER : Payload passed invalid data OPAL_RESOURCE : Ran out of MDST or MDDT table size OPAL_HARDWARE : MPIPL not supported Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Define OPAL metadata areaVasant Hegde1-0/+13
We want to save some information (like crashing CPU PIR, kernel tags, etc) before triggering MPIPL. Post MPIPL we will use this information to retrieve dump metadata and create dump. MDRT table doesn't need 64K. Hence split MDRT table to accommodate metadata area. Finally define metadata structure. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15MPIPL: Register for OPAL dumpVasant Hegde3-1/+149
This patch adds support to register for OPAL dump. - Calculate memory required to capture OPAL dump - Reserve OPAL dump destination memory - Add OPAL dump details to MDST and MDDT table Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-15OPAL: Add OPAL boot entry address to device treeVasant Hegde1-0/+2
Needed for creating OPAL core file. Sample output: -------------- sys/firmware/devicetree/base/ibm,opal # lsprop ... opal-boot-address 00000000 30002560 ... Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [oliver: rebased] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-02SPDX fixups and Copyright date fixesStewart Smith27-21/+43
Ensure the (C) who and years are correct, based on git history. Also a few SPDX fixups Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-08-02core/pci-quirk: Microsemi switch UR workaroundOliver O'Halloran3-0/+90
Some Microsemi switches have a bug where accessing an unimplemented config space register causes an Unsupported Request error. This is a violation of the PCI spec which requires devices to ignore writes and return 0x00 when an unimplemented config space register is accessed. Linux allows userspace to access all of config space and tools (e.g. lspci) will read the entire 4KB space. This results in flood of spurious EEH events since POWER chips treat URs as an indication of a malfunctioning device. This patch adds a PCI device quirk that scans the config space of the switch in early boot to determine what ranges will trigger a UR. With this information we can then use config filters to block accesses to the problematic ranges. This scanning process is a little slow, but: a) This bug should be resolved by a switch firmware update eventually, and b) System firmware updates might result PCIe capabilities being added or removed from the switch's config space. This means that we would have a cache invalidation problem which isn't straightforward to resolve. We can check if the workaround is needed at all by reading 0xFF (the end of the legacy config space) since we know the switch never has anything implemented for that address. Do the simple thing for now rather than trying to make it faster since this should be a temporary workaround. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-By: Alistair Popple <alistair@popple.id.au>
2019-08-02core/pci: Export pci_check_clear_freeze()Oliver O'Halloran1-5/+10
We'd like to be able to check when we get a freeze in the quirk handling code. Make pci_check_clear_freeze un-static so it can be used elsewhere. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-By: Alistair Popple <alistair@popple.id.au>
2019-08-02core/pci-quirk: Re-order struct membersOliver O'Halloran2-4/+4
Having the function first throws out the alignment on the VDID since the functions names are probably different lengths. Swap them ordering of the struct members so the VDID comes first to keep things tidy. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Stewart Smith <stewart@linux.ibm.com> Reviewed-by: Alistair Popple <alistair@popple.id.au>
2019-07-26hw: Introduce npu3Reza Arbab1-0/+1
POWER9P systems have been upgraded with NVLink 3.0 interconnects. The underlying hardware is fundamentally different--each POWER9 chip has (1 NPU) * (3 stacks) * (2 bricks) = (6 links) Where in each POWER9P chip, there are (3 NPUs) * (4 bricks) = (12 links) This flatter hierarchy simplifies the firmware implementation a bit, but also prevents sharing much common code with npu2. As in previous versions, initialize the hardware and expose each link to the OS as a virtual PCIe device. This initial support covers NVLink devices only, with OpenCAPI to follow. Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-26npu2: Add checks to npu2-only codepathsReza Arbab1-0/+4
To prepare for npu3, add a few checks in codepaths that are only for npu2. Compare against PVR_TYPE_P9, as npu3 will be in systems of PVR_TYPE_P9P (or greater). Alternatively, check for dt compatibility with "ibm,power9-npu" because npu3 will use "ibm,power9-npu3". Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-26hw/phys-map: Add pvr argument to phys_map_init()Reza Arbab1-1/+1
When new chip types are added, phys_map_init() will need to know which memory map it should use. Instead of directly checking PVR, make it an argument to the function, so that 'make hw-check' can test all the maps. Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Acked-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Acked-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-26SPDX-ify all skiboot codeStewart Smith80-1093/+311
Use Software Package Data Exchange (SPDX) to indicate license for each file that is unique to skiboot. At the same time, ensure the (C) who and years are correct. See https://spdx.org/ Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: Added a few missing files] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-19pci-slot: Allow to create slot for downstream port of any switchIlya Kuznetsov1-7/+2
System vendor may build systems with large PCIe tree with deeper switch topologies. Currenlty downstream ports slot creation is limited to first switch. Patch allows to use any. Signed-off-by: Ilya Kuznetsov <ilya@yadro.com> [oliver: added pci-slot prefix] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-19sparse: fix (main|secondar)_cpu_entry declaration typesStewart Smith1-2/+2
core/init.c:923:28: error: symbol 'main_cpu_entry' redeclared with different type (originally declared at core/init.c:921) - different modifiers core/init.c:1314:28: error: symbol 'secondary_cpu_entry' redeclared with different type (originally declared at core/init.c:1312) - different modifiers Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-19sparse: Silence "directive in argument list" for version stringStewart Smith1-7/+8
core/init.c:966:1: error: directive in argument list core/init.c:968:1: error: directive in argument list core/init.c:970:1: error: directive in argument list Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-19Silence sparse warning for version.cStewart Smith1-0/+1
version.c:1:12: warning: symbol 'version' was not declared. Should it be static? Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-07-15core/platform: Add finalise_dt() callbackOliver O'Halloran1-0/+3
Previously the platform.exit() callback was called before we created the flattened device tree blob for Linux. Some platforms used this to add various DT properties and this was broken in commit Fixes: 9fc0c1287ada ("Move FSP specific op-panel calls to platform.exit()") which moved the exit callback to after the DTB had been created. The logic for moving the time of the exit call makes some sense since we want to terminate the IPMI watchdog timer as late as possible, but we still need a way for the platform modify the DTB as late as possible. This patch adds another platform callback (yay!) called finalise_dt() which can be used to graft stuff into the DT. Suggested-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-27pci: Make the pci-eeh-verbose nvram option genericOliver O'Halloran1-0/+5
We currently have the "pci-eeh-verbose" NVRAM flag that causes phb4 to print a register dump when it detects the PHB has been fenced. This is useful for debugging most EEH issues since the kernel may not be ready to handle EEH events when the problem is first detected. There's no real reason this needs to be specific to PHB4 so this patch moves the nvram flag handling into the generic init path (along with the pcie_max_link_speed flag) so we can add a similar function for PHB3. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24core/timer: Use platform heartmeat_time call for FSP platformsStewart Smith1-1/+1
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24Move FSP-specific VPD functionality to platforms/ibm-fsp/Stewart Smith2-144/+0
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24fast-reboot: move platform specific bits to a platform callStewart Smith1-2/+2
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24core/pci: use !platform.bmc hack over fsp_present()Stewart Smith1-2/+1
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24core/opal: move HIR trigger to FSP pollerStewart Smith1-14/+0
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24Move FSP specific op-panel calls to platform.exit()Stewart Smith1-10/+3
We move the platform exit call much closer to executing the kernel, which should all be safe, and in fact a much better time to do watchdog related things. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24core/init.c: no longer need to include FSP headersStewart Smith1-2/+0
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24core/init.c: use if (platform.bmc) rather than !fsp_present()Stewart Smith1-1/+1
This decouples FSP platform from core skiboot logic by using this small hack that may/may not be a good idea (although is already used elsewhere, so at least we're consistent). Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24Move core/hostservices.c to platforms/ibm-fsp/Stewart Smith2-944/+1
It's only used on FSP systems so should really just be part of that platform support. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24Move more FSP functions to FSP platformStewart Smith1-12/+0
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-24op_display: make platform function rather than "FSP" specificStewart Smith1-0/+6
We have an implementation for non-FSP systems now, and we shouldn't be calling that from code in an fsp/ directory, so move op_display() to a platform function. Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-06-13sparse: fix bt_lock should be staticStewart Smith1-1/+1
Fix this sparse warning: core/stack.c:123:13: warning: symbol 'bt_lock' was not declared. Should it be static? Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
generated by cgit v1.1 at 2024-08-02 16:55:33 +0000