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
In “Understanding the compatible Property”
The first string in the list specifies the exact device that the node
represents in the form manufacturer,model.
should be The first string in the list specifies the exact device that the
node represents in the form manufacturer,model.
--
Terren Chow
On Thu, Aug 5, 2010 at 9:15 AM, Terren Chow terren.c...@gmail.com wrote:
In “Understanding the compatible Property”
The first string in the list specifies the exact device that the node
represents in the form manufacturer,model.
The first string in the list specifies the exact device that the
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
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.
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
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
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
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
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
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
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
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
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 enough.
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, 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
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:
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 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
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
[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
[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 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 :-)
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, 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,
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
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
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,
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
51 matches
Mail list logo
