On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
>> This merges support for the previously DENX-only kernel feature of
>> specifying an alternative, "external" buffer for kernel printk
>> messages and their associated metadata. In addition,
On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
> This merges support for the previously DENX-only kernel feature of
> specifying an alternative, "external" buffer for kernel printk
> messages and their associated metadata. In addition, this ports
> architecture support for this feature fr
On Tue, Nov 25, 2008 at 3:45 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> No comment from me on $SUBJECT beyond "it seems plausible", but ...
>
> On Tuesday 25 November 2008, David VomLehn wrote:
>> The important point, though, is that device tree is the only
>> thing approaching a standard on a
On Tue, Nov 25, 2008 at 13:34, Grant Erickson wrote:
> This merges support for the previously DENX-only kernel feature of
> specifying an alternative, "external" buffer for kernel printk
> messages and their associated metadata. In addition, this ports
> architecture support for this feature from a
No comment from me on $SUBJECT beyond "it seems plausible", but ...
On Tuesday 25 November 2008, David VomLehn wrote:
> The important point, though, is that device tree is the only
> thing approaching a standard on any non-x86-based platform for passing
> structured information from the bootloader
On Tue, 2008-11-25 at 14:19 -0600, Bill Gatliff wrote:
> Just trying to figure out where the walls of this "sandbox" are. I've
> been aware of the concept of Open Firmware for a while, but haven't
> really looked into it before now--- mostly because my impression until
> now was that the availab
On Tue, Nov 25, 2008 at 3:05 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Matt,
>
> In message <[EMAIL PROTECTED]>
> you wrote:
> >
> > There is also no reason you can't hard-code the locations into the device
> > tree, to support older U-Boots that don't know about
> > /chosen/linux,log-me
Dear Matt,
In message <[EMAIL PROTECTED]> you wrote:
>
> There is also no reason you can't hard-code the locations into the device
> tree, to support older U-Boots that don't know about
> /chosen/linux,log-metadata and /chosen/linux,log-buffer*.
Actually there is such reason - U-Boot traditionall
On Tue, Nov 25, 2008 at 2:17 PM, Grant Likely <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
> > But here's the real question; why do you need an opensource
> implementation?
> > Curiosity?
>
> Umm, so that it can be ported to new boards perha
On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
>>
>> Matt Sealey wrote:
>>
>> > I can think of a bunch of reasons why it's a good idea..
>>
>> Can you point to a GPL/LGPL/BSD/etc. source code for
. F
On Tue, Nov 25, 2008 at 12:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
>
>> I can think of a bunch of reasons why it's a good idea..
>
> Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
> implementation?
In powerpc land using the Open Firmware devi
Matt Sealey wrote:
> Yes, there's FirmWorks, CodeGen SmartFirmware, IBM SLOF and OpenBIOS..
> they're all linked from the OpenBIOS website (along with a bunch of the
> documentation from http://www.openfirmware.org in more-readable formats
> like PDF)
>
> http://www.openbios.org/
>
>
> But here'
Matt Sealey wrote:
> I can think of a bunch of reasons why it's a good idea..
Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
implementation?
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozla
On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
>
> > I can think of a bunch of reasons why it's a good idea..
>
> Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
> implementation?
>
Yes, there's FirmWorks, CodeGen SmartFirmware,
Actually there is an ARM board out there with an Open Firmware (Toshiba
TOPAS910 -
http://www.toshiba-components.com/microcontroller/BMSKTOPAS910.html) so,
yes, device trees do appear on those platforms. QEMU is looking to go that
way too, seems for every architecture it would be a pretty awesome i
On 11/25/08 10:55 AM, Josh Boyer wrote:
> On Tue, 25 Nov 2008 12:53:12 -0600
> "Matt Sealey" <[EMAIL PROTECTED]> wrote:
>> Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
>> property(ies), perhaps something in the
>> /chosen node that U-Boot etc. can then fill out?
>
> I
On Tue, Nov 25, 2008 at 12:55 PM, Josh Boyer <[EMAIL PROTECTED]>wrote:
> On Tue, 25 Nov 2008 12:53:12 -0600
> "Matt Sealey" <[EMAIL PROTECTED]> wrote:
>
> > Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
> > property(ies), perhaps something in the
> > /chosen node that U
On Tue, 25 Nov 2008 12:53:12 -0600
"Matt Sealey" <[EMAIL PROTECTED]> wrote:
> Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
> property(ies), perhaps something in the
> /chosen node that U-Boot etc. can then fill out?
I don't think that's a nitpick. It's a fundamental
Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
property(ies), perhaps something in the
/chosen node that U-Boot etc. can then fill out?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
On Tue, Nov 25, 2008 at 12:34 PM, Grant Erickson
<[EMAIL PROT
This merges support for the previously DENX-only kernel feature of
specifying an alternative, "external" buffer for kernel printk
messages and their associated metadata. In addition, this ports
architecture support for this feature from arch/ppc to arch/powerpc.
Signed-off-by: Grant Erickson <[EMA
20 matches
Mail list logo
