Actually there is an ARM board out there with an Open Firmware (Toshiba
TOPAS910 -
<a href="http://www.toshiba-components.com/microcontroller/BMSKTOPAS910.html">http://www.toshiba-components.com/microcontroller/BMSKTOPAS910.html</a>)
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).<br><br>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.<br>
<br>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.<br><br>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*.<br>
<br>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.<br>
<br>* 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.<br><br>-- <br>
Matt Sealey <<a href="mailto:matt@genesi-usa.com">matt@genesi-usa.com</a>><br>Genesi, Manager, Developer Relations<br><br><div class="gmail_quote">On Tue, Nov 25, 2008 at 1:04 PM, Grant Erickson <span dir="ltr"><<a href="mailto:gerickson@nuovations.com">gerickson@nuovations.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">On 11/25/08 10:55 AM, Josh Boyer wrote:<br>
> On Tue, 25 Nov 2008 12:53:12 -0600<br>
> "Matt Sealey" <<a href="mailto:matt@genesi-usa.com">matt@genesi-usa.com</a>> wrote:<br>
>> Nitpick, really.. shouldn't the logbuffer location(s) be some device tree<br>
>> property(ies), perhaps something in the<br>
>> /chosen node that U-Boot etc. can then fill out?<br>
><br>
> I don't think that's a nitpick. It's a fundamental change in how this<br>
> would all work. However, I do think you're generally right.<br>
><br>
> Perhaps not /chosen, but maybe something like /rtas or /firmware, etc.<br>
<br>
</div></div>I'm inclined to agree with you both; however, the submitted implementation<br>
was a choice of expediency given the existing DENX implementation and a<br>
customer that needed the feature "yesterday".<br>
<br>
ARM, MIPS, et al have not yet adopted device trees, correct? If so, is there<br>
value in providing the submitted implementation and adding support for<br>
getting said information from the device tree as another option if such<br>
information exists?<br>
<br>
Regards,<br>
<font color="#888888"><br>
Grant<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>