[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1317221051.2580.76.camel@deneb.redhat.com>
Date: Wed, 28 Sep 2011 10:44:10 -0400
From: Mark Salter <msalter@...hat.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
devicetree-discuss@...ts.ozlabs.org,
Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v3 07/24] C6X: devicetree support
On Wed, 2011-09-28 at 15:31 +0200, Arnd Bergmann wrote:
> On Tuesday 27 September 2011, Mark Salter wrote:
> > diff --git a/arch/c6x/boot/install-dtb.c b/arch/c6x/boot/install-dtb.c
> > new file mode 100644
> > index 0000000..fa979ce
> > --- /dev/null
> > +++ b/arch/c6x/boot/install-dtb.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * Program to hack in a DTB to an ELF file having a placeholder
> > + * section named __fst_blob.
> > + *
> > + * This allows for building multiple images with builtin DTBs
> > + * using a single vmlinux image. This is only necessary until
> > + * bootloader support exists.
> > + *
> > + * Copyright 2011 Texas Instruments Incorporated
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + *
> > + * Usage: install-dtb <image.dtb> <kernel.elf>
> > + */
>
> Other architectures allow simply appending the device tree to the
> kernel image file, which is more convenient for users and does
> not require much kernel support. Have you tried this?
Well, I considered it. My main reason for doing it this way was one of
debugging convenience. The debugger loads an ELF file and while I was
making lots of device tree changes in the tree and in the code, it was
more convenient to have one ELF file to deal with rather than an ELF
file and a dtb. And the thought was to get rid of it altogether once
bootloader support comes along. Maybe the thing to do would be to just
rip it out of the kernel. It can almost as easily be post-processing
step outside the kernel.
--Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists