From: Hollis Blanchard <hollisb@us.ibm.com>
To: "Mark A. Greer" <mgreer@mvista.com>
Cc: linuxppc-dev@ozlabs.org,
"xen-ppc-devel@lists.xensource.com"
<xen-ppc-devel@lists.xensource.com>
Subject: Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
Date: Sun, 06 Aug 2006 19:38:02 -0500 [thread overview]
Message-ID: <1154911082.27074.104.camel@diesel> (raw)
In-Reply-To: <20060719230544.GD3887@mag.az.mvista.com>
On Wed, 2006-07-19 at 16:05 -0700, an unknown sender wrote:
> --- /dev/null
> +++ b/arch/powerpc/boot/fdt.c
> @@ -0,0 +1,525 @@
> +/*
> + * Simple dtb (binary flattened device tree) search/manipulation routines.
> + *
> + * Author: Mark A. Greer <mgreer at mvista.com>
> + * - The code for strrchr() was copied from lib/string.c and is
> + * copyrighted by Linus Torvalds.
> + * - The smarts for fdt_finddevice() were copied with the author's
> + * permission from u-boot:common/ft_build.c which was written by
> + * Pantelis Antoniou <pantelis at embeddedalley.com>.
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.
Xen needs all the finddevice and setprop functionality here, which looks
like it's about 2/3rds of this code.
> +static void *dtb_start;
> +static void *dtb_end;
I'd like to avoid the use of globals here. I know it's fine when you're
running in early boot, but as I mentioned I'd like to copy this code
elsewhere. Could these be moved into a structure that's passed as a
function parameter?
> +static void
> +fdt_modify_prop(u32 *dp, char *datap, u32 *old_prop_sizep, char *buf,
> + int buflen)
> +{
> + u32 old_prop_data_len, new_prop_data_len;
> +
> + old_prop_data_len = _ALIGN_UP(*old_prop_sizep, 4);
> + new_prop_data_len = _ALIGN_UP(buflen, 4);
> +
> + /* Check if new prop data fits in old prop data area */
> + if (new_prop_data_len == old_prop_data_len) {
> + memcpy(datap, buf, buflen);
> + *old_prop_sizep = buflen;
> + }
> + else { /* Need to alloc new area to put larger or smaller fdt */
> + struct boot_param_header *old_bph, *new_bph;
> + u32 *old_tailp, *new_tailp, *new_datap;
> + u32 old_total_size, new_total_size, head_len, tail_len, diff;
> + void *new_dtb_start, *new_dtb_end;
> +
> + old_bph = fdt_get_bph(dtb_start),
> + old_total_size = old_bph->totalsize;
> + head_len = (u32)datap - (u32)dtb_start;
> + tail_len = old_total_size - (head_len + old_prop_data_len);
> + old_tailp = (u32 *)((u32)dtb_end - tail_len);
> + new_total_size = head_len + new_prop_data_len + tail_len;
> +
> + if (!(new_dtb_start = malloc(new_total_size))) {
> + printf("Can't alloc space for new fdt\n\r");
> + exit();
> + }
> +
> + new_dtb_end = (void *)((u32)new_dtb_start + new_total_size);
> + new_datap = (u32 *)((u32)new_dtb_start + head_len);
> + new_tailp = (u32 *)((u32)new_dtb_end - tail_len);
> +
> + memcpy(new_dtb_start, dtb_start, head_len);
> + memcpy(new_datap, buf, buflen);
> + memcpy(new_tailp, old_tailp, tail_len);
> + *(new_datap - 2) = buflen;
> +
> + new_bph = fdt_get_bph(new_dtb_start),
> + new_bph->totalsize = new_total_size;
> +
> + diff = new_prop_data_len - old_prop_data_len;
> +
> + /* Adjust offsets of other sections, if necessary */
> + if (new_bph->off_dt_strings > new_bph->off_dt_struct)
> + new_bph->off_dt_strings += diff;
> +
> + if (new_bph->off_mem_rsvmap > new_bph->off_dt_struct)
> + new_bph->off_mem_rsvmap += diff;
> +
> + free(dtb_start, old_total_size);
> +
> + dtb_start = new_dtb_start;
> + dtb_end = new_dtb_end;
> + }
> +}
I didn't realize the boot wrapper had a full malloc() to work with. I
was actually planning to only allow overwriting properties with values
of the same size, since for the most part I just need to modify some
small fixed-size data. Do you need more? I guess if the code already
works...
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2006-08-07 0:38 UTC|newest]
Thread overview: 17+ 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 [this message]
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
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
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=1154911082.27074.104.camel@diesel \
--to=hollisb@us.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mgreer@mvista.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).