linux-kernel - Re: [PATCH] OF: Add support for built in FDT blob

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 7 Nov 2014 16:47:01 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Rob Herring <robherring2@...il.com>
Cc:	Alban <albeu@...e.fr>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>
Subject: Re: [PATCH] OF: Add support for built in FDT blob

On Fri, Nov 07, 2014 at 02:56:32PM +0000, Rob Herring wrote:
> On Fri, Nov 7, 2014 at 6:59 AM, Alban <albeu@...e.fr> wrote:
> > On Fri, 7 Nov 2014 12:09:33 +0000
> > Mark Rutland <mark.rutland@....com> wrote:
> >
> >> Hi,
> >>
> >> On Fri, Nov 07, 2014 at 11:14:09AM +0000, Alban Bedel wrote:
> >> > Allow embedding an FDT blob in the kernel image, this is mostly
> >> > useful to run new kernels on boards with old bootloaders.
> >>
> >> I am very much not keen on embedding a DTB within a kernel. It's far
> >> nicer for the two to remain separate blobs, with a small shim to set
> >> up the DTB address.
> >>
> >> On ARM we have appended DTB for this purpose, which is at least better
> >> than embedding the DT inside of the kernel.
> >
> > I looked at that but that seemed quiet complicated to implement, not to
> > mention that it needed quiet a lot of arch specific code. On the other
> > hand having the DTB built in like this was trivial and would be portable
> > to every architecture, so that seemed like the best way to me.
> >
> >> What architecture and bootloader are you using that necessitate this?
> >
> > MIPS with an antic u-boot version patched by the board vendor to use
> > some non standard image format. Updating the boot loader is currently
> > not an option because of the lack of documentation for the board/SoC.
> 
> MIPS and a few other arches already have built-in dtb support. We
> don't need another way to do it, but I would welcome any clean-up that
> makes it arch independent and available to any arch.
> 
> While Mark is right, I could envision other uses such as embedding
> overlay dtbs in the kernel either for add-on boards or just as fixups.

I don't see how embedding a DTB in this manner helps with overlays and
fixups.

I'm rather worried about this turning into a shoddy board file, and
making it painful to build/distribute/boot a generic kernel for an
arbitrary platform.

On arm64 the kernel and DTB have always been separate, and I'm not keen
on allowing the two to be tightly coupled in this way. There are already
container formats (e.g. FIT) that can be used to hold both if that's
what the bootloader desires.

Thanks,
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/