WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

[XenPPC] Re: [RFC] consolidated libdt proposal

To: Pantelis Antoniou <pantelis@xxxxxxxxxxxxxxxxx>
Subject: [XenPPC] Re: [RFC] consolidated libdt proposal
From: Haren Myneni <haren@xxxxxxxxxx>
Date: Tue, 08 Aug 2006 20:19:55 -0700
Cc: "Mark A. Greer" <mgreer@xxxxxxxxxx>, "xen-ppc-devel@xxxxxxxxxxxxxxxxxxx" <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>, Milton Miller <miltonm@xxxxxxx>, linuxppc-dev@xxxxxxxxxx, "Sachin P. Sant" <sachinp@xxxxxxxxxx>, linuxppc-embedded <linuxppc-embedded@xxxxxxxxxx>, Jon Loeliger <jdl@xxxxxxxxxxxxx>
Delivery-date: Tue, 08 Aug 2006 20:20:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1BB7BBC5-8348-4C4C-9390-064A06C1B370@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060719230544.GD3887@xxxxxxxxxxxxxxxxx> <1154911082.27074.104.camel@diesel> <1154987921.24455.32.camel@xxxxxxxxxxxxxxxxxxxxx> <44D8230F.4020202@xxxxxxxxxx> <1BB7BBC5-8348-4C4C-9390-064A06C1B370@xxxxxxxxxxxxxxxxx>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-2
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).


--------------------------------------------------------------------- ---

/






_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel