1. 07 4月, 2014 2 次提交
  2. 24 3月, 2014 3 次提交
  3. 07 3月, 2014 3 次提交
    • S
      powerpc/powernv Platform dump interface · c7e64b9c
      Stewart Smith 提交于
      This enables support for userspace to fetch and initiate FSP and
      Platform dumps from the service processor (via firmware) through sysfs.
      
      Based on original patch from Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
      
      Flow:
        - We register for OPAL notification events.
        - OPAL sends new dump available notification.
        - We make information on dump available via sysfs
        - Userspace requests dump contents
        - We retrieve the dump via OPAL interface
        - User copies the dump data
        - userspace sends ack for dump
        - We send ACK to OPAL.
      
      sysfs files:
        - We add the /sys/firmware/opal/dump directory
        - echoing 1 (well, anything, but in future we may support
          different dump types) to /sys/firmware/opal/dump/initiate_dump
          will initiate a dump.
        - Each dump that we've been notified of gets a directory
          in /sys/firmware/opal/dump/ with a name of the dump type and ID (in hex,
          as this is what's used elsewhere to identify the dump).
        - Each dump has files: id, type, dump and acknowledge
          dump is binary and is the dump itself.
          echoing 'ack' to acknowledge (currently any string will do) will
          acknowledge the dump and it will soon after disappear from sysfs.
      
      OPAL APIs:
        - opal_dump_init()
        - opal_dump_info()
        - opal_dump_read()
        - opal_dump_ack()
        - opal_dump_resend_notification()
      
      Currently we are only ever notified for one dump at a time (until
      the user explicitly acks the current dump, then we get a notification
      of the next dump), but this kernel code should "just work" when OPAL
      starts notifying us of all the dumps present.
      Signed-off-by: NStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c7e64b9c
    • S
      powerpc/powernv: Read OPAL error log and export it through sysfs · 774fea1a
      Stewart Smith 提交于
      Based on a patch by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      
      This patch adds support to read error logs from OPAL and export
      them to userspace through a sysfs interface.
      
      We export each log entry as a directory in /sys/firmware/opal/elog/
      
      Currently, OPAL will buffer up to 128 error log records, we don't
      need to have any knowledge of this limit on the Linux side as that
      is actually largely transparent to us.
      
      Each error log entry has the following files: id, type, acknowledge, raw.
      Currently we just export the raw binary error log in the 'raw' attribute.
      In a future patch, we may parse more of the error log to make it a bit
      easier for userspace (e.g. to be able to display a brief summary in
      petitboot without having to have a full parser).
      
      If we have >128 logs from OPAL, we'll only be notified of 128 until
      userspace starts acknowledging them. This limitation may be lifted in
      the future and with this patch, that should "just work" from the linux side.
      
      A userspace daemon should:
      - wait for error log entries using normal mechanisms (we announce creation)
      - read error log entry
      - save error log entry safely to disk
      - acknowledge the error log entry
      - rinse, repeat.
      
      On the Linux side, we read the error log when we're notified of it. This
      possibly isn't ideal as it would be better to only read them on-demand.
      However, this doesn't really work with current OPAL interface, so we
      read the error log immediately when notified at the moment.
      
      I've tested this pretty extensively and am rather confident that the
      linux side of things works rather well. There is currently an issue with
      the service processor side of things for >128 error logs though.
      Signed-off-by: NStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      774fea1a
    • M
      powerpc/book3s: Recover from MC in sapphire on SCOM read via MMIO. · 55672ecf
      Mahesh Salgaonkar 提交于
      Detect and recover from machine check when inside opal on a special
      scom load instructions. On specific SCOM read via MMIO we may get a machine
      check exception with SRR0 pointing inside opal. To recover from MC
      in this scenario, get a recovery instruction address and return to it from
      MC.
      
      OPAL will export the machine check recoverable ranges through
      device tree node mcheck-recoverable-ranges under ibm,opal:
      
      # hexdump /proc/device-tree/ibm,opal/mcheck-recoverable-ranges
      0000000 0000 0000 3000 2804 0000 000c 0000 0000
      0000010 3000 2814 0000 0000 3000 27f0 0000 000c
      0000020 0000 0000 3000 2814 xxxx xxxx xxxx xxxx
      0000030 llll llll yyyy yyyy yyyy yyyy
      ...
      ...
      #
      
      where:
      	xxxx xxxx xxxx xxxx = Starting instruction address
      	llll llll           = Length of the address range.
      	yyyy yyyy yyyy yyyy = recovery address
      
      Each recoverable address range entry is (start address, len,
      recovery address), 2 cells each for start and recovery address, 1 cell for
      len, totalling 5 cells per entry. During kernel boot time, build up the
      recovery table with the list of recovery ranges from device-tree node which
      will be used during machine check exception to recover from MMIO SCOM UE.
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      55672ecf
  4. 05 3月, 2014 1 次提交
  5. 28 2月, 2014 1 次提交
  6. 15 1月, 2014 2 次提交
  7. 13 12月, 2013 2 次提交
  8. 09 12月, 2013 1 次提交
  9. 05 12月, 2013 2 次提交
  10. 30 10月, 2013 2 次提交
  11. 11 10月, 2013 4 次提交
  12. 27 8月, 2013 1 次提交
  13. 14 8月, 2013 2 次提交
  14. 21 6月, 2013 1 次提交
  15. 20 6月, 2013 1 次提交
  16. 14 5月, 2013 1 次提交
  17. 10 5月, 2013 1 次提交
  18. 26 4月, 2013 1 次提交
  19. 07 12月, 2011 1 次提交
  20. 20 9月, 2011 5 次提交
    • B
      powerpc/powernv: Machine check and other system interrupts · ed79ba9e
      Benjamin Herrenschmidt 提交于
      OPAL can handle various interrupt for us such as Machine Checks (it
      performs all sorts of recovery tasks and passes back control to us with
      informations about the error), Hardware Management Interrupts and Softpatch
      interrupts.
      
      This wires up the mechanisms and prints out specific informations returned
      by HAL when a machine check occurs.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ed79ba9e
    • B
      powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks · 628daa8d
      Benjamin Herrenschmidt 提交于
      Implements OPAL RTC and NVRAM support and wire all that up to
      the powernv platform.
      
      We use RTAS for RTC as a fallback if available. Using RTAS for nvram
      is not supported yet, pending some rework/cleanup and generalization
      of the pSeries & CHRP code. We also use RTAS fallbacks for power off
      and reboot
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      628daa8d
    • B
      powerpc/powernv: Support for OPAL console · daea1175
      Benjamin Herrenschmidt 提交于
      This adds a udbg and an hvc console backend for supporting a console
      using the OPAL console interfaces.
      
      On OPAL v1 we have hvc0 mapped to whatever console the system was
      configured for (network or hvsi serial port) via the service
      processor.
      
      On OPAL v2 we have hvcN mapped to the Nth console provided by OPAL
      which generally corresponds to:
      
      	hvc0 : network console (raw protocol)
      	hvc1 : serial port S1 (hvsi)
      	hvc2 : serial port S2 (hvsi)
      
      Note: At this point, early debug console only works with OPAL v1
      and shouldn't be enabled in a normal kernel.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      daea1175
    • B
      powerpc/powernv: Basic support for OPAL · 14a43e69
      Benjamin Herrenschmidt 提交于
      Add definition of OPAL interfaces along with  the wrappers to call
      into OPAL runtime and the early device-tree parsing hook to locate
      the OPAL runtime firmware.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      14a43e69
    • B
      powerpc/powernv: Add OPAL takeover from PowerVM · 27f44888
      Benjamin Herrenschmidt 提交于
      On machines supporting the OPAL firmware version 1, the system
      is initially booted under pHyp. We then use a special hypercall
      to verify if OPAL is available and if it is, we then trigger
      a "takeover" which disables pHyp and loads the OPAL runtime
      firmware, giving control to the kernel in hypervisor mode.
      
      This patch add the necessary code to detect that the OPAL takeover
      capability is present when running under PowerVM (aka pHyp) and
      perform said takeover to get hypervisor control of the processor.
      
      To perform the takeover, we must first use RTAS (within Open
      Firmware runtime environment) to start all processors & threads,
      in order to give control to OPAL on all of them. We then call
      the takeover hypercall on everybody, OPAL will re-enter the kernel
      main entry point passing it a flat device-tree.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      27f44888