Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages

["Matt Sealey" <matt@genesi-usa.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3289 bytes --]

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 idea
(especially on ARM).

In any case, for platforms that don't, you can then make sure the "depends
on" line in Kconfig is for boards with no device trees - right now that
particular thing escapes me but I bet !PPC_OF or similar couldn't be too far
from the truth - so the ability to set the values is taken away if you have
device tree support built-in.

On MIPS or ARM with no DT support, if they don't have device tree support
compiled in, the options magically appear. You get the best of both worlds.

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*.

I can think of a bunch of reasons why it's a good idea.. what if your board
supports a DIMM and you want to keep the buffer up near the top of memory,
or the MBAR/CCSRBAR/IMMRBAR or whatever can move location so your SRAM moves
around depending on your firmware version or feature support, or, similarly,
if your L2 and SRAM are the same thing and can be configured to use
different sizes on each boot - pick a different size for the L2/SRAM and the
location may have to be moved, which means compiling a new firmware AND a
new kernel and matching up the values.. in the end it makes everyone's life
easier.

* naive implementation - if you only specify log-buffer then that means
metadata and buffer are "colocated" as your docs said, that'd be the least
complicated way to implement it without involving a hell of a lot of new
stuff, plus it means you can check the existance/value of two properties in
a node you can guarantee exists. Also since the log buffer format is
Linux-specific and Linux-compatible, and entirely a Linux feature, just like
the linux,initrd-start and -end, making a whole new node seems wasteful.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

On Tue, Nov 25, 2008 at 1:04 PM, Grant Erickson <gerickson@nuovations.com>wrote:

> On 11/25/08 10:55 AM, Josh Boyer wrote:
> > On Tue, 25 Nov 2008 12:53:12 -0600
> > "Matt Sealey" <matt@genesi-usa.com> 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 change in how this
> > would all work.  However, I do think you're generally right.
> >
> > Perhaps not /chosen, but maybe something like /rtas or /firmware, etc.
>
> I'm inclined to agree with you both; however, the submitted implementation
> was a choice of expediency given the existing DENX implementation and a
> customer that needed the feature "yesterday".
>
> ARM, MIPS, et al have not yet adopted device trees, correct? If so, is
> there
> value in providing the submitted implementation and adding support for
> getting said information from the device tree as another option if such
> information exists?
>
> Regards,
>
> Grant
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 4068 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev