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 b
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
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 co
Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
This driver was apparently overlooked in the processes.
Signed-off-by: Richard Cochran
---
drivers/mtd/nand/fsl_upm.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/na
On Sat, 12 Jun 2010 14:39:43 +0200
Richard Cochran wrote:
> Commit 58f9b0b02414062eaff46716bc04b47d7e79add5 removed of_device->node.
> This driver was apparently overlooked in the processes.
>
> Signed-off-by: Richard Cochran
> ---
> drivers/mtd/nand/fsl_upm.c | 18 ++
> 1 fi
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
--
From: Milton Miller
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 therefor
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
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/Devic
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.
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 A
On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson 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. This isn't actually
>> in any spec anywhere, but I n
That would be great. Thank you.
On 12 Jun 2010 11:44, "Stephan Gatzka" 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
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
---
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerp
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
wrote:
> 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
>> dif
Grant Likely wrote:
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
wrote:
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 d
On Sat, 2010-06-12 at 23:07 -0600, Grant Likely wrote:
>
> 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.
Well, no. OF has a well defined "client interface" which is what gets us
in prom_init
On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote:
> Minimally, OFW needs to own some memory that the kernel won't steal.
> OFW on ARM is position-independent, so it can be tucked up at the top of
> memory
> fairly easily.
Amen :-)
> To call back into OFW, the virtual mapping for that m
Benjamin Herrenschmidt wrote:
On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote:
Minimally, OFW needs to own some memory that the kernel won't steal.
OFW on ARM is position-independent, so it can be tucked up at the top of memory
fairly easily.
Amen :-)
To call back into OF
On Sat, Jun 12, 2010 at 05:09:36PM -0600, Grant Likely wrote:
> On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson 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
20 matches
Mail list logo
