1. 30 11月, 2016 1 次提交
  2. 18 11月, 2016 1 次提交
  3. 13 9月, 2016 3 次提交
  4. 22 8月, 2016 1 次提交
    • M
      powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support · 66443efa
      Michael Ellerman 提交于
      When booting from an OpenFirmware which supports it, we use the
      "ibm,client-architecture-support" firmware call to communicate
      our capabilities to firmware.
      
      The format of the structure we pass to firmware is specified in
      PAPR (Power Architecture Platform Requirements), or the public version
      LoPAPR (Linux on Power Architecture Platform Reference).
      
      Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte
      field at bytes 17-20 for the "Platform Facilities Enable". This is
      followed by a 1 byte field at byte 21 for "Sub-Processor Represenation
      Level".
      
      Comparing to the code, there we have the Platform Facilities
      options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its
      full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is
      incorrectly placed at byte 18.
      
      Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes
      to hopefully make it clearer in future.
      
      As far as I'm aware nothing actually consumes this value at this time,
      so the effect of this bug is nil in practice.
      
      It does mean we've been incorrectly setting bit 15 of the "Platform
      Facilities Enable" option for the past ~3 1/2 years, so we should avoid
      allocating that bit to anything else in future.
      
      Fixes: df77c799 ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      66443efa
  5. 10 8月, 2016 1 次提交
  6. 08 6月, 2016 1 次提交
    • M
      powerpc/pseries: Fix IBM_ARCH_VEC_NRCORES_OFFSET since POWER8NVL was added · 2c2a63e3
      Michael Ellerman 提交于
      The recent commit 7cc85103 ("powerpc/pseries: Add POWER8NVL support
      to ibm,client-architecture-support call") added a new PVR mask & value
      to the start of the ibm_architecture_vec[] array.
      
      However it missed the fact that further down in the array, we hard code
      the offset of one of the fields, and then at boot use that value to
      patch the value in the array. This means every update to the array must
      also update the #define, ugh.
      
      This means that on pseries machines we will misreport to firmware the
      number of cores we support, by a factor of threads_per_core.
      
      Fix it for now by updating the #define.
      
      Fixes: 7cc85103 ("powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call")
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2c2a63e3
  7. 01 6月, 2016 1 次提交
  8. 17 12月, 2015 1 次提交
  9. 19 10月, 2015 3 次提交
  10. 13 7月, 2015 1 次提交
  11. 08 6月, 2015 1 次提交
  12. 10 4月, 2015 1 次提交
    • M
      powerpc: Reword the "returning from prom_init" message · 7e862d7e
      Michael Ellerman 提交于
      We get way too many bug reports that say "the kernel is hung in
      prom_init", which stems from the fact that the last piece of output
      people see is "returning from prom_init".
      
      The kernel is almost never hung in prom_init(), it's just that it's
      crashed somewhere after prom_init() but prior to the console coming up.
      
      The existing message should give a clue to that, ie. "returning from"
      indicates that prom_init() has finished, but it doesn't seem to work.
      Let's try something different.
      
      This prints:
      
        Quiescing Open Firmware ...
        Booting Linux via __start() ...
      
      Which hopefully makes it clear that prom_init() is not the problem, and
      although __start() probably isn't either, it's at least the right place
      to begin looking.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Wistfully-Acked-by: NJeremy Kerr <jk@ozlabs.org>
      7e862d7e
  13. 25 6月, 2014 1 次提交
    • M
      powerpc/powernv: Remove OPAL v1 takeover · e2500be2
      Michael Ellerman 提交于
      In commit 27f44888 "Add OPAL takeover from PowerVM" we added support
      for "takeover" on OPAL v1 machines.
      
      This was a mode of operation where we would boot under pHyp, and query
      for the presence of OPAL. If detected we would then do a special
      sequence to take over the machine, and the kernel would end up running
      in hypervisor mode.
      
      OPAL v1 was never a supported product, and was never shipped outside
      IBM. As far as we know no one is still using it.
      
      Newer versions of OPAL do not use the takeover mechanism. Although the
      query for OPAL should be harmless on machines with newer OPAL, we have
      seen a machine where it causes a crash in Open Firmware.
      
      The code in early_init_devtree() to copy boot_command_line into cmd_line
      was added in commit 817c21ad "Get kernel command line accross OPAL
      takeover", and AFAIK is only used by takeover, so should also be
      removed.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e2500be2
  14. 13 1月, 2014 1 次提交
    • B
      powerpc: Check return value of instance-to-package OF call · 10348f59
      Benjamin Herrenschmidt 提交于
      On PA-Semi firmware, the instance-to-package callback doesn't seem
      to be implemented. We didn't check for error, however, thus
      subsequently passed the -1 value returned into stdout_node to
      thins like prom_getprop etc...
      
      Thus caused the firmware to load values around 0 (physical) internally
      as node structures. It somewhat "worked" as long as we had a NULL in the
      right place (address 8) at the beginning of the kernel, we didn't "see"
      the bug. But commit 5c0484e2
      "powerpc: Endian safe trampoline" changed the kernel entry point causing
      that old bug to now cause a crash early during boot.
      
      This fixes booting on PA-Semi board by properly checking the return
      value from instance-to-package.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Tested-by: NOlof Johansson <olof@lixom.net>
      ---
      10348f59
  15. 11 10月, 2013 1 次提交
  16. 25 9月, 2013 1 次提交
  17. 11 9月, 2013 1 次提交
    • V
      powerpc: Fix section mismatch warning for prom_rtas_call · 620e5050
      Vladimir Murzin 提交于
      While cross-building for PPC64 I've got
      
      WARNING: vmlinux.o(.text.unlikely+0x1ba): Section mismatch in
      reference from the function .prom_rtas_call() to the variable
      .init.data:dt_string_start The function .prom_rtas_call() references
      the variable __initdata dt_string_start.  This is often because
      .prom_rtas_call lacks a __initdata annotation or the annotation of
      dt_string_start is wrong.
      
      WARNING: vmlinux.o(.meminit.text+0xeb0): Section mismatch in reference
      from the function .free_area_init_core.isra.47() to the function
      .init.text:.set_pageblock_order() The function __meminit
      .free_area_init_core.isra.47() references a function __init
      .set_pageblock_order().  If .set_pageblock_order is only used by
      .free_area_init_core.isra.47 then annotate .set_pageblock_order with a
      matching annotation.
      
      Fix it by proper annotation of prom_rtas_call.
      Signed-off-by: NVladimir Murzin <murzin.v@gmail.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      620e5050
  18. 14 8月, 2013 2 次提交
    • B
    • B
      powerpc/pmac: Early debug output on screen on 64-bit macs · 7191b615
      Benjamin Herrenschmidt 提交于
      We have a bunch of CONFIG_PPC_EARLY_DEBUG_* options that are intended
      for bringup/debug only. They hard wire a machine specific udbg backend
      very early on (before we even probe the platform), and use whatever
      tricks are available on each machine/cpu to be able to get some kind
      of output out there early on.
      
      So far, on powermac with no serial ports, we have CONFIG_PPC_EARLY_DEBUG_BOOTX
      to use the low-level btext engine on the screen, but it doesn't do much, at
      least on 64-bit. It only really gets enabled after the platform has been
      probed and the MMU enabled.
      
      This adds a way to enable it much earlier. From prom_init.c (while still
      running with Open Firmware), we grab the screen details and set things up
      using the physical address of the frame buffer.
      
      Then btext itself uses the "rm_ci" feature of the 970 processor (Real
      Mode Cache Inhibited) to access it while in real mode.
      
      We need to do a little bit of reorg of the btext code to inline things
      better, in order to limit how much we touch memory while in this mode as
      the consequences might be ... interesting.
      
      This successfully allowed me to debug problems early on with the G5
      (related to gold being broken vs. ppc64 kernels).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7191b615
  19. 24 7月, 2013 1 次提交
  20. 26 4月, 2013 3 次提交
  21. 13 3月, 2013 1 次提交
    • A
      powerpc: Fix -mcmodel=medium breakage in prom_init.c · 1674400a
      Anton Blanchard 提交于
      Commit 5ac47f7a (powerpc: Relocate prom_init.c on 64bit) made
      prom_init.c position independent by manually relocating its entries
      in the TOC.
      
      We get the address of the TOC entries with the __prom_init_toc_start
      linker symbol. If __prom_init_toc_start ends up as an entry in the
      TOC then we need to add an offset to get the current address. This is
      the case for older toolchains.
      
      On the other hand, if we have a newer toolchain that supports
      -mcmodel=medium then __prom_init_toc_start will be created by a
      relative offset from r2 (the TOC pointer). Since r2 has already been
      relocated, nothing more needs to be done.  Adding an offset in this
      case is wrong and Aaro Koskinen and Alexander Graf have noticed noticed
      G5 and OpenBIOS breakage.
      
      Alan Modra suggested we just use r2 to get at the TOC which is simpler
      and works with both old and new toolchains.
      Reported-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1674400a
  22. 10 1月, 2013 2 次提交
    • A
      powerpc: Remove RELOC() macro · 5827d416
      Anton Blanchard 提交于
      Now we relocate prom_init.c on 64bit we can finally remove the
      nasty RELOC() macro.
      
      Finally a patch that I can claim has a net positive effect on
      the kernel. It doesn't happen very often.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5827d416
    • A
      powerpc: Relocate prom_init.c on 64bit · 5ac47f7a
      Anton Blanchard 提交于
      The ppc64 kernel can get loaded at any address which means
      our very early init code in prom_init.c must be relocatable. We do
      this with a pretty nasty RELOC() macro that we wrap accesses of
      variables with. It is very fragile and sometimes we forget to add a
      RELOC() to an uncommon path or sometimes a compiler change breaks it.
      
      32bit has a much more elegant solution where we build prom_init.c
      with -mrelocatable and then process the relocations manually.
      Unfortunately we can't do the equivalent on 64bit and we would
      have to build the entire kernel relocatable (-pie), resulting in a
      large increase in kernel footprint (megabytes of relocation data).
      The relocation data will be marked __initdata but it still creates
      more pressure on our already tight memory layout at boot.
      
      Alan Modra pointed out that the 64bit ABI is relocatable even
      if we don't build with -pie, we just need to relocate the TOC.
      This patch implements that idea and relocates the TOC entries of
      prom_init.c. An added bonus is there are very few relocations to
      process which helps keep boot times on simulators down.
      
      gcc does not put 64bit integer constants into the TOC but to be
      safe we may want a build time script which passes through the
      prom_init.c TOC entries to make sure everything looks reasonable.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5ac47f7a
  23. 15 11月, 2012 1 次提交
  24. 05 9月, 2012 1 次提交
  25. 23 8月, 2012 1 次提交
  26. 01 8月, 2012 1 次提交
  27. 29 6月, 2012 1 次提交
  28. 16 5月, 2012 1 次提交
  29. 14 5月, 2012 2 次提交
  30. 29 3月, 2012 1 次提交
  31. 28 3月, 2012 1 次提交