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 Sun, Jun 13, 2010 at 2:03 PM, Grant Likely wrote:
> [cc'ing the mailing list as a call for help]
>
> On Sun, Jun 13, 2010 at 2:59 AM, Stephan Gatzka wrote:
>> Hi Grant,
>>
>> I just startet to edit a PCI example for the device tree documentation (it's
>> a draft).
>>
>> It would be very helpfu
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
[cc'ing devicetree-discuss - this conversation should be kept on-list]
Hi Lorenzo,
On Mon, Jun 14, 2010 at 4:42 AM, Lorenzo Pieralisi
wrote:
> Hi Grant,
>
> Sorry to bother you, we had a chat about this at UDS, but I wanted to make
> sure I am doing it the PPC way.
Well, I wouldn't call it the
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, 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, 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, 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"
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
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, 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 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?
___
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
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
28 matches
Mail list logo
