From: wmb@firmworks•com (Mitch Bradley)
To: linux-arm-kernel@lists•infradead.org
Subject: Request review of device tree documentation
Date: Sun, 13 Jun 2010 20:17:13 -1000 [thread overview]
Message-ID: <4C15C969.7020108@firmworks.com> (raw)
In-Reply-To: <1276495772.2552.22.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
>
>>> We use that to suck the device-tree, which we flatten, and then
>>>
>> re-enter
>>
>>> the kernel with the "common" entry interface.
>>>
>> I don't think I want to do the same on ARM. I'd rather have the
>> prom_init stuff in a boot wrapper, or have OFW itself generate the
>> flat representation before booting the kernel.
>>
>
> But then it's no longer OF. IE. A compliant OF implementation provides a
> client interface API :-)
>
> This is going to be especially important if Mitch wants to keep OF
> alive.
>
> I suppose it could be done via a wrapper like prom_init, which flattens
> the tree, and sticks somewhere in a property the address of the OF
> client interface callback though it's a tad awkward. If well defined, I
> suppose Mitch might even be able to make his OF natively boot kernels
> that way but that's of course up to him.
>
I'm willing to create a flattened tree. I can provide both a client
interface and a flattened tree. The kernel probably won't use the
client interface to any significant extent.
Way back in the misty annals of history, I dreamed of having a common
interface between firmware and OSs. That didn't happen. Every OS
insisted on defining its own interface and creating a custom bootloader,
or in some cases a half dozen of them.
>
>> I'm trying to constrain the number of things that could go wrong by
>> defining only one way for getting the device tree data into the
>> kernel.
>>
>
> I understand, and the flattened method is the most versatile, I'm just
> pointing out the situation here :-)
>
>
>> Right. We don't need to use OFW/RTAS to handle this use case.
>>
>
> Definitely not. It will depend on whatever hypervisor interface is
> implemented in a given environment. Though I do like the idea of passing
> precompiled bits of .dtb around for hotplug :-) We could make that a
> standard way of KVM to do things in embedded space.
>
> Cheers,
> Ben.
>
>
>
prev parent reply other threads:[~2010-06-14 6:17 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTilK4YkRMJqlcRDOAlGBzpdlZuSo9NF5NrRNocHT@mail.gmail.com>
[not found] ` <33BD8E86-9397-432A-97BF-F154812C157B@digitaldans.com>
[not found] ` <AANLkTilv6TtPZs0DAwd8JlSV_J3VvMsvtVVOOeQauOIn@mail.gmail.com>
[not found] ` <4C13430B.5000907@firmworks.com>
[not found] ` <1276339529.1962.184.camel@pasglop>
[not found] ` <1276339684.1962.186.camel@pasglop>
[not found] ` <4C13B618.1030006@firmworks.com>
[not found] ` <1276383132.1962.195.camel@pasglop>
[not found] ` <AANLkTimRV8u3gDNCAIlROJoPcKs7jFwj2na3ZDFOg3O0@mail.gmail.com>
[not found] ` <4C146F18.9030008@firmworks.com>
2010-06-14 5:02 ` Request review of device tree documentation Grant Likely
2010-06-14 12:44 ` David Gibson
2010-06-14 14:59 ` Nicolas Pitre
2010-06-14 15:08 ` Grant Likely
2010-06-14 16:02 ` Jamie Lokier
2010-06-14 16:23 ` Nicolas Pitre
2010-06-14 16:29 ` Grant Likely
2010-06-14 16:28 ` Grant Likely
2010-06-14 16:33 ` Jamie Lokier
2010-06-14 16:58 ` Mitch Bradley
2010-06-14 17:26 ` Nicolas Pitre
2010-06-14 18:20 ` Mitch Bradley
2010-06-14 19:40 ` Nicolas Pitre
2010-06-14 20:08 ` Mark Brown
2010-06-16 6:09 ` Mike Rapoport
2010-06-16 6:13 ` Mitch Bradley
2010-06-16 6:17 ` Mike Rapoport
2010-06-16 6:32 ` Mitch Bradley
2010-06-16 6:47 ` Mike Rapoport
2010-06-16 7:40 ` Mitch Bradley
2010-06-16 9:45 ` Vladimir Pantelic
2010-06-16 10:39 ` Mike Rapoport
2010-06-16 11:41 ` Jamie Lokier
2010-06-16 13:48 ` Jamie Bennett
2010-06-16 14:39 ` Nicolas Pitre
2010-06-16 17:43 ` Tim Bird
2010-06-17 6:45 ` Benjamin Zores
2010-06-16 6:52 ` M. Warner Losh
2010-06-18 22:12 ` Frank Rowand
2010-06-15 2:02 ` David Gibson
2010-06-14 15:51 ` M. Warner Losh
[not found] ` <1276408773.1962.574.camel@pasglop>
2010-06-14 5:23 ` Grant Likely
2010-06-14 7:38 ` Russell King - ARM Linux
2010-06-14 7:45 ` Mitch Bradley
2010-06-14 9:25 ` Russell King - ARM Linux
2010-06-14 9:36 ` Benjamin Herrenschmidt
2010-06-14 9:47 ` Russell King - ARM Linux
2010-06-14 14:29 ` Jamie Lokier
2010-06-14 13:51 ` Nicolas Pitre
2010-06-14 15:35 ` Grant Likely
2010-06-14 15:58 ` Nicolas Pitre
2010-06-14 16:16 ` Grant Likely
[not found] ` <4C147EA5.3060500@firmworks.com>
[not found] ` <1276417792.1962.731.camel@pasglop>
2010-06-14 5:36 ` Grant Likely
2010-06-14 20:00 ` Ben Dooks
[not found] ` <1276408087.1962.552.camel@pasglop>
2010-06-14 5:13 ` Grant Likely
2010-06-14 6:09 ` Benjamin Herrenschmidt
2010-06-14 6:17 ` Mitch Bradley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C15C969.7020108@firmworks.com \
--to=wmb@firmworks$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox