* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-13 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, microblaze-uclinux, devicetree-discuss,
Olof Johansson, Mitch Bradley, Dan Malek, Jeremy Kerr
In-Reply-To: <1276383132.1962.195.camel@pasglop>
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote:
>
>> I'm certainly going to try keeping OFW alive. =A0On the x86 OLPC machine=
s,
>> the ability to
>> dive into OFW via a SysRq key combo was very helpful for debugging some
>> difficult
>> problems. =A0The team has asked me to support the feature on ARM.
>
> Oh well, if you can and can convince the ARM kernel folks to do the
> necessary changes ... :-)
What is needed to keep OFW alive? I've got no problem with doing so
if it isn't invasive, and as long as the same boot entry interface can
be used.
> One thing tho, you will only benefit from the whole infrastructure we
> have created accross platforms in linux if the device-tree is "sucked"
> into linux at boot. IE. Linux will not do constant accesses to OF for
> the DT. Even sparc converted to that now.
>
> That means that if your device-tree has a dynamic nature, we'll need to
> come up with a way to inform the kernel of changes in it so it can
> update it's copy accordingly.
What is the use-case for having a dynamic device tree? I can see
keeping OFW alive being useful for some debug facilities, but once the
kernel has started, I'm really not interested in relying on firmware
to manage the hardware. (but then again it's no secret that I'm
suspicious of anything that depends on runtime interaction with
firmware).
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc: Fix mpic_resume on early G5 macs
From: Alastair Bridgewater @ 2010-06-13 1:36 UTC (permalink / raw)
To: linuxppc-dev
mpic_resume() on G5 macs blindly dereferences mpic->fixups, but
it may legitimately be NULL (as on PowerMac7,2). Add an explicit
check.
This fixes suspend-to-disk with one processor (maxcpus=1) for me.
Signed-off-by: Alastair Bridgewater <alastair.bridgewater@gmail.com>
---
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 4fd57ab..28668ba 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1666,7 +1666,7 @@ static int mpic_resume(struct sys_device *dev)
mpic->save_data[i].dest);
#ifdef CONFIG_MPIC_U3_HT_IRQS
- {
+ if (mpic->fixups) {
struct mpic_irq_fixup *fixup = &mpic->fixups[i];
if (fixup->base) {
^ permalink raw reply related
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-12 23:09 UTC (permalink / raw)
To: Olof Johansson
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Mitch Bradley, Dan Malek, Jeremy Kerr
In-Reply-To: <20100612221554.GA17876@lixom.net>
On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Jun 12, 2010 at 12:53:59AM -0600, Grant Likely wrote:
>
>> I also changed the property in the cpu nodes from model to compatible
>> so that the exact CPU version can be specified. =A0This isn't actually
>> in any spec anywhere, but I need something to properly identify the
>> different ARM cores.
>
> I don't see why this has to be in the device tree. It's not there on PPC.
> The exact CPU version is found through the PVR register on PPC, ARM also
> has cpu version and feature registers for runtime probing.
I had been told that they runtime registers weren't reliable. If I'm
misinformed, then yes the compatible value can be dropped from the cpu
nodes.
g.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 22:52 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <4C13B618.1030006@firmworks.com>
On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote:
> I'm certainly going to try keeping OFW alive. On the x86 OLPC machines,
> the ability to
> dive into OFW via a SysRq key combo was very helpful for debugging some
> difficult
> problems. The team has asked me to support the feature on ARM.
Oh well, if you can and can convince the ARM kernel folks to do the
necessary changes ... :-)
One thing tho, you will only benefit from the whole infrastructure we
have created accross platforms in linux if the device-tree is "sucked"
into linux at boot. IE. Linux will not do constant accesses to OF for
the DT. Even sparc converted to that now.
That means that if your device-tree has a dynamic nature, we'll need to
come up with a way to inform the kernel of changes in it so it can
update it's copy accordingly.
We also don't have much mechanisms within Linux to notify users that
things have changed either. It only really happens on IBM pseries for
hotplug, which uses a private notifier.
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Olof Johansson @ 2010-06-12 22:15 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Mitch Bradley, Dan Malek, Jeremy Kerr
In-Reply-To: <AANLkTilv6TtPZs0DAwd8JlSV_J3VvMsvtVVOOeQauOIn@mail.gmail.com>
On Sat, Jun 12, 2010 at 12:53:59AM -0600, Grant Likely wrote:
> I also changed the property in the cpu nodes from model to compatible
> so that the exact CPU version can be specified. This isn't actually
> in any spec anywhere, but I need something to properly identify the
> different ARM cores.
I don't see why this has to be in the device tree. It's not there on PPC.
The exact CPU version is found through the PVR register on PPC, ARM also
has cpu version and feature registers for runtime probing.
-Olof
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-12 18:19 UTC (permalink / raw)
To: stephan; +Cc: linuxppc-dev
In-Reply-To: <4C13C4D9.2030108@gatzka.org>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
That would be great. Thank you.
On 12 Jun 2010 11:44, "Stephan Gatzka" <stephan@gatzka.org> wrote:
Hi Grant,
> I've been doing a bit of work on some introductory level documentation
> of the flattened device...
this looks good. Maybe an example of a complete host/PCI bridge might be
helpful. Probably I can write something during the next week.
Regards,
Stephan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 915 bytes --]
^ permalink raw reply
* Re: Request review of device tree documentation
From: Stephan Gatzka @ 2010-06-12 17:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hi Grant,
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can find it here:
>
> http://devicetree.org/Device_Tree_Usage
>
> Thanks,
> g.
>
this looks good. Maybe an example of a complete host/PCI bridge might be
helpful. Probably I can write something during the next week.
Regards,
Stephan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3332 bytes --]
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-12 16:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <1276339684.1962.186.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote:
>
>> On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
>>
>>> It seems that many of the differences at the CPU level can be determined
>>> by looking at "coprocessor" registers. For what purpose(s) do we need
>>> to identify the core? That will inform our choice of a core ID schema.
>>>
>> The primary thing I see would be architecture version compliance,
>> though this is better carried additionally via a binary field in
>> the header or a GPR at the entry point, to help the initial asm
>> code to setup the MMU etc... before getting into C code.
>>
>
> Also, if you're going to revive a "real" OF port to ARM (with client
> interface etc...), should we start considering moving some of powerpc's
> prom_init.c to a generic place ?
>
> IE. prom_init is a trampoline that uses the client interface to
> essentially create a flatten device-tree and enter the kernel via the
> common "epapr" style entry point.
>
> The main drawback is that it doesn't allow to keep OF alive along with
> the OS, but then, only sparc does that successfully and I'm not sure
> it's something that would be practical to do on ARM either.
>
I'm certainly going to try keeping OFW alive. On the x86 OLPC machines,
the ability to
dive into OFW via a SysRq key combo was very helpful for debugging some
difficult
problems. The team has asked me to support the feature on ARM.
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: rtas_flash needs to use rtas_data_buf
From: Anton Blanchard @ 2010-06-12 13:48 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <20100610-rtas-flash@mdm.bga.com>
From: Milton Miller <miltonm@us.ibm.com>
When trying to flash a machine via the update_flash command, Anton received the
following error:
Restarting system.
FLASH: kernel bug...flash list header addr above 4GB
The code in question has a comment that the flash list should be in
the kernel data and therefore under 4GB:
/* NOTE: the "first" block list is a global var with no data
* blocks in the kernel data segment. We do this because
* we want to ensure this block_list addr is under 4GB.
*/
Unfortunately the Kconfig option is marked tristate which means the variable
may not be in the kernel data and could be above 4GB.
Instead of relying on the data segment being below 4GB, use the static
data buffer allocated by the kernel for use by rtas. Since we don't
use the header struct directly anymore, convert it to a simple pointer.
Reported-By: Anton Blanchard <anton@samba.org>
Signed-Off-By: Milton Miller <miltonm@bga.com
Tested-By: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/rtas_flash.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/rtas_flash.c 2010-05-05 16:17:00.883456148 +1000
+++ powerpc.git/arch/powerpc/kernel/rtas_flash.c 2010-06-12 23:44:25.973458269 +1000
@@ -94,12 +94,8 @@ struct flash_block_list {
struct flash_block_list *next;
struct flash_block blocks[FLASH_BLOCKS_PER_NODE];
};
-struct flash_block_list_header { /* just the header of flash_block_list */
- unsigned long num_blocks;
- struct flash_block_list *next;
-};
-static struct flash_block_list_header rtas_firmware_flash_list = {0, NULL};
+static struct flash_block_list *rtas_firmware_flash_list;
/* Use slab cache to guarantee 4k alignment */
static struct kmem_cache *flash_block_cache = NULL;
@@ -108,13 +104,14 @@ static struct kmem_cache *flash_block_ca
/* Local copy of the flash block list.
* We only allow one open of the flash proc file and create this
- * list as we go. This list will be put in the
- * rtas_firmware_flash_list var once it is fully read.
+ * list as we go. The rtas_firmware_flash_list varable will be
+ * set once the data is fully read.
*
* For convenience as we build the list we use virtual addrs,
* we do not fill in the version number, and the length field
* is treated as the number of entries currently in the block
- * (i.e. not a byte count). This is all fixed on release.
+ * (i.e. not a byte count). This is all fixed when calling
+ * the flash routine.
*/
/* Status int must be first member of struct */
@@ -201,16 +198,16 @@ static int rtas_flash_release(struct ino
if (uf->flist) {
/* File was opened in write mode for a new flash attempt */
/* Clear saved list */
- if (rtas_firmware_flash_list.next) {
- free_flash_list(rtas_firmware_flash_list.next);
- rtas_firmware_flash_list.next = NULL;
+ if (rtas_firmware_flash_list) {
+ free_flash_list(rtas_firmware_flash_list);
+ rtas_firmware_flash_list = NULL;
}
if (uf->status != FLASH_AUTH)
uf->status = flash_list_valid(uf->flist);
if (uf->status == FLASH_IMG_READY)
- rtas_firmware_flash_list.next = uf->flist;
+ rtas_firmware_flash_list = uf->flist;
else
free_flash_list(uf->flist);
@@ -593,7 +590,7 @@ static void rtas_flash_firmware(int rebo
unsigned long rtas_block_list;
int i, status, update_token;
- if (rtas_firmware_flash_list.next == NULL)
+ if (rtas_firmware_flash_list == NULL)
return; /* nothing to do */
if (reboot_type != SYS_RESTART) {
@@ -610,20 +607,25 @@ static void rtas_flash_firmware(int rebo
return;
}
- /* NOTE: the "first" block list is a global var with no data
- * blocks in the kernel data segment. We do this because
- * we want to ensure this block_list addr is under 4GB.
+ /*
+ * NOTE: the "first" block must be under 4GB, so we create
+ * an entry with no data blocks in the reserved buffer in
+ * the kernel data segment.
*/
- rtas_firmware_flash_list.num_blocks = 0;
- flist = (struct flash_block_list *)&rtas_firmware_flash_list;
+ spin_lock(&rtas_data_buf_lock);
+ flist = (struct flash_block_list *)&rtas_data_buf[0];
+ flist->num_blocks = 0;
+ flist->next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr above 4GB\n");
+ spin_unlock(&rtas_data_buf_lock);
return;
}
printk(KERN_ALERT "FLASH: preparing saved firmware image for flash\n");
/* Update the block_list in place. */
+ rtas_firmware_flash_list = NULL; /* too hard to backout on error */
image_size = 0;
for (f = flist; f; f = next) {
/* Translate data addrs to absolute */
@@ -664,6 +666,7 @@ static void rtas_flash_firmware(int rebo
printk(KERN_ALERT "FLASH: unknown flash return code %d\n", status);
break;
}
+ spin_unlock(&rtas_data_buf_lock);
}
static void remove_flash_pde(struct proc_dir_entry *dp)
^ permalink raw reply
* Re: [PATCH] powerpc: rtas_flash cannot be a module
From: Anton Blanchard @ 2010-06-12 13:46 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <20100610-reply@mdm.bga.com>
Hi,
> So we should use that rtas_data_buf with its lock ...
>
> Oh look, the driver already uses that buffer for the call to verify_flash
>
> untested patch to follow
Thanks, it built and tested OK with the following patch. Will send a
complete patch with these changes in a minute.
Anton
--- build/arch/powerpc/kernel/rtas_flash.c~ 2010-06-12 09:06:43.000000000 -0400
+++ build/arch/powerpc/kernel/rtas_flash.c 2010-06-12 09:08:30.000000000 -0400
@@ -613,9 +613,9 @@
* the kernel data segment.
*/
spin_lock(&rtas_data_buf_lock);
- flist = (struct rtas_flash_list *)&rtas_data_buf[0];
- flist.num_blocks = 0;
- flist.next = rtas_firmware_flash_list;
+ flist = (struct flash_block_list *)&rtas_data_buf[0];
+ flist->num_blocks = 0;
+ flist->next = rtas_firmware_flash_list;
rtas_block_list = virt_to_abs(flist);
if (rtas_block_list >= 4UL*1024*1024*1024) {
printk(KERN_ALERT "FLASH: kernel bug...flash list header addr above 4GB\n");
^ permalink raw reply
* Re: [PATCH] powerpc: fix obsolete device tree code for the UPM NAND driver.
From: Anatolij Gustschin @ 2010-06-12 12:56 UTC (permalink / raw)
To: Richard Cochran; +Cc: linuxppc-dev
In-Reply-To: <20100612123943.GA1982@riccoc20.at.omicron.at>
On Sat, 12 Jun 2010 14:39:43 +0200
Richard Cochran <richardcochran@gmail.com> wrote:
> Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
> This driver was apparently overlooked in the processes.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> ---
> drivers/mtd/nand/fsl_upm.c | 18 ++++++++++--------
> 1 files changed, 10 insertions(+), 8 deletions(-)
This is already fixed in 2.6.35-rc2, please update your tree.
^ permalink raw reply
* [PATCH] powerpc: fix obsolete device tree code for the UPM NAND driver.
From: Richard Cochran @ 2010-06-12 12:39 UTC (permalink / raw)
To: linuxppc-dev
Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
This driver was apparently overlooked in the processes.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/mtd/nand/fsl_upm.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 00aea6f..81ec87a 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -232,7 +232,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
if (!fun)
return -ENOMEM;
- ret = of_address_to_resource(ofdev->node, 0, &io_res);
+ ret = of_address_to_resource(ofdev->dev.of_node, 0, &io_res);
if (ret) {
dev_err(&ofdev->dev, "can't get IO base\n");
goto err1;
@@ -244,7 +244,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
goto err1;
}
- prop = of_get_property(ofdev->node, "fsl,upm-addr-offset", &size);
+ prop = of_get_property(ofdev->dev.of_node,
+ "fsl,upm-addr-offset", &size);
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM address offset\n");
ret = -EINVAL;
@@ -252,7 +253,8 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_addr_offset = *prop;
- prop = of_get_property(ofdev->node, "fsl,upm-cmd-offset", &size);
+ prop = of_get_property(ofdev->dev.of_node,
+ "fsl,upm-cmd-offset", &size);
if (!prop || size != sizeof(uint32_t)) {
dev_err(&ofdev->dev, "can't get UPM command offset\n");
ret = -EINVAL;
@@ -260,7 +262,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
fun->upm_cmd_offset = *prop;
- prop = of_get_property(ofdev->node,
+ prop = of_get_property(ofdev->dev.of_node,
"fsl,upm-addr-line-cs-offsets", &size);
if (prop && (size / sizeof(uint32_t)) > 0) {
fun->mchip_count = size / sizeof(uint32_t);
@@ -276,7 +278,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
for (i = 0; i < fun->mchip_count; i++) {
fun->rnb_gpio[i] = -1;
- rnb_gpio = of_get_gpio(ofdev->node, i);
+ rnb_gpio = of_get_gpio(ofdev->dev.of_node, i);
if (rnb_gpio >= 0) {
ret = gpio_request(rnb_gpio, dev_name(&ofdev->dev));
if (ret) {
@@ -292,13 +294,13 @@ static int __devinit fun_probe(struct of_device *ofdev,
}
}
- prop = of_get_property(ofdev->node, "chip-delay", NULL);
+ prop = of_get_property(ofdev->dev.of_node, "chip-delay", NULL);
if (prop)
fun->chip_delay = *prop;
else
fun->chip_delay = 50;
- prop = of_get_property(ofdev->node, "fsl,upm-wait-flags", &size);
+ prop = of_get_property(ofdev->dev.of_node, "fsl,upm-wait-flags", &size);
if (prop && size == sizeof(uint32_t))
fun->wait_flags = *prop;
else
@@ -315,7 +317,7 @@ static int __devinit fun_probe(struct of_device *ofdev,
fun->dev = &ofdev->dev;
fun->last_ctrl = NAND_CLE;
- ret = fun_chip_init(fun, ofdev->node, &io_res);
+ ret = fun_chip_init(fun, ofdev->dev.of_node, &io_res);
if (ret)
goto err2;
--
1.6.3.3
^ permalink raw reply related
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 10:48 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <1276339529.1962.184.camel@pasglop>
On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
> > It seems that many of the differences at the CPU level can be determined
> > by looking at "coprocessor" registers. For what purpose(s) do we need
> > to identify the core? That will inform our choice of a core ID schema.
>
> The primary thing I see would be architecture version compliance,
> though this is better carried additionally via a binary field in
> the header or a GPR at the entry point, to help the initial asm
> code to setup the MMU etc... before getting into C code.
Also, if you're going to revive a "real" OF port to ARM (with client
interface etc...), should we start considering moving some of powerpc's
prom_init.c to a generic place ?
IE. prom_init is a trampoline that uses the client interface to
essentially create a flatten device-tree and enter the kernel via the
common "epapr" style entry point.
The main drawback is that it doesn't allow to keep OF alive along with
the OS, but then, only sparc does that successfully and I'm not sure
it's something that would be practical to do on ARM either.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 10:45 UTC (permalink / raw)
To: Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <4C13430B.5000907@firmworks.com>
On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
> It seems that many of the differences at the CPU level can be determined
> by looking at "coprocessor" registers. For what purpose(s) do we need
> to identify the core? That will inform our choice of a core ID schema.
The primary thing I see would be architecture version compliance,
though this is better carried additionally via a binary field in
the header or a GPR at the entry point, to help the initial asm
code to setup the MMU etc... before getting into C code.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-12 8:19 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Dan Malek, Jeremy Kerr
In-Reply-To: <AANLkTilv6TtPZs0DAwd8JlSV_J3VvMsvtVVOOeQauOIn@mail.gmail.com>
Grant Likely wrote:
>
> I also changed the property in the cpu nodes from model to compatible
> so that the exact CPU version can be specified. This isn't actually
> in any spec anywhere, but I need something to properly identify the
> different ARM cores.
>
> Mitch, I know you were working on a draft ARM binding a while ago,
> have you resurrected it at all?
As it turns out, today I re-began ARM OFW work in earnest, after a
hiatus of something like 10 years.
I haven't thought much about a binding yet. I'm still getting my head
around the current state of the ARM art.
> How do you think the core should be identified?
>
When I was last working on ARM, few ARM devices had enough resources to
run a general purpose OS. To first approximation, StrongARM was the
only game in town - so there wasn't much need to address the
identification question.
It seems that many of the differences at the CPU level can be determined
by looking at "coprocessor" registers. For what purpose(s) do we need
to identify the core? That will inform our choice of a core ID schema.
> Cheers,
> g.
>
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Grant Likely @ 2010-06-12 6:53 UTC (permalink / raw)
To: Dan Malek, Mitch Bradley
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com>
On Fri, Jun 11, 2010 at 5:47 PM, Dan Malek <ppc6dev@digitaldans.com> wrote:
>
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
>> I've been doing a bit of work on some introductory level documentation
>> of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously, I never understood this well and this is a
> great document.
Hey, thanks! That's a fantastic compliment!
> I have one source of confusion. =A0Your first Initial structure
> example uses 'compatible' to describe the machine, the
> paragraph below then mentions the 'model' property,
> and all subsequent examples use model.
>
> Does this mean if I use just the single line in the dts,
> using 'compatible' implies the ARM machine ID? =A0If I
> have more description I use 'model'?
No, that is just a reflection of a late change I made to the document.
It should be compatible all the way down. I was trying to keep
things simple because on a lot of boards both compatible and model
properties will exist in the root node. I started writing with model,
and then changed it last minute without fixing everything up which is
why the document was confusing.
I've fixed it now if you want to take a look.
I also changed the property in the cpu nodes from model to compatible
so that the exact CPU version can be specified. This isn't actually
in any spec anywhere, but I need something to properly identify the
different ARM cores.
Mitch, I know you were working on a draft ARM binding a while ago,
have you resurrected it at all? How do you think the core should be
identified?
Cheers,
g.
^ permalink raw reply
* Re: [PATCH 1/2] mtd: m25p80: Rework probing/JEDEC code
From: Barry Song @ 2010-06-12 6:27 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, linux-kernel, linuxppc-dev,
linux-mtd, Andrew Morton, David Woodhouse
In-Reply-To: <20090818214622.GA22651@oksana.dev.rtsoft.ru>
T24gV2VkLCBBdWcgMTksIDIwMDkgYXQgNTo0NiBBTSwgQW50b24gVm9yb250c292Cjxhdm9yb250
c292QHJ1Lm12aXN0YS5jb20+IHdyb3RlOgo+Cj4gUHJldmlvc2x5IHRoZSBkcml2ZXIgYWx3YXlz
IHRyaWVkIEpFREVDIHByb2JpbmcsIGFzc3VtaW5nIHRoYXQgbm9uLUpFREVDCj4gY2hpcHMgd2ls
bCByZXR1cm4gJzAnLiBCdXQgdHJ1bHkgbm9uLUpFREVDIGNoaXBzIChsaWtlIENBVDI1KSB3b24n
dCBkbwo+IHRoYXQsIHRoZWlyIGJlaGF2aW91ciBvbiBSRElEIGNvbW1hbmQgaXMgdW5kZWZpbmVk
LCBzbyB0aGUgZHJpdmVyIHNob3VsZAo+IG5vdCBjYWxsIGplZGVjX3Byb2JlKCkgZm9yIHRoZXNl
IGNoaXBzLgo+Cj4gQWxzbywgYmUgbGVzcyBzdHJpY3Qgb24gZXJyb3IgY29uZGl0aW9ucywgZG9u
J3QgZmFpbCB0byBwcm9iZSBpZiBKRURFQwo+IGZvdW5kIGEgY2hpcCB0aGF0IGlzIGRpZmZlcmVu
dCBmcm9tIHdoYXQgcGxhdGZvcm0gY29kZSB0b2xkLCBpbnN0ZWFkCj4ganVzdCBwcmludCBzb21l
IHdhcm5pbmdzIGFuZCB1c2UgYW4gaW5mb3JtYXRpb24gb2J0YWluZWQgdmlhIEpFREVDLiBJbgpU
aGlzIHBhdGNoIGNhdXNlZCBhIHByb2JsZW06CmV2ZW4gdGhvdWdoIHRoZSBleHRlcm5hbCBmbGFz
aCBkb2Vzbid0IGV4aXN0LCBpdCB3aWxsIHN0aWxsIHBhc3MgdGhlCnByb2JlKCkgYW5kIGJlIHJl
Z2lzdGVycmVkIGludG8ga2VybmVsIGFuZCBnaXZlbiB0aGUgcGFydGl0aW9uIHRhYmxlLgpZb3Ug
bWF5IHJlZmVyIHRvIHRoaXMgYnVnIHJlcG9ydDoKaHR0cDovL2JsYWNrZmluLnVjbGludXgub3Jn
L2dmL3Byb2plY3QvdWNsaW51eC1kaXN0L3RyYWNrZXIvP2FjdGlvbj1UcmFja2VySXRlbUVkaXQm
dHJhY2tlcl9pdGVtX2lkPTU5NzUmc3RhcnQ9MAoKPiB0aGF0IGNhc2Ugd2Ugc2hvdWxkIG5vdCB0
cnVzdCBwYXJ0aXRpb25zIGFueSBsb25nZXIsIGJ1dCB0aGV5IG1pZ2h0IGJlCj4gc3RpbGwgdXNl
ZnVsIChpLmUuIHRoZXkgY291bGQgcHJvdGVjdCBzb21lIHBhcnRzIG9mIHRoZSBjaGlwKS4KPgo+
IFNpZ25lZC1vZmYtYnk6IEFudG9uIFZvcm9udHNvdiA8YXZvcm9udHNvdkBydS5tdmlzdGEuY29t
Pgo+IC0tLQo+IMKgZHJpdmVycy9tdGQvZGV2aWNlcy9tMjVwODAuYyB8IMKgIDY5ICsrKysrKysr
KysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tCj4gwqAxIGZpbGVzIGNoYW5nZWQsIDQw
IGluc2VydGlvbnMoKyksIDI5IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
bXRkL2RldmljZXMvbTI1cDgwLmMgYi9kcml2ZXJzL210ZC9kZXZpY2VzL20yNXA4MC5jCj4gaW5k
ZXggMGQ3NGIzOC4uYjc1ZTMxOSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL210ZC9kZXZpY2VzL20y
NXA4MC5jCj4gKysrIGIvZHJpdmVycy9tdGQvZGV2aWNlcy9tMjVwODAuYwo+IEBAIC01ODEsNiAr
NTgxLDE0IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3Qgc3BpX2RldmljZV9pZCAqX19kZXZpbml0IGpl
ZGVjX3Byb2JlKHN0cnVjdCBzcGlfZGV2aWNlICpzcGkpCj4gwqAgwqAgwqAgwqBqZWRlYyA9IGpl
ZGVjIDw8IDg7Cj4gwqAgwqAgwqAgwqBqZWRlYyB8PSBpZFsyXTsKPgo+ICsgwqAgwqAgwqAgLyoK
PiArIMKgIMKgIMKgIMKgKiBTb21lIGNoaXBzIChsaWtlIE51bW9ueXggTTI1UDgwKSBoYXZlIEpF
REVDIGFuZCBub24tSkVERUMgdmFyaWFudHMsCj4gKyDCoCDCoCDCoCDCoCogd2hpY2ggZGVwZW5k
IG9uIHRlY2hub2xvZ3kgcHJvY2Vzcy4gT2ZmaWNpYWxseSBSRElEIGNvbW1hbmQgZG9lc24ndAo+
ICsgwqAgwqAgwqAgwqAqIGV4aXN0IGZvciBub24tSkVERUMgY2hpcHMsIGJ1dCBmb3IgY29tcGF0
aWJpbGl0eSB0aGV5IHJldHVybiBJRCAwLgo+ICsgwqAgwqAgwqAgwqAqLwo+ICsgwqAgwqAgwqAg
aWYgKGplZGVjID09IDApCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4gTlVMTDsKPiAr
Cj4gwqAgwqAgwqAgwqBleHRfamVkZWMgPSBpZFszXSA8PCA4IHwgaWRbNF07Cj4KPiDCoCDCoCDC
oCDCoGZvciAodG1wID0gMDsgdG1wIDwgQVJSQVlfU0laRShtMjVwX2lkcykgLSAxOyB0bXArKykg
ewo+IEBAIC02MDIsNyArNjEwLDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lk
ICpfX2RldmluaXQgamVkZWNfcHJvYmUoc3RydWN0IHNwaV9kZXZpY2UgKnNwaSkKPiDCoCovCj4g
wqBzdGF0aWMgaW50IF9fZGV2aW5pdCBtMjVwX3Byb2JlKHN0cnVjdCBzcGlfZGV2aWNlICpzcGkp
Cj4gwqB7Cj4gLSDCoCDCoCDCoCBjb25zdCBzdHJ1Y3Qgc3BpX2RldmljZV9pZCDCoCDCoCDCoCpp
ZDsKPiArIMKgIMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lkIMKgIMKgIMKgKmlkID0g
c3BpX2dldF9kZXZpY2VfaWQoc3BpKTsKPiDCoCDCoCDCoCDCoHN0cnVjdCBmbGFzaF9wbGF0Zm9y
bV9kYXRhIMKgIMKgIMKgKmRhdGE7Cj4gwqAgwqAgwqAgwqBzdHJ1Y3QgbTI1cCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCAqZmxhc2g7Cj4gwqAgwqAgwqAgwqBzdHJ1Y3QgZmxhc2hfaW5m
byDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqaW5mbzsKPiBAQCAtNjE1LDQxICs2MjMsNDQgQEAgc3Rh
dGljIGludCBfX2RldmluaXQgbTI1cF9wcm9iZShzdHJ1Y3Qgc3BpX2RldmljZSAqc3BpKQo+IMKg
IMKgIMKgIMKgICovCj4gwqAgwqAgwqAgwqBkYXRhID0gc3BpLT5kZXYucGxhdGZvcm1fZGF0YTsK
PiDCoCDCoCDCoCDCoGlmIChkYXRhICYmIGRhdGEtPnR5cGUpIHsKPiArIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lkICpwbGF0X2lkOwo+ICsKPiDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoGZvciAoaSA9IDA7IGkgPCBBUlJBWV9TSVpFKG0yNXBfaWRzKSAtIDE7
IGkrKykgewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWQgPSAmbTI1cF9p
ZHNbaV07Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmZvID0gKHZvaWQg
KiltMjVwX2lkc1tpXS5kcml2ZXJfZGF0YTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGlmIChzdHJjbXAoZGF0YS0+dHlwZSwgaWQtPm5hbWUpKQo+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgcGxhdF9pZCA9ICZtMjVwX2lkc1tpXTsKPiArIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChzdHJjbXAoZGF0YS0+dHlwZSwgcGxhdF9pZC0+
bmFtZSkpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBj
b250aW51ZTsKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJyZWFrOwo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAvKiB1bnJl
Y29nbml6ZWQgY2hpcD8gKi8KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChpID09IEFSUkFZ
X1NJWkUobTI1cF9pZHMpIC0gMSkgewo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgREVCVUcoTVREX0RFQlVHX0xFVkVMMCwgIiVzOiB1bnJlY29nbml6ZWQgaWQgJXNcbiIsCj4g
LSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCBkZXZfbmFtZSgmc3BpLT5kZXYpLCBkYXRhLT50eXBlKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIGluZm8gPSBOVUxMOwo+IC0KPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IC8qIHJlY29nbml6ZWQ7IGlzIHRoYXQgY2hpcCByZWFsbHkgd2hhdCdzIHRoZXJlPyAqLwo+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfSBlbHNlIGlmIChpbmZvLT5qZWRlY19pZCkgewo+IC0gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWQgPSBqZWRlY19wcm9iZShzcGkpOwo+IC0K
PiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIChpZCAhPSAmbTI1cF9pZHNb
aV0pIHsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRl
dl93YXJuKCZzcGktPmRldiwgImZvdW5kICVzLCBleHBlY3RlZCAlc1xuIiwKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlkID8gaWQtPm5hbWUgOiAiVU5LTk9XTiIsCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtMjVwX2lkc1tp
XS5uYW1lKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IGluZm8gPSBOVUxMOwo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+IC0g
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfQo+IC0gwqAgwqAgwqAgfSBlbHNlIHsKPiAtIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIGlkID0gamVkZWNfcHJvYmUoc3BpKTsKPiAtIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIGlmICghaWQpCj4gLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IHNw
aV9nZXRfZGV2aWNlX2lkKHNwaSk7Cj4gLQo+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5mbyA9
ICh2b2lkICopaWQtPmRyaXZlcl9kYXRhOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWYgKHBs
YXRfaWQpCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IHBsYXRfaWQ7
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbHNlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCBkZXZfd2Fybigmc3BpLT5kZXYsICJ1bnJlY29nbml6ZWQgaWQgJXNcbiIsIGRh
dGEtPnR5cGUpOwo+IMKgIMKgIMKgIMKgfQo+Cj4gLSDCoCDCoCDCoCBpZiAoIWluZm8pCj4gLSDC
oCDCoCDCoCDCoCDCoCDCoCDCoCByZXR1cm4gLUVOT0RFVjsKPiArIMKgIMKgIMKgIGluZm8gPSAo
dm9pZCAqKWlkLT5kcml2ZXJfZGF0YTsKPiArCj4gKyDCoCDCoCDCoCBpZiAoaW5mby0+amVkZWNf
aWQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnN0IHN0cnVjdCBzcGlfZGV2aWNlX2lk
ICpqaWQ7Cj4gKwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgamlkID0gamVkZWNfcHJvYmUoc3Bp
KTsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmICghamlkKSB7Cj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCBkZXZfaW5mbygmc3BpLT5kZXYsICJub24tSkVERUMgdmFyaWFu
dCBvZiAlc1xuIiwKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgaWQtPm5hbWUpOwo+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfSBlbHNlIGlmIChqaWQg
IT0gaWQpIHsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC8qCj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogSkVERUMga25vd3MgYmV0dGVyLCBzbyBv
dmVyd3JpdGUgcGxhdGZvcm0gSUQuIFdlCj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogY2FuJ3QgdHJ1c3QgcGFydGl0aW9ucyBhbnkgbG9uZ2VyLCBidXQgd2UnbGwgbGV0
Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogbXRkIGFwcGx5IHRoZW0g
YW55d2F5LCBzaW5jZSBzb21lIHBhcnRpdGlvbnMgbWF5IGJlCj4gKyDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogbWFya2VkIHJlYWQtb25seSwgYW5kIHdlIGRvbid0IHdhbnQg
dG8gbG9zZSB0aGF0Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCogaW5m
b3JtYXRpb24sIGV2ZW4gaWYgaXQncyBub3QgMTAwJSBhY2N1cmF0ZS4KPiArIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKi8KPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIGRldl93YXJuKCZzcGktPmRldiwgImZvdW5kICVzLCBleHBlY3RlZCAlc1xuIiwKPiAr
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgamlkLT5uYW1l
LCBpZC0+bmFtZSk7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZCA9IGpp
ZDsKPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZm8gPSAodm9pZCAqKWpp
ZC0+ZHJpdmVyX2RhdGE7Cj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCB9Cj4gKyDCoCDCoCDCoCB9
Cj4KPiDCoCDCoCDCoCDCoGZsYXNoID0ga3phbGxvYyhzaXplb2YgKmZsYXNoLCBHRlBfS0VSTkVM
KTsKPiDCoCDCoCDCoCDCoGlmICghZmxhc2gpCj4gLS0KPiAxLjYuMy4zCj4KPiAtLQo+IFRvIHVu
c3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51
eC1rZXJuZWwiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtl
cm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDovL3ZnZXIua2VybmVsLm9y
Zy9tYWpvcmRvbW8taW5mby5odG1sCj4gUGxlYXNlIHJlYWQgdGhlIEZBUSBhdCDCoGh0dHA6Ly93
d3cudHV4Lm9yZy9sa21sLwo=
^ permalink raw reply
* random exception on ppc based board
From: Thirumalai @ 2010-06-12 5:10 UTC (permalink / raw)
To: u-boot, linuxppc-dev
Hi,
I am having a ppc based target on which linux-2.4.20 kernel is running
with u-boot 1.3.4 as boot loader. The target is having MPC7410 as processor
and MPC107 as system controller. Regarding memory it is having 128 MB of ram
and 16 MB of Flash memory. Also the kernel is patched with RTLinux-3.2 for
realtime performance. I am getting a random Program and DSI exception on the
target. Normally the exeption occurs during loading of rtl_time.o. The panic
message is given below.
==================
Using /usr/rtlinux/modules/rtl_time.okernel BUG at page_alloc.c:221!
Oops: Exception in kernel mode, sig: 4
NIP: C0032980 XER: 00000000 LR: C0032980 SP: C7CEDBA0 REGS: c7cedaf0 TRAP:
0700 Not tainted
MSR: 00089032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c7cec000[366] 'exe' Last syscall: 3
last math c7cec000 last altivec 00000000
GPR00: C0032980 C7CEDBA0 C7CEC000 00000020 00000001 00000001 00001137
00000000
GPR08: 00000002 00000000 CD879EC0 C7CEDAB0 CD876108 C0011934 00000000
00000000
GPR16: 00000004 00000001 C002A0E8 C789E840 00009032 07CEDD90 C01A2C70
C01A2C70
GPR24: 00000001 00000000 C016E080 00000000 C79966E0 00000000 C016E0B8
C016E0C4
Call backtrace:
C0032980 C0033020 C0032C4C C0025A18 C0025B58 C0025D8C C000EF88
C0005D48 C03A8B28 C0029B28 C002A258 C003A99C C0005AFC 00000000
0FF15DBC 0FF175DC 0FF09894 10012190 100127D0 100356AC 100352A4
0FEBCF6C 00000000
Oops: kernel access of bad area, sig: 11
NIP: C00326DC XER: 00000000 LR: C0032588 SP: C7CED880 REGS: c7ced7d0 TRAP:
0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 42000000
TASK = c7cec000[366] 'exe' Last syscall: 3
last math c7cec000 last altivec 00000000
GPR00: 00000000 C7CED880 C7CEC000 C7CED888 FFFFFFFF 30026000 C0388250
00000000
GPR08: 00008000 00000000 00155210 00000000 CD876CD4 C0032588 00000000
00000000
GPR16: 00000004 00000001 C002A0E8 C789E840 00009032 C01A2C70 C01A2C70
C016E130
GPR24: C0233024 C0388234 00003E06 00007C0C C016E080 FFFFFFFE C016E0B8
C0388260
Call backtrace:
C003249C C0033398 C0033B18 C00243D8 C0026234 C00246D0 C0027A70
C001326C C00187D4 C0005ED4 C0005F44 C00062B0 C0005D48 C0032980
C0033020 C0032C4C C0025A18 C0025B58 C0025D8C C000EF88 C0005D48
C03A8B28 C0029B28 C002A258 C003A99C C0005AFC 00000000 0FF15DBC
0FF175DC 0FF09894 10012190 100127D0 100356AC
Illegal instruction
========
Sometimes i am getting the following panic message.
===========
Oops: kernel access of bad area, sig: 11
NIP: C0033360 XER: 20000000 LR: C00DE9A8 SP: C016C0D0 REGS: c016c020 TRAP:
0300 Tainted: P
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 03910018, DSISR: 40000000
TASK = c016a480[0] 'swapper' Last syscall: 120
last math c505c000 last altivec 00000000
GPR00: C00DE9A8 C016C0D0 C016A480 03910000 00000000 00000000 C5A469DC
FFFFFFFF
GPR08: 00000001 03910014 00000043 C5A2FE20 2490C022 C0030A04 07FF0D00
00000000
GPR16: 00044008 00000000 00000000 00000000 00001032 00000003 FFFFFFFF
0A050393
GPR24: C5A46980 C5A2F842 00000040 00000000 C5A2F842 C01C0000 C5A46980
00000001
Call backtrace:
00000040 C00DE9A8 C00DE9DC C00DEB28 C01163D4 C01166EC C00F4898
C00F44E4 C00F4AC8 C00F468C C00E3664 C00E3810 C00E397C C001A200
C0007620 CD876CAC C0005D40 C000744C C0007460 C0003918 C01815E0
000035F0
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 180 seconds..
================
How to debug this???
-Thirumalai
^ permalink raw reply
* Re: Request review of device tree documentation
From: Mitch Bradley @ 2010-06-12 4:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: microblaze-uclinux, Dan Malek, devicetree-discuss, Jeremy Kerr,
linuxppc-dev
In-Reply-To: <1276311487.1962.172.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
>
>> Hi Grant.
>>
>> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>>
>>
>>> I've been doing a bit of work on some introductory level documentation
>>> of the flattened device tree.
>>>
>> Wow, I feel empowered to create device trees now :-)
>> Seriously, I never understood this well and this is a
>> great document.
>>
>> I have one source of confusion. Your first Initial structure
>> example uses 'compatible' to describe the machine, the
>> paragraph below then mentions the 'model' property,
>> and all subsequent examples use model.
>>
>> Does this mean if I use just the single line in the dts,
>> using 'compatible' implies the ARM machine ID? If I
>> have more description I use 'model'?
>>
>
> Normally, "compatible" is what is used for code to match,
> and model is more like a user-visible thingy.
>
Indeed, one common use of "model" - at least in the systems I work on -
is to display the name of the machine in a system identification banner
that the user sees.
> It's possible to peek at 'model' tho, in some cases, I've seen the case
> for example where things are -supposed- to be identical from an arch
> point of view, have the same compatible, but later on, a quirk is found
> and a test against model is used to differentiate. But that's something
> to avoid in general. Better off having multiple strings in "compatible"
> then, one more "generic" to have the BSP match against, and one more
> "specific" that can be used if a quirk is needed.
>
> Of course, it doesn't help that all pseries have "chrp" and nothing else
> as compatible :-) But then, both IBM and Apple have been quite lax with
> their (ab)use of the DT.
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
>
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 3:07 UTC (permalink / raw)
To: Grant Likely
Cc: Olof Johansson, microblaze-uclinux, devicetree-discuss,
Jeremy Kerr, linuxppc-dev
In-Reply-To: <1276311610.1962.173.camel@pasglop>
On Sat, 2010-06-12 at 13:00 +1000, Benjamin Herrenschmidt wrote:
>
> Quite nice. Maybe the introduction could use a very quick blurb on
> the
> various data types that dtc supports for properties, and something on
> labels & phandles (references to nodes).
>
> I just flew over it. I'll try to give you a more in depth review
> later.
Oh, yes, btw, Dan is right, you do seem to mixup "model" and
"compatible" all over the place :-)
Maybe a paragraph on the new proposed clock binding that Jeremy is
working would be of use btw.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 3:00 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
On Fri, 2010-06-11 at 16:59 -0600, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can find it here:
>
> http://devicetree.org/Device_Tree_Usage
Quite nice. Maybe the introduction could use a very quick blurb on the
various data types that dtc supports for properties, and something on
labels & phandles (references to nodes).
I just flew over it. I'll try to give you a more in depth review later.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Benjamin Herrenschmidt @ 2010-06-12 2:58 UTC (permalink / raw)
To: Dan Malek
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com>
On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
> > I've been doing a bit of work on some introductory level documentation
> > of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously, I never understood this well and this is a
> great document.
>
> I have one source of confusion. Your first Initial structure
> example uses 'compatible' to describe the machine, the
> paragraph below then mentions the 'model' property,
> and all subsequent examples use model.
>
> Does this mean if I use just the single line in the dts,
> using 'compatible' implies the ARM machine ID? If I
> have more description I use 'model'?
Normally, "compatible" is what is used for code to match,
and model is more like a user-visible thingy.
It's possible to peek at 'model' tho, in some cases, I've seen the case
for example where things are -supposed- to be identical from an arch
point of view, have the same compatible, but later on, a quirk is found
and a test against model is used to differentiate. But that's something
to avoid in general. Better off having multiple strings in "compatible"
then, one more "generic" to have the BSP match against, and one more
"specific" that can be used if a quirk is needed.
Of course, it doesn't help that all pseries have "chrp" and nothing else
as compatible :-) But then, both IBM and Apple have been quite lax with
their (ab)use of the DT.
Cheers,
Ben.
^ permalink raw reply
* Re: Request review of device tree documentation
From: Dan Malek @ 2010-06-11 23:47 UTC (permalink / raw)
To: Grant Likely
Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev,
Olof Johansson, Jeremy Kerr
In-Reply-To: <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
Hi Grant.
On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree.
Wow, I feel empowered to create device trees now :-)
Seriously, I never understood this well and this is a
great document.
I have one source of confusion. Your first Initial structure
example uses 'compatible' to describe the machine, the
paragraph below then mentions the 'model' property,
and all subsequent examples use model.
Does this mean if I use just the single line in the dts,
using 'compatible' implies the ARM machine ID? If I
have more description I use 'model'?
Thanks.
-- Dan
^ permalink raw reply
* Request review of device tree documentation
From: Grant Likely @ 2010-06-11 22:59 UTC (permalink / raw)
To: devicetree-discuss, Jeremy Kerr, John Rigby, linuxppc-dev,
microblaze-uclinux, Olof Johansson
I've been doing a bit of work on some introductory level documentation
of the flattened device tree. I've got a rough copy up on the
devicetree.org wiki, and I could use some feedback. If anyone has
some time to look at it, you can find it here:
http://devicetree.org/Device_Tree_Usage
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2.6.35 & stable (v2)] powerpc: fix logic error in fixup_irqs
From: Johannes Berg @ 2010-06-11 21:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, alastair.bridgewater
In-Reply-To: <1276289756.3918.4.camel@jlt3.sipsolutions.net>
On Fri, 2010-06-11 at 22:55 +0200, Johannes Berg wrote:
> When SPARSE_IRQ is set, irq_to_desc() can
> return NULL. While the code here has a
> check for NULL, it's not really correct.
> Fix it by separating the check for it.
Incidentally, there's another quirk in fixup_irqs():
...
alloc_cpumask_var(&mask, GFP_KERNEL);
...
local_irq_enable();
mdelay(1);
local_irq_disable();
Either it's called with IRQs disabled, in which case it shouldn't do
GFP_KERNEL, or it's called with IRQs enabled, in which case it doesn't
need the local_irq_enable(), no?
johannes
^ 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