* [PATCH 1/5] microblaze: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:42 UTC (permalink / raw)
To: Michal Simek, microblaze-uclinux
Cc: David Miller, Paul Mackerras, sparclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/microblaze/Kconfig | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 76818f9..2b37820 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -17,6 +17,8 @@ config MICROBLAZE
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select TRACING_SUPPORT
+ select OF
+ select OF_FLATTREE
config SWAP
def_bool n
@@ -125,8 +127,7 @@ config CMDLINE_FORCE
override those passed by the boot loader.
config OF
- def_bool y
- select OF_FLATTREE
+ bool
config PROC_DEVICETREE
bool "Support for device tree in /proc"
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 2/5] powerpc: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Michal Simek, microblaze-uclinux, David Miller, sparclinux,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Kconfig | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..3697231 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -120,6 +120,8 @@ config ARCH_NO_VIRT_TO_BUS
config PPC
bool
default y
+ select OF
+ select OF_FLATTREE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
@@ -173,8 +175,7 @@ config PPC_OF
def_bool y
config OF
- def_bool y
- select OF_FLATTREE
+ bool
config PPC_UDBG_16550
bool
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 3/5] sparc: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:44 UTC (permalink / raw)
To: David Miller, sparclinux
Cc: Michal Simek, Paul Mackerras, microblaze-uclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6f1470b..d02e8ac 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -18,6 +18,7 @@ config 64BIT
config SPARC
bool
default y
+ select OF
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_ARCH_KGDB if !SMP || SPARC64
@@ -149,7 +150,7 @@ config ARCH_NO_VIRT_TO_BUS
def_bool y
config OF
- def_bool y
+ bool
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y if SPARC64
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 4/5] of: define CONFIG_OF globally so architectures can select it
From: Stephen Rothwell @ 2010-06-29 2:45 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/of/Kconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 7cecc8f..1678dbc 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -1,3 +1,6 @@
+config OF
+ bool
+
config OF_FLATTREE
bool
depends on OF
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 5/5] of: remove architecture CONFIG_OF definitions
From: Stephen Rothwell @ 2010-06-29 2:47 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
now that CONFIG_OF is defined globally
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/microblaze/Kconfig | 3 ---
arch/powerpc/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
3 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 2b37820..1a8f682 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -126,9 +126,6 @@ config CMDLINE_FORCE
Set this to have arguments from the default kernel command string
override those passed by the boot loader.
-config OF
- bool
-
config PROC_DEVICETREE
bool "Support for device tree in /proc"
depends on PROC_FS
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3697231..402f4c0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -174,9 +174,6 @@ config ARCH_MAY_HAVE_PC_FDC
config PPC_OF
def_bool y
-config OF
- bool
-
config PPC_UDBG_16550
bool
default n
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index d02e8ac..13a9f2f 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -149,9 +149,6 @@ config GENERIC_GPIO
config ARCH_NO_VIRT_TO_BUS
def_bool y
-config OF
- bool
-
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y if SPARC64
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 3/5] sparc: turn CONFIG_OF into a select
From: David Miller @ 2010-06-29 3:11 UTC (permalink / raw)
To: sfr
Cc: monstr, microblaze-uclinux, paulus, sparclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629124450.5e85bafe.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 Jun 2010 12:44:50 +1000
> so that we can make CONFIG_OF global and remove it from
> the architecture Kconfig files later.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Using devices trees on X86
From: Grant Likely @ 2010-06-29 5:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
On Mon, Jun 28, 2010 at 7:38 PM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Stephen,
>
> On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer <stephen.neuendor=
ffer@xilinx.com> wrote:
>>
>> 2) config OF is currently implemented in the architecture code. =A0This
>> should be non-architecture dependent and selected by the arches that
>> need it.
>>
>> Comments greatly appreciated, in particular if you have
>> likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
>> carefully solving 2) in
>> a way which doesn't bork the existing of-based arches.
>
> See the following patch set. =A0Parts 1, 2 and 3 could be applied to the
> respective architecture trees as well as Grant's tree to aleviate some
> conflict problems. =A0Part 5 could wait until a later time if necessary.
> However, this is relatively trivial, so we could just collect ACKs and
> put it all in Grant's tree and live with any minor pain.
>
> Having OF in more than one Kconfig file should not cause any problems as
> long as they are all the same.
I've got an Ack from David now. I'll wait for more acks, and then
pull the whole series of 5 into my devicetree-next branch. It's
certainly less invasive that some of the other changes arch changes
I've taken through my tree.
g.
^ permalink raw reply
* Re: Using devices trees on X86
From: Stephen Rothwell @ 2010-06-29 6:02 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <AANLkTikEJluwUSTmG64jgQYAt_8YI7-gVA2iqOPKrM9W@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
Hi Grant,
On Mon, 28 Jun 2010 22:56:14 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> I've got an Ack from David now. I'll wait for more acks, and then
> pull the whole series of 5 into my devicetree-next branch. It's
> certainly less invasive that some of the other changes arch changes
> I've taken through my tree.
Yes, certainly. However, I have a plan to write a series of patches for
PowerPC that may clash some what, so if that is the case, I might ask Ben
to take the one patch as well. Especially if the conflict turns up in
linux-next :-)
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] powerpc: fix feature-fixup tests for gcc 4.5
From: Stephen Rothwell @ 2010-06-29 7:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
The feature-fixup test declare some extern void variables and then take
their addresses. Fix this by declaring them as extern u8 instead.
Fixes these warnings (treated as errors):
CC arch/powerpc/lib/feature-fixups.o
cc1: warnings being treated as errors
arch/powerpc/lib/feature-fixups.c: In function 'test_cpu_macros':
arch/powerpc/lib/feature-fixups.c:293:23: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:294:9: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:297:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:297:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c: In function 'test_fw_macros':
arch/powerpc/lib/feature-fixups.c:306:23: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:307:9: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:310:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:310:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c: In function 'test_lwsync_macros':
arch/powerpc/lib/feature-fixups.c:321:23: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:322:9: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:326:3: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:326:3: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:329:3: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:329:3: error: taking address of expression of type 'void'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/lib/feature-fixups.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
I haven't actually booted this, just built it.
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index e640175..0d08d01 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -12,6 +12,7 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
@@ -288,8 +289,8 @@ static void test_alternative_case_with_external_branch(void)
static void test_cpu_macros(void)
{
- extern void ftr_fixup_test_FTR_macros;
- extern void ftr_fixup_test_FTR_macros_expected;
+ extern u8 ftr_fixup_test_FTR_macros;
+ extern u8 ftr_fixup_test_FTR_macros_expected;
unsigned long size = &ftr_fixup_test_FTR_macros_expected -
&ftr_fixup_test_FTR_macros;
@@ -301,8 +302,8 @@ static void test_cpu_macros(void)
static void test_fw_macros(void)
{
#ifdef CONFIG_PPC64
- extern void ftr_fixup_test_FW_FTR_macros;
- extern void ftr_fixup_test_FW_FTR_macros_expected;
+ extern u8 ftr_fixup_test_FW_FTR_macros;
+ extern u8 ftr_fixup_test_FW_FTR_macros_expected;
unsigned long size = &ftr_fixup_test_FW_FTR_macros_expected -
&ftr_fixup_test_FW_FTR_macros;
@@ -314,10 +315,10 @@ static void test_fw_macros(void)
static void test_lwsync_macros(void)
{
- extern void lwsync_fixup_test;
- extern void end_lwsync_fixup_test;
- extern void lwsync_fixup_test_expected_LWSYNC;
- extern void lwsync_fixup_test_expected_SYNC;
+ extern u8 lwsync_fixup_test;
+ extern u8 end_lwsync_fixup_test;
+ extern u8 lwsync_fixup_test_expected_LWSYNC;
+ extern u8 lwsync_fixup_test_expected_SYNC;
unsigned long size = &end_lwsync_fixup_test -
&lwsync_fixup_test;
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Segher Boessenkool @ 2010-06-29 7:32 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <9B84B663-7DC6-4543-96F7-23F77106065C@suse.de>
>>> On PowerPC it's very normal to not support all of the physical
>>> RAM in real mode.
>>
>> Oh? Are you referring to "real mode limit", or 32-bit
>> implementations with
>> more than 32 address lines, or something else?
>
> The former.
Okay. In that case, the hypervisor can usually access all of physical
ram directly, unless it limits itself; and a supervisor gets either
no real mode access, or all ram, or some part -- whatever the hypervisor
likes.
If you access outside of ram, you will most likely get a machine check.
Depends on the implementation (like most things here).
>> Either way, RMO is a really bad name for this, since that name is
>> already
>> used for a similar but different concept.
>
> It's the same concept, no? Not all physical memory is accessible
> from real mode.
I think you're looking for "real mode limit":
The concept is called "offset real mode".
RMO ("real mode offset") is the value that is ORed to an effective
address
to make the physical address (not added, "offset" is a pretty bad name).
RML ("real mode limit") is the value that has to be bigger than the
effective
address or you will get an exception.
RMA ("real mode area") is the name for the range of addresses usable
in offset
real mode.
>> Also, it seems you construct the physical address by masking out
>> bits from
>> the effective address. Most implementations will trap or machine
>> check if
>> you address outside of physical address space, instead.
>
> Well the only case where I remember to have hit a real RMO case is
> on the PS3 - that issues a data/instruction storage interrupt when
> accessing anything > 8MB in real mode.
>
> So I'd argue this is heavily implementation specific.
It is. So what is the behaviour you want to implement?
> Apart from that what I'm trying to cover is that on ppc64 accessing
> 0xc0000000000000 in real mode gets you 0x0. Is there a better name
> for this?
(You missed two zeroes).
In hypervisor real mode, the top few bits are magic. They are used
for e.g.
enabling hypervisor offset real mode.
In supervisor real mode, those bits are ignored (and all other bits
that do
not correspond to physical address lines may also be ignored).
Maybe you want to call it physical_address_mask or similar?
Segher
^ permalink raw reply
* Re: [PATCH 24/26] KVM: PPC: PV mtmsrd L=0 and mtmsr
From: Segher Boessenkool @ 2010-06-29 7:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <05E77C6E-7465-4A0E-B00B-F1240417281D@suse.de>
>>> There is also a form of mtmsr where all bits need to be
>>> addressed. While the
>>> PPC64 Linux kernel behaves resonably well here, the PPC32 one
>>> never uses the
>>> L=1 form but does mtmsr even for simple things like only changing
>>> EE.
>>
>> You make it sound like the 32-bit kernel does something stupid, while
>> there is no other choice. The "L=1" thing only exists for 64-bit.
>
> Oh, so that's why :). That doesn't really change the fact that it's
> very hard to distinguish between a mtmsr that only changes MSR_EE
> vs one that changes MSR_IR for example :).
Hard to predict for the CPU as well, guess why there is a separate
instruction now :-P
By the way, L=1 _does_ exist for mtmsr; it's just that no 32-bit
"classic"
implementations support it.
Segher
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Alexander Graf @ 2010-06-29 7:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <07830DA6-1B53-4E84-A0E2-8449289C71F1@kernel.crashing.org>
On 29.06.2010, at 09:32, Segher Boessenkool wrote:
>>>> On PowerPC it's very normal to not support all of the physical RAM =
in real mode.
>>>=20
>>> Oh? Are you referring to "real mode limit", or 32-bit =
implementations with
>>> more than 32 address lines, or something else?
>>=20
>> The former.
>=20
> Okay. In that case, the hypervisor can usually access all of physical
> ram directly, unless it limits itself; and a supervisor gets either
> no real mode access, or all ram, or some part -- whatever the =
hypervisor
> likes.
>=20
> If you access outside of ram, you will most likely get a machine =
check.
> Depends on the implementation (like most things here).
>=20
>>> Either way, RMO is a really bad name for this, since that name is =
already
>>> used for a similar but different concept.
>>=20
>> It's the same concept, no? Not all physical memory is accessible from =
real mode.
>=20
> I think you're looking for "real mode limit":
>=20
> The concept is called "offset real mode".
>=20
> RMO ("real mode offset") is the value that is ORed to an effective =
address
> to make the physical address (not added, "offset" is a pretty bad =
name).
> RML ("real mode limit") is the value that has to be bigger than the =
effective
> address or you will get an exception.
> RMA ("real mode area") is the name for the range of addresses usable =
in offset
> real mode.
>=20
>>> Also, it seems you construct the physical address by masking out =
bits from
>>> the effective address. Most implementations will trap or machine =
check if
>>> you address outside of physical address space, instead.
>>=20
>> Well the only case where I remember to have hit a real RMO case is on =
the PS3 - that issues a data/instruction storage interrupt when =
accessing anything > 8MB in real mode.
>>=20
>> So I'd argue this is heavily implementation specific.
>=20
> It is. So what is the behaviour you want to implement?
The one below.
>=20
>> Apart from that what I'm trying to cover is that on ppc64 accessing =
0xc0000000000000 in real mode gets you 0x0. Is there a better name for =
this?
>=20
> (You missed two zeroes).
> In hypervisor real mode, the top few bits are magic. They are used =
for e.g.
> enabling hypervisor offset real mode.
> In supervisor real mode, those bits are ignored (and all other bits =
that do
> not correspond to physical address lines may also be ignored).
So which bits exactly are reserved? I couldn't find a reference to that =
part.
> Maybe you want to call it physical_address_mask or similar?
PAM - doesn't sound bad :).
Alex
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Segher Boessenkool @ 2010-06-29 7:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <182AF505-54A6-4F71-AF5D-7CA40D911C35@suse.de>
>>>> Also, it seems you construct the physical address by masking out
>>>> bits from
>>>> the effective address. Most implementations will trap or
>>>> machine check if
>>>> you address outside of physical address space, instead.
>>>
>>> Well the only case where I remember to have hit a real RMO case
>>> is on the PS3 - that issues a data/instruction storage interrupt
>>> when accessing anything > 8MB in real mode.
>>>
>>> So I'd argue this is heavily implementation specific.
>>
>> It is. So what is the behaviour you want to implement?
>
> The one below.
I'm sorry, I lost it. "Below"?
>>> Apart from that what I'm trying to cover is that on ppc64
>>> accessing 0xc0000000000000 in real mode gets you 0x0. Is there a
>>> better name for this?
>>
>> (You missed two zeroes).
>> In hypervisor real mode, the top few bits are magic. They are
>> used for e.g.
>> enabling hypervisor offset real mode.
>> In supervisor real mode, those bits are ignored (and all other
>> bits that do
>> not correspond to physical address lines may also be ignored).
>
> So which bits exactly are reserved? I couldn't find a reference to
> that part.
If by "reserved" you mean "cannot be used for addressing", it's the
top four
bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 document.
Implementations are allowed to ignore more bits than that.
I believe in earlier versions of the architecture it was the top two
bits,
not four, but maybe I misremember.
>> Maybe you want to call it physical_address_mask or similar?
>
> PAM - doesn't sound bad :).
And miraculously nothing in the Power arch uses that acronym yet! But I
would spell it out if I were you, acronyms are confusing.
Segher
^ permalink raw reply
* machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-29 7:59 UTC (permalink / raw)
To: ppcdev
I'm porting a mpc870 board to the powerpc arch. The base is the
adder-875 board. My first try to boot the cuImage.my870 is
experiencing a machine check. And I have no clue where to look. Any
help?
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 747319 Bytes = 729.8 kB
Load Address: 00400000
Entry Point: 004004d4
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Bus Fault @ 0x00404c40, fixup 0x00000000
Machine check in kernel mode.
Caused by (from msr): regs 07d1cb80 Unknown values in msr
NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001
MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00404D50 07D1CC70 00000000 00000004 007FFF0C 00000001 0040AAB8 726F6F74
GPR08: 3D2F6465 0059D958 FF0009C0 0059DDDC FF003C00 1014BAC4 07FFF000 00000001
GPR16: 007FFF0D 004004D4 00000001 007FFF00 07FF9D78 FFFFFFFF 00000000 07D5D2A0
GPR24: 007FFEC0 00800000 00000000 00000000 00000000 0059D958 004129BC 00000000
Call backtrace:
machine check
Thanks alot,
-Shawn.
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Alexander Graf @ 2010-06-29 8:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <1550A5F0-3A22-48ED-8251-96328E2FEAE3@kernel.crashing.org>
On 29.06.2010, at 09:52, Segher Boessenkool wrote:
>>>>> Also, it seems you construct the physical address by masking out =
bits from
>>>>> the effective address. Most implementations will trap or machine =
check if
>>>>> you address outside of physical address space, instead.
>>>>=20
>>>> Well the only case where I remember to have hit a real RMO case is =
on the PS3 - that issues a data/instruction storage interrupt when =
accessing anything > 8MB in real mode.
>>>>=20
>>>> So I'd argue this is heavily implementation specific.
>>>=20
>>> It is. So what is the behaviour you want to implement?
>>=20
>> The one below.
>=20
> I'm sorry, I lost it. "Below"?
Well, the ones a few lines below :).
>=20
>>>> Apart from that what I'm trying to cover is that on ppc64 accessing =
0xc0000000000000 in real mode gets you 0x0. Is there a better name for =
this?
>>>=20
>>> (You missed two zeroes).
>>> In hypervisor real mode, the top few bits are magic. They are used =
for e.g.
>>> enabling hypervisor offset real mode.
>>> In supervisor real mode, those bits are ignored (and all other bits =
that do
>>> not correspond to physical address lines may also be ignored).
>>=20
>> So which bits exactly are reserved? I couldn't find a reference to =
that part.
>=20
> If by "reserved" you mean "cannot be used for addressing", it's the =
top four
> bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 =
document.
> Implementations are allowed to ignore more bits than that.
>=20
> I believe in earlier versions of the architecture it was the top two =
bits,
> not four, but maybe I misremember.
Ah, nice. So that part is implementation specific too. Awesome ;).
>=20
>>> Maybe you want to call it physical_address_mask or similar?
>>=20
>> PAM - doesn't sound bad :).
>=20
> And miraculously nothing in the Power arch uses that acronym yet! But =
I
> would spell it out if I were you, acronyms are confusing.
Well, the bad thing about not using acronyms here is that I'll run out =
of the 80 character limit pretty soon. And that means line wraps and =
more confusingness when reading the code.
Alex
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Joakim Tjernlund @ 2010-06-29 8:06 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinA2ghLxBU41aFAsLM1oXQ8HMASx1eQMDVvi56n@mail.gmail.com>
> From: Shawn Jin <shawnxjin@gmail.com>
>
> I'm porting a mpc870 board to the powerpc arch. The base is the
> adder-875 board. My first try to boot the cuImage.my870 is
> experiencing a machine check. And I have no clue where to look. Any
> help?
>
> => bootm 1000000
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.33.5
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 747319 Bytes = 729.8 kB
> Load Address: 00400000
> Entry Point: 004004d4
Load and Entry Point should probably be 0
Jocke
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-29 8:37 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: ppcdev
In-Reply-To: <OF0E653CF5.2ED4C3A3-ONC1257751.002C6D6E-C1257751.002C903E@transmode.se>
>> =3D> bootm 1000000
>> ## Booting image at 01000000 ...
>> =A0 =A0Image Name: =A0 Linux-2.6.33.5
>> =A0 =A0Image Type: =A0 PowerPC Linux Kernel Image (gzip compressed)
>> =A0 =A0Data Size: =A0 =A0747319 Bytes =3D 729.8 kB
>> =A0 =A0Load Address: 00400000
>> =A0 =A0Entry Point: =A0004004d4
>
> Load and Entry Point should probably be 0
But the cuImage.adder875-uboot image also has the same load address as
mine and the entry point is 0x4004d8. Also cuImage.mpc885ads has the
same load address and entry point as cuImage.adder875-uboot. So I
don't suspect them.
All right. I built a uImage for mpc885ads and the uImage's load
address and entry point are both 0. So this is because I'm using
cuImage instead of uImage.
Thanks Joake, anyway.
-Shawn.
^ permalink raw reply
* [PATCH] powerpc: disable SPARSE_IRQ by default
From: Li Yang @ 2010-06-29 9:32 UTC (permalink / raw)
To: benh, linuxppc-dev
The SPARSE_IRQ considerably adds overhead to critical path of IRQ
handling. However it doesn't benefit much in space for most systems with
limited IRQ_NR. Should be disabled unless really necessary.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..6506bf4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -400,7 +400,7 @@ config IRQ_ALL_CPUS
config SPARSE_IRQ
bool "Support sparse irq numbering"
- default y
+ default n
help
This enables support for sparse irqs. This is useful for distro
kernels that want to define a high CONFIG_NR_CPUS value but still
@@ -409,7 +409,7 @@ config SPARSE_IRQ
( Sparse IRQs can also be beneficial on NUMA boxes, as they spread
out the irq_desc[] array in a more NUMA-friendly way. )
- If you don't know what to do here, say Y.
+ If you don't know what to do here, say N.
config NUMA
bool "NUMA support"
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Alexander Graf @ 2010-06-29 9:54 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C274028.7020105@redhat.com>
Avi Kivity wrote:
> On 06/26/2010 02:24 AM, Alexander Graf wrote:
>> For transparent variable sharing between the hypervisor and guest, I
>> introduce
>> a shared page. This shared page will contain all the registers the
>> guest can
>> read and write safely without exiting guest context.
>>
>> This patch only implements the stubs required for the basic structure
>> of the
>> shared page. The actual register moving follows.
>>
>>
>> @@ -123,8 +123,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto free_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_vcpu;
>> +
>> return vcpu;
>>
>> +uninit_vcpu:
>> + kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> out:
>> @@ -135,6 +141,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> }
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 884d4a5..ba79b35 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -1247,6 +1247,10 @@ struct kvm_vcpu
>> *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
>> if (err)
>> goto free_shadow_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_vcpu;
>> +
>> vcpu->arch.host_retip = kvm_return_point;
>> vcpu->arch.host_msr = mfmsr();
>> #ifdef CONFIG_PPC_BOOK3S_64
>> @@ -1277,6 +1281,8 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>>
>> return vcpu;
>>
>> +uninit_vcpu:
>> + kvm_vcpu_uninit(vcpu);
>> free_shadow_vcpu:
>> kfree(vcpu_book3s->shadow_vcpu);
>> free_vcpu:
>> @@ -1289,6 +1295,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kfree(vcpu_book3s->shadow_vcpu);
>> vfree(vcpu_book3s);
>> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
>> index e8a00b0..71750f2 100644
>> --- a/arch/powerpc/kvm/e500.c
>> +++ b/arch/powerpc/kvm/e500.c
>> @@ -117,8 +117,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto uninit_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_tlb;
>> +
>> return vcpu;
>>
>> +uninit_tlb:
>> + kvmppc_e500_tlb_uninit(vcpu_e500);
>> uninit_vcpu:
>> kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> @@ -131,6 +137,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvmppc_e500_tlb_uninit(vcpu_e500);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
>>
>
> Code repeats 3x. Share please.
Looking at this again, I could combine the 3 lines of init code into 3
lines of code that do a generic function call and then error checking.
And I could convert the one free_page line with one function call that
would free the page. Is there a real gain behind this?
Alex
^ permalink raw reply
* Re: [PATCH 1/5] microblaze: turn CONFIG_OF into a select
From: Michal Simek @ 2010-06-29 9:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: microblaze-uclinux, David Miller, Paul Mackerras, sparclinux,
linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629124200.20ca24b7.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> so that we can make CONFIG_OF global and remove it from
> the architecture Kconfig files later.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/Kconfig | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 76818f9..2b37820 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -17,6 +17,8 @@ config MICROBLAZE
> select HAVE_DMA_ATTRS
> select HAVE_DMA_API_DEBUG
> select TRACING_SUPPORT
> + select OF
> + select OF_FLATTREE
>
> config SWAP
> def_bool n
> @@ -125,8 +127,7 @@ config CMDLINE_FORCE
> override those passed by the boot loader.
>
> config OF
> - def_bool y
> - select OF_FLATTREE
> + bool
>
> config PROC_DEVICETREE
> bool "Support for device tree in /proc"
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 5/5] of: remove architecture CONFIG_OF definitions
From: Michal Simek @ 2010-06-29 9:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: microblaze-uclinux, David Miller, Paul Mackerras, sparclinux,
linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629124701.f879c55c.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> now that CONFIG_OF is defined globally
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/Kconfig | 3 ---
> arch/powerpc/Kconfig | 3 ---
> arch/sparc/Kconfig | 3 ---
> 3 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 2b37820..1a8f682 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -126,9 +126,6 @@ config CMDLINE_FORCE
> Set this to have arguments from the default kernel command string
> override those passed by the boot loader.
>
> -config OF
> - bool
> -
> config PROC_DEVICETREE
> bool "Support for device tree in /proc"
> depends on PROC_FS
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 3697231..402f4c0 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -174,9 +174,6 @@ config ARCH_MAY_HAVE_PC_FDC
> config PPC_OF
> def_bool y
>
> -config OF
> - bool
> -
> config PPC_UDBG_16550
> bool
> default n
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index d02e8ac..13a9f2f 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -149,9 +149,6 @@ config GENERIC_GPIO
> config ARCH_NO_VIRT_TO_BUS
> def_bool y
>
> -config OF
> - bool
> -
> config ARCH_SUPPORTS_DEBUG_PAGEALLOC
> def_bool y if SPARC64
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Avi Kivity @ 2010-06-29 10:55 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29C2E1.4000706@suse.de>
On 06/29/2010 12:54 PM, Alexander Graf wrote:
>
>> Code repeats 3x. Share please.
>>
> Looking at this again, I could combine the 3 lines of init code into 3
> lines of code that do a generic function call and then error checking.
> And I could convert the one free_page line with one function call that
> would free the page. Is there a real gain behind this?
>
>
Looks marginal, yes. It will help if initialization is expanded later,
but currently it doesn't help much.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* RE: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Rupjyoti Sarmah @ 2010-06-29 12:20 UTC (permalink / raw)
To: Marek Vasut, Rupjyoti Sarmah
Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
Hi,
Thanks for your feedback. I submitted an updated version of this patch
later.
I tried to limit the lines within 80 characters.
Regards,
Rup
-----Original Message-----
From: Marek Vasut [mailto:marek.vasut@gmail.com]
Sent: Tuesday, June 29, 2010 7:04 AM
To: Rupjyoti Sarmah
Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
jgarzik@pobox.com; sr@denx.de; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
Dne P=C3=A1 4. =C4=8Dervna 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>
--SNIP--
> + dev_err(ap->dev, "%s: Command not pending cmd_issued=3D%d "
> + "(tag=3D%d) DMA NOT started\n", __func__,
> + hsdevp->cmd_issued[tag], tag);
Just a nitpick, but don't break strings if possible.
^ permalink raw reply
* Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Anton Vorontsov @ 2010-06-29 12:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linuxppc-dev, Rupjyoti Sarmah, linux-kernel, linux-ide, sr,
jgarzik
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
On Tue, Jun 29, 2010 at 03:33:50AM +0200, Marek Vasut wrote:
> Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> > This patch enables the on-chip DWC SATA controller of the AppliedMicro
> > processor 460EX.
> >
> > Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> > Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
> >
>
> --SNIP--
>
> > + dev_err(ap->dev, "%s: Command not pending cmd_issued=%d "
> > + "(tag=%d) DMA NOT started\n", __func__,
> > + hsdevp->cmd_issued[tag], tag);
>
> Just a nitpick, but don't break strings if possible.
Note that in this particular case breaking strings was OK, and
was actually done in a clever manner.
That is, I doubt that anyone grep for error messages with
regexps, so grep "Command not pending" or grep "DMA NOT started"
would work.
This makes the code more readable (literally, because you don't
have to scroll to see dev_err's arguments) without sacrificing
grep'ability.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 12:56 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C286770.6010204@redhat.com>
Avi Kivity wrote:
> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>> +}
>>>>
>>>>
>>> Still with the wierd coding style?
>>>
>> Not sure what's going on there. My editor displays it normally. Weird.
>>
>
> Try hitting 'save'.
hexdump -C on the respective section in the exact patch file I submitted
above shows:
00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
hash_64(eadd|
00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r >>
PTE_SIZE, H|
Maybe your mail client breaks it?
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox