linux-stable.git/arch/powerpc/kernel/prom_init.c, branch linux-3.3.y

powerpc: Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE

2011-12-20T15:20:19+00:00

The current implementation of CONFIG_RELOCATABLE in BookE is based
on mapping the page aligned kernel load address to KERNELBASE. This
approach however is not enough for platforms, where the TLB page size
is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used
currently in BookE to DYNAMIC_MEMSTART to reflect the actual method.

The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the
dynamic relocations will be introduced in the later in the patch series.

This change would allow the use of the old method of RELOCATABLE for
platforms which can afford to enforce the page alignment (platforms with
smaller TLB size).

Changes since v3:

* Introduced a new config, NONSTATIC_KERNEL, to denote a kernel which is
  either a RELOCATABLE or DYNAMIC_MEMSTART(Suggested by: Josh Boyer)

Suggested-by: Scott Wood 
Tested-by: Scott Wood 

Signed-off-by: Suzuki K. Poulose 
Cc: Scott Wood 
Cc: Kumar Gala 
Cc: Josh Boyer 
Cc: Benjamin Herrenschmidt 
Cc: linux ppc dev 
Signed-off-by: Josh Boyer

powerpc: Fix old bug in prom_init setting of the color

2011-12-19T03:41:25+00:00

We have an array of 16 entries and a loop of 32 iterations... oops.

Signed-off-by: Benjamin Herrenschmidt

powerpc: Only use initrd_end as the limit for alloc_bottom if it's inside the RMO.

2011-12-19T03:41:24+00:00

As the kernels and initrd's get bigger boot-loaders and possibly
kexec-tools will need to place the initrd outside the RMO.  When this
happens we end up with no lowmem and the boot doesn't get very far.

Only use initrd_end as the limit for alloc_bottom if it's inside the
RMO.

Signed-off-by: Paul Mackerras 
Signed-off-by: Tony Breeds 
Signed-off-by: Benjamin Herrenschmidt

powerpc/pseries: Increase minimum RMO size from 64MB to 256MB

2011-12-08T03:22:53+00:00

The minimum RMO size field in ibm,client-architecture is currently
ignored, but a future firmware version will rectify that. Since we
always get at least 128MB of RMO right now, asking for 64MB is
likely to result in boot failures.

We should bump it to at least 128MB, but considering all the boot
issues we have on 128MB RMO boxes and all new machines have virtual
RMO, we may as well set our minimum to 256MB.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt

powerpc/powernv: Workaround OFW issues in prom_init.c

2011-12-07T07:04:53+00:00

Open Firmware on OPAL machines seems to have issues if we close
stdin and/or we try to print things after calling "quiesce" so
we avoid doing both.

Signed-off-by: Benjamin Herrenschmidt

powerpc: panic if we can't instantiate RTAS

2011-11-16T03:47:54+00:00

I had to debug a strange situation where all manner of things were
failing. SMT threads, storage and network were all completely broken.

The root cause was we couldn't find enough memory to instantiate RTAS -
this was a network install so the initrd was huge.

Instead of limping along and failing in mysterious ways we should just
panic up front if RTAS exists and we can't allocate space for it.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Don't try OPAL takeover on old 970 blades

2011-09-29T07:04:59+00:00

The firmware on old 970 blades supports some kind of takeover called
"TNK takeover" which will crash if we try to probe for OPAL takeover,
so don't do it.

Signed-off-by: Benjamin Herrenschmidt

powerpc/powernv: Add support for instanciating OPAL v2 from Open Firmware

2011-09-20T06:09:52+00:00

OPAL v2 is instantiated in a way similar to RTAS using Open Firmware
client interface calls, and the resulting address and entry point are
put in the device-tree

Signed-off-by: Benjamin Herrenschmidt

powerpc/powernv: Get kernel command line accross OPAL takeover

2011-09-20T06:09:48+00:00

We stash it in boot_command_line which isn't in BSS and so won't
be overwritten. We then use that as a default cmd_line before
we walk the device-tree.

Signed-off-by: Benjamin Herrenschmidt

powerpc/powernv: Add OPAL takeover from PowerVM

2011-09-20T06:09:47+00:00

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: Benjamin Herrenschmidt