On Thu, Aug 05, 2010 at 02:43:25PM +1000, David Gibson wrote:
> On Fri, Jun 11, 2010 at 04:59:46PM -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
On Fri, Jun 11, 2010 at 04:59:46PM -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
On 06/15/10 23:52, M. Warner Losh wrote:
> In message: <4c187013.5000...@firmworks.com>
> Mitch Bradley writes:
> : Mike Rapoport wrote:
> : > Mitch Bradley wrote:
> : >> Mike Rapoport wrote:
> : >>> Mitch Bradley wrote:
> : >>>
> : The second topic is the hypothetical use of OFW
On 06/16/2010 07:39 AM, Nicolas Pitre wrote:
> The cost function _is_ different for the Linux community and decision
> makers at chip vendor companies. I know that for having worked long
> enough at a prominent chip vendor already.
>
> Those vendors want to ship a product and be first on the mar
On Wed, 16 Jun 2010, Mike Rapoport wrote:
> Mitch Bradley wrote:
> > One counterargument, of course, is that "there is a better way". But it is
> > only "better" under a cost function that values things differently than the
> > vendors value them. Were that not so, the vendors would gladly use th
On 16 Jun 2010, at 12:41, Jamie Lokier wrote:
> Mike Rapoport wrote:
>>> Which of course raises the question: How does the Linux community view
>>> such SoC vendors? Are they embraced and eagerly supported, or (either
>>> openly or secretly) viewed as a nuisance? How does the widespread
>>> o
Mike Rapoport wrote:
> >Which of course raises the question: How does the Linux community view
> >such SoC vendors? Are they embraced and eagerly supported, or (either
> >openly or secretly) viewed as a nuisance? How does the widespread
> >objection to something that such vendors "would make
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That
will not happen for several reasons. The opposition to the idea
is widespread
Mitch Bradley wrote:
I'm also objecting the step (b) and, fortunately, it's not yet the
status quo.
Current U-Boot/kernel implementations I've encountered still do not
have OS calls to resident HW access routines. But if such calls would
be allowed, my impression is that SoC vendors would m
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That
will not happen for several reasons. The opposition to the idea
is widespread and deeply held, and t
In message: <4c187013.5000...@firmworks.com>
Mitch Bradley writes:
: Mike Rapoport wrote:
: > Mitch Bradley wrote:
: >> Mike Rapoport wrote:
: >>> Mitch Bradley wrote:
: >>>
: The second topic is the hypothetical use of OFW as a HAL. That will
: not happen for several reasons
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will not
happen for several reasons. The opposition to the idea is widespread
and deeply held, and there are good arguments to support that
opposition. Furthermore, the economic conditions necessary for the
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good argument
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that opp
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that opposition. Furthermore
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that opposition. Furthermore, the economic conditi
On Mon, Jun 14, 2010 at 10:59:20AM -0400, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > [sni]
> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > > firmware, there is no pres
On Mon, Jun 14, 2010 at 03:40:19PM -0400, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Mitch Bradley wrote:
> > Arranging for a JTAG dongle to appear at the customer site, then
> > getting it set up and the necessary software installed and configured
> > on a suitable host system, typically requi
On Sun, Jun 13, 2010 at 11:36:57PM -0600, Grant Likely wrote:
> On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
> wrote:
> > On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> >
> >> Either fought or embraced. To the extent that it is possible to focus
> >> solely on Linux and ARM,
On Mon, 14 Jun 2010, Mitch Bradley wrote:
> Nicolas Pitre wrote:
> > On Mon, 14 Jun 2010, Mitch Bradley wrote:
> >
> >
> > > First, the primary use case for "keeping OFW alive" is for debugging
> > > purposes.
> > > OFW remains resident in memory so that, if the OS is set to allow it (not
> >
Nicolas Pitre wrote:
On Mon, 14 Jun 2010, Mitch Bradley wrote:
First, the primary use case for "keeping OFW alive" is for debugging purposes.
OFW remains resident in memory so that, if the OS is set to allow it (not the
default), a hot-key freezes the OS and enters OFW, where a human can ins
On Mon, 14 Jun 2010, Mitch Bradley wrote:
> First, the primary use case for "keeping OFW alive" is for debugging purposes.
> OFW remains resident in memory so that, if the OS is set to allow it (not the
> default), a hot-key freezes the OS and enters OFW, where a human can inspect
> the state of d
I shall try to clarify this discussion.
There are actually two different things being discussed. The first is,
I hope, not too controversial. The second is so controversial as to be
a hopeless cause.
First, the primary use case for "keeping OFW alive" is for debugging
purposes. OFW remain
Grant Likely wrote:
> > Like initrd, some people will find they need to compile it in to the
> > kernel image to fit some bootloader they can't change, or daren't risk
> > changing in already rolled out devices that they want to update to a
> > DT-using kernel.
>
> Yes, I fully expect that. Fortu
On Mon, Jun 14, 2010 at 10:23 AM, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Jamie Lokier wrote:
>> So requiring that a bootloader can update the DT _independently_ of
>> everything else is a bit much for some devices.
>
> In my opinion, this use case you're illustrating above simply could
> cont
On Mon, Jun 14, 2010 at 10:02 AM, Jamie Lokier wrote:
> Nicolas Pitre wrote:
>> On Mon, 14 Jun 2010, David Gibson wrote:
>>
>> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
>> > [sni]
>> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
>> > > > firmwa
On Mon, 14 Jun 2010, Jamie Lokier wrote:
> Nicolas Pitre wrote:
> > On Mon, 14 Jun 2010, David Gibson wrote:
> >
> > > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > > [sni]
> > > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust
> > > > > the
> > > > > f
On Mon, 14 Jun 2010, Grant Likely wrote:
> The discussion *started* with a request to review this document:
>
> http://devicetree.org/Device_Tree_Usage
>
> Which is in early draft form (which is why the arm list wasn't
> initially cc'd. I was soliciting feedback from the current device tree
> us
On Mon, 14 Jun 2010, David Gibson wrote:
> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> [sni]
> > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > firmware, there is no pressure for the firmware to "get it right".
> >
> > Firmware will not get it
On Sun, 13 Jun 2010, Grant Likely wrote:
> [cc'ing linux-arm-kernel]
>
> On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
> > BTW. I notice no ARM list is CCed on this discussion ... maybe we should
> > fix that ?
>
> cc'ing linux-arm-kernel in all my replies
I'm afraid this won't be en
On Mon, Jun 14, 2010 at 9:58 AM, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Grant Likely wrote:
>
>> The discussion *started* with a request to review this document:
>>
>> http://devicetree.org/Device_Tree_Usage
>>
>> Which is in early draft form (which is why the arm list wasn't
>> initially cc'
In message: <20100614124438.gf9...@yookeroo>
David Gibson writes:
: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
: [sni]
: > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
: > > firmware, there is no pressure for the firmware to "get it right
Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > [sni]
> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > > firmware, there is no pressure for the firmware to "get it right".
>
On Mon, Jun 14, 2010 at 7:51 AM, Nicolas Pitre wrote:
> On Sun, 13 Jun 2010, Grant Likely wrote:
>
>> [cc'ing linux-arm-kernel]
>>
>> On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
>> > BTW. I notice no ARM list is CCed on this discussion ... maybe we should
>> > fix that ?
>>
>> cc'ing
On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
>> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
>> Indeed. In fact, the general rule of thumb is really "put as much as
>> possible into the most easily replaced layer of the stack"
Russell King - ARM Linux wrote:
> On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> > However, there's a lot of room for abuse here and I'm worried that if it
> > becomes widespread, we'll start seeing vendors use that as a way to do
> > some kind of HAL and hide various pla
On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
[sni]
> > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > firmware, there is no pressure for the firmware to "get it right".
>
> Firmware will not get it right. Period. There will always be
> something wron
On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> However, there's a lot of room for abuse here and I'm worried that if it
> becomes widespread, we'll start seeing vendors use that as a way to do
> some kind of HAL and hide various platform methods in there (clock
> control,
On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> > None of this is a deal-breaker for the kind of debugging tasks that are
> > the primary use case for the callback.
>
> Would you mind explaining what kind of ta
On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> None of this is a deal-breaker for the kind of debugging tasks that are
> the primary use case for the callback.
Would you mind explaining what kind of tasks these callbacks will
be used for?
___
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
> >> Or perhaps the MMU and caches can be turned off for the duration of the
> >> callback.
> >> I don't have the details of ARM MMUs and caches reloaded into my head
> >> yet. Maybe next week...
We've had these kinds of questions in t
Russell King - ARM Linux wrote:
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
Or perhaps the MMU and caches can be turned off for the duration of the
callback.
I don't have the details of ARM MMUs and caches reloaded into my head
yet. Maybe next week...
We've had t
Benjamin Herrenschmidt wrote:
On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
We use that to suck the device-tree, which we flatten, and then
re-enter
the kernel with the "common" entry interface.
I don't think I want to do the same on ARM. I'd rather have the
pr
On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
> > We use that to suck the device-tree, which we flatten, and then
> re-enter
> > the kernel with the "common" entry interface.
>
> I don't think I want to do the same on ARM. I'd rather have the
> prom_init stuff in a boot wrapper, or have
On Sat, Jun 12, 2010 at 11:33 AM, Stephan Gatzka wrote:
> 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 lo
On Sun, Jun 13, 2010 at 7:12 AM, Jeremy Kerr wrote:
> hi Ben,
>
>> Maybe a paragraph on the new proposed clock binding that Jeremy is
>> working would be of use btw.
>
> Here's one I prepared earlier:
>
> http://devicetree.org/ClockBindings
Yup, but the documents have difference purposes. ClockB
On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
wrote:
> On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
>
>> Either fought or embraced. To the extent that it is possible to focus
>> solely on Linux and ARM, one could image doing a good HAL.
>
> That will come with a huge amount o
[cc'ing linux-arm-kernel]
On Sat, Jun 12, 2010 at 11:59 PM, 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
On Sat, Jun 12, 2010 at 11:48 PM, Benjamin Herrenschmidt
wrote:
> 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
[cc'ing linux-arm-kernel because we're discussing ARM issues]
On Sat, Jun 12, 2010 at 11:39 PM, Mitch Bradley wrote:
> 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:
>>>
>>>
hi Ben,
> Maybe a paragraph on the new proposed clock binding that Jeremy is
> working would be of use btw.
Here's one I prepared earlier:
http://devicetree.org/ClockBindings
:)
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs
On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> > BTW. I notice no ARM list is CCed on this discussion ... maybe we
> should
> > fix that ?
> >
>
> Sounds like a good idea. Do you know which list(s) would be good
> candidates?
Forgot to reply to that one ... I'd say
linux-arm-ker
On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> Either fought or embraced. To the extent that it is possible to focus
> solely on Linux and ARM, one could image doing a good HAL.
That will come with a huge amount of comunity resistance sadly, but I
can imagine distros liking it.
In g
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
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
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.
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
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
On Fri, Jun 11, 2010 at 5:47 PM, 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
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 dev
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 gi
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 fi
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
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 o
74 matches
Mail list logo
