<br><br><div class="gmail_quote">On Tue, Nov 25, 2008 at 12:55 PM, Josh Boyer <span dir="ltr"><<a href="mailto:jwboyer@linux.vnet.ibm.com">jwboyer@linux.vnet.ibm.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 class="Ih2E3d">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>
<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>
</div>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>
<font color="#888888"><br>
josh</font></blockquote><div> </div></div>I think the best place is chosen, with things like stdin, stdout etc. - this is where you generally go and dump weird little variables which need to be passed in for early boot. You could consider the log buffer a kind of stdin/out variation.<br>
<br>I don't think it needs a whole new device tree node just for two memory locations.. is the support really worth a compatible property, etc. to differentiate between different operating modes?<br clear="all"><br>-- <br>
Matt Sealey <<a href="mailto:matt@genesi-usa.com">matt@genesi-usa.com</a>><br>Genesi, Manager, Developer Relations<br>