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 could
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 w...@firmworks.com writes:
: Mike Rapoport wrote:
: Mitch Bradley wrote:
: Mike Rapoport wrote:
: Mitch Bradley wrote:
:
: The second topic is the hypothetical use of OFW as a
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
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.
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
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
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
In message: 4c187013.5000...@firmworks.com
Mitch Bradley w...@firmworks.com 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
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
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
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
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
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
objection to
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 the
better
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 market
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 OFW
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
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
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 the past.
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 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 tasks
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 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 wrong. It
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 platform
On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre n...@fluxnic.net 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
On Mon, Jun 14, 2010 at 7:51 AM, Nicolas Pitre n...@fluxnic.net 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
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.
Firmware
In message: 20100614124438.gf9...@yookeroo
David Gibson da...@gibson.dropbear.id.au 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
On Mon, Jun 14, 2010 at 9:58 AM, Nicolas Pitre n...@fluxnic.net 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
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
users.
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
firmware, there is no
On Mon, Jun 14, 2010 at 10:02 AM, Jamie Lokier ja...@shareable.org 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
On Mon, Jun 14, 2010 at 10:23 AM, Nicolas Pitre n...@fluxnic.net 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
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. Fortunately
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 remains
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
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
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
the
default), a
On Sun, Jun 13, 2010 at 11:36:57PM -0600, Grant Likely wrote:
On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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 requires
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 pressure for the
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
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
On Sat, Jun 12, 2010 at 05:09:36PM -0600, Grant Likely wrote:
On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson o...@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
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
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
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
[cc'ing linux-arm-kernel because we're discussing ARM issues]
On Sat, Jun 12, 2010 at 11:39 PM, Mitch Bradley w...@firmworks.com wrote:
Grant Likely wrote:
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Sat, 2010-06-12 at 06:30 -1000, Mitch
On Sat, Jun 12, 2010 at 11:48 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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.
[cc'ing linux-arm-kernel]
On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On Sun, Jun 13, 2010 at 7:12 AM, Jeremy Kerr jeremy.k...@canonical.com 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
On Sat, Jun 12, 2010 at 11:33 AM, Stephan Gatzka step...@gatzka.org 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
On Fri, Jun 11, 2010 at 5:47 PM, Dan Malek ppc6...@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 :-)
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
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
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?
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:
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
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.
On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson o...@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. This isn't actually
in any spec anywhere,
That would be great. Thank you.
On 12 Jun 2010 11:44, Stephan Gatzka step...@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.
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
b...@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. On the x86 OLPC machines,
the ability to
dive into OFW via a SysRq key combo was very helpful for
Grant Likely wrote:
On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt
b...@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. On the x86 OLPC machines,
the ability to
dive into OFW via a SysRq key
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.c on
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
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
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
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
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
72 matches
Mail list logo
