linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Haren Myneni <haren@us.ibm.com>
To: Pantelis Antoniou <pantelis@embeddedalley.com>
Cc: Hollis Blanchard <hollisb@us.ibm.com>,
	"xen-ppc-devel@lists.xensource.com"
	<xen-ppc-devel@lists.xensource.com>,
	Milton Miller <miltonm@bga.com>,
	linuxppc-dev@ozlabs.org, "Sachin P. Sant" <sachinp@in.ibm.com>,
	linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [RFC] consolidated libdt proposal
Date: Tue, 08 Aug 2006 20:19:55 -0700	[thread overview]
Message-ID: <44D9545B.4020202@us.ibm.com> (raw)
In-Reply-To: <1BB7BBC5-8348-4C4C-9390-064A06C1B370@embeddedalley.com>

Pantelis Antoniou wrote:

>
> On 08 Αυγ 2006, at 8:37 ΠΜ, Haren Myneni wrote:
>
>> Hollis Blanchard wrote:
>>
>>> On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote:
>>>
>>>> Hmm, so we'll have at least three copies of this code: uboot, kernel,
>>>> and Xen. Would it make sense to put this stuff into a libdt.a?
>>>> Technically, dtc has a "libdt" already, but it's absurdly incomplete
>>>> (I don't even know why it's there), so we could just replace it.
>>>
>>>
>>> Mark, I had a look at the code Pantelis wrote for u-boot, and it was
>>> pretty easy to adapt to meet Xen's (userspace-based) needs. I've
>>> attached my version below (and see ft_setup() at the bottom of the
>>> file). Does it meet your requirements for the kernel bootwrapper?
>>>
>>> One limitation of the attached code is that it doesn't support changing
>>> the *size* of properties, though I don't think that would be too
>>> difficult to add if needed.
>>>
>>> Haren, what about using this in kexec-tools?
>>>
>>
>> Hollis,
>> Good idea to have this lib. Based on brief look, some of these funcs 
>> are also useful for kexec-tools. Yes, as you mentioned, changing the 
>> size of properties is important for kexec/kdump.
>>
>> Present flattened device-tree process in kexec-tools:
>>
>> - Kexec-tool reads the /proc/device-tree and sort these entries since 
>> we get the different order than the first kernel uses.
>> - creates linux,usable-memory property under /proc/device-tree/ 
>> memory@* as appropriate. (for kdump)
>> - Modify the reserve map for RTAS, initrd, TCE and (0- crashkernel- 
>> start)
>> - Create initrd properties if not exist in the first kernel as needed
>> - Modify bootargs property
>>
>> Thanks
>> Haren
>>
>
> Hi Haren,
>
> Mind writing down what your requirements are? Just modifying the size 
> of the properties?

Pantelis,

Yes, kexec-tool can use the proposed interfaces.

kexec-tool requirements:
creating the flattened device-tree from scratch based on the first 
kernel /proc/device-tree
While doing this process, should be able to
- add new properties (Ex: linux,usable-memory property under 
/proc/device-tree/memory@*)
- Modify properties: size and the value of the property could be 
changed(Ex: bootargs, not an issue since creating new anyway)

Thanks
Haren

>
> Note that my functions work in a two phases.
> In the first phase the tree is build with the string table being put 
> at the end
> of the allocated memory area in a downward motion.
> When the tree is finalized the string table is memmov'ed to be 
> adjacent to the structure
> proper.
>
> Could you use this two phased approach for you uses? I.e. first work 
> with maximum sized
> properties and perform a move & fixup stage when finalizing?
>
> Regards
>
> Pantelis
>
>>> If everybody can use this (I expect small modifications would be
>>> needed), I think we should turn it into a library in the dtc source
>>> tree. The various projects using it could then include snapshots (to
>>> avoid dependencies). In general I'd like to avoid everybody writing and
>>> maintaining their own version of this stuff (myself included).
>>>
>>>
>>> --------------------------------------------------------------------- 
>>> ---
>>>
>>> /
>>>
>>
>
>

  reply	other threads:[~2006-08-09  3:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-19 23:05 [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree Mark A. Greer
2006-08-02 16:10 ` Tom Rini
2006-08-02 17:05   ` Mark A. Greer
2006-08-02 17:23     ` Tom Rini
2006-08-07  0:38 ` Hollis Blanchard
2006-08-07 21:58   ` [RFC] consolidated libdt proposal Hollis Blanchard
2006-08-08  5:37     ` Haren Myneni
2006-08-08  9:34       ` Pantelis Antoniou
2006-08-09  3:19         ` Haren Myneni [this message]
2006-08-08 18:04     ` Mark A. Greer
2006-08-08 18:25       ` Hollis Blanchard
2006-08-08 18:51         ` Mark A. Greer
2006-08-08 18:46     ` Matthew McClintock
2006-08-08 19:12       ` Matthew McClintock
2006-08-11 19:33         ` Jon Loeliger
2006-08-08  0:30   ` [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree Mark A. Greer
2006-09-08  3:38 ` [PATCH 3/6] bootwrapper: Add flat device tree ops glue code Mark A. Greer
  -- strict thread matches above, loose matches on Subject: below --
2006-08-10 16:51 [RFC] consolidated libdt proposal Milton Miller
2006-08-10 18:55 ` Mark A. Greer
2006-08-11  4:55   ` Milton Miller

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=44D9545B.4020202@us.ibm.com \
    --to=haren@us.ibm.com \
    --cc=hollisb@us.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=pantelis@embeddedalley.com \
    --cc=sachinp@in.ibm.com \
    --cc=xen-ppc-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).