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
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, 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
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
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, 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
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
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 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.
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
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
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
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
13 matches
Mail list logo
