[sodaville] [RFC] [PATCH] Adding DTB to architecture independent vmlinux

[Grant Likely]

On Wed, Oct 27, 2010 at 1:27 PM, H. Peter Anvin <hpa at linux.intel.com> wrote:
> On 10/27/2010 4:09 AM, Grant Likely wrote:
[...]
>> I don't think it is worth trying to do this in a cross-architecture
>> way.  The powerpc zImage wrappers are already very platform-specific
>> code, and there are no assumptions made about how a dtb image is
>> linked into the wrapper.  A wrapper could even link in multiple dtb
>> images.
>>
>> For the x86 code, linking the dtb into the vmlinux itself is not
>> something that is desired without the option of selecting it between
>> multiple linked-in dtb files if firmware doesn't pass one in for you.
>> This will require some discussion about how best to manage dtbs before
>> merging a patch like this.
>>
>
> I have to disagree, strongly, that it is not worth doing a
> cross-architectural patch.  There is nothing that prevents an architecture
> from having any number of different ones *in addition to* the independent
> way, but that would clearly establish a baseline that everyone can benefit
> from.  This is a Very Good Thing[TM].  We already have too many gratuitous
> differences between architectures in Linux.

The problem in this case is that it turns into a magic config option
that explicitly restricts the number of platforms a kernel image will
run on down to exactly one.  This (particular) approach is 100%
counter to the direction I've been trying to take embedded platforms
over the last few years.  I'm opposed to linking a single .dtb as a
'baseline' image because embedded system developers will start using
and depending on that feature instead if implementing something that
is multi-platform friendly.

That said, I'm not at all opposed to common infrastructure for linking
one or more .dtb images into the kernel provided that each image is
referred to by a separate symbol, and that it does not implement any
kind of baseline semantics.  Selection of the correct .dtb image from
platform code should always be explicit; not implicit nor controlled
by a single Kconfig setting.

So, if a patch is floated that provides linking multiple and arbitrary
.dtb images into the kernel for use by other code, then I'm all for
it.  The problem of selecting /which/ dtb to use can be addressed (and
debated) in a separate patch.

> As far as linking in multiple dtbs, the one architecture-independent way we
> have to pass data into the kernel is the kernel command line, and it might
> make sense to have a command line parameter like "dtb=foo",

Patches have been floated before to pass the .dtb address via the
kernel command line, but they've not been pursued to completion.  I
have no problems with accepting cross-architecture patches to
implement a dtb= kernel parameter, with the caveat that it wouldn't be
applicable when the kernel command line is passed via the .dtb.  :-)

> although I
> expect the vast majority of all users who don't rely on the
> firmware/bootloader to feed them information are going to have one kernel
> image per platform anyway, just for space reasons.

Not really true.  Currently on ARM many SoC family support multiple
boards on a single kernel image with firmware only supplying a unique
integer (machine id) to identify the board.  See
arch/arm/include/asm/mach/arch.h, grep for both MACHINE_START and
lookup_machine_type in arch/arm/mach-*.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.