[PATCH 2/2] of/fdt: add kernel command line option for dtb_compat string

[Grant Likely]

On Tue, Nov 16, 2010 at 6:48 PM, Dirk Brandewie
<dirk.brandewie at gmail.com> wrote:
> On 11/16/2010 04:12 PM, Grant Likely wrote:
>>
>> On Tue, Nov 16, 2010 at 6:50 AM, Dirk Brandewie
>> <dirk.brandewie at gmail.com>  wrote:
>>>
>>> On 11/15/2010 10:32 PM, Grant Likely wrote:
>>>>
>>>> On Mon, Nov 15, 2010 at 08:01:21PM -0800, dirk.brandewie at gmail.com
>>>> wrote:
>>>>>
>>>>> +{
>>>>> +       void *rc = NULL;
>>>>> +       unsigned long root, size;
>>>>> +       struct boot_param_header  *orig_initial_boot_params;
>>>>> +       uint8_t *blob;
>>>>
>>>> blob should be a void* here.  It is never used as a uint8.
>>>>
>>>
>>> I used uint8_t prevent compiler warning when blob is compared to
>>> __dtb_end
>>>
>>
>> okay
>>
>>>>> +{
>>>>> +       strncpy(dtb_compat_name, line, MAX_DTB_COMPAT_STR);
>>>>> +       return 1;
>>>>> +}
>>>>
>>>> I don't remember getting a response about whether or not
>>>> of_find_compatible_dtb can be called directly from dtb_compat_setup.
>>>> Doing so would eliminate the arbitrary MAX_DTB_COMPAT_STR because
>>>> there would be no need to keep around a copy of dtb_compat_name.  It
>>>> also means that of_find_compatible_dtb() can be restricted to the file
>>>> scope.
>>>>
>>>> Is there a use-case for calling of_find_compatible_dtb() anywhere
>>>> other than in dtb_compat_setup?
>>>>
>>>
>>> The use case for having these functions exposed is allowing the platfrom
>>> code decide the policy for which dtb will be used in the case where a dtb
>>> might have been passed in by the boot loader. These functions can be used
>>> as
>>> a fallback if a dtb was not passed in or to override of the passed in dtb
>>> by
>>> the platform code.
>>
>> Still this all looks very generic, even across architectures.  I say
>> don't export the functions for now, and change it later if a use case
>> shows up that requires it.  I'd really rather not let platform code
>> muck about with it directly if there isn't a use case for it.
>
> I have the use case for it in my platform.  There will two ways that the
> kernel can get the DTB.
> 1. The blob is linked in and I go find the one for my platform. This is the
> path that uses the two new functions.
>
> 2. The a pointer blob passed in (physical address) from the bootloader. The
> blob is relocated/copied to keep the bootloader from having to know the
> kernel memory layout.
>
> One method will be able to override the other.  I am not sure what the
> precedence between the methods will be ATM.

ATM, let's assume that all platforms will use the same precedence
rules.  I really don't want to see arbitrary differences between
platforms in this regard.  Encode the behaviour fully into fdt.c.  If
the precedence rules end up being wrong, then it can be changed.  If
it turns out that different platforms really do need to have different
rules, then it can be exported at that time.

g.

>> However, thinking about it further.  You also need to make sure this
>> code is excluded for the powerpc and microblaze architectures because
>> the kernel command line is passed via the device tree blob in those
>> cases.  By that time it gets called, it is too late to switch the
>> device tree pointer.
>>
> if a "wrapped" kernel is booted doesn't it know exactly which dtb it should
> be using?

Yes.  All of the current powerpc dt-wrappers only carry 1 dtb image
per wrapper, so the question of which dtb is moot.  However, powerpc
wrappers are firmware-interface specific, and their entire purpose in
life is to translate data from the firmware-specific interface into
the dtb representation.  Powerpc history has a number of oddball
firmware interfaces with no way to detect which one is being used.
Therefore, the wrapper has to be hand chosen for each legacy platform.

> These platforms would never go looking for the command line value
> even it it was passed in.

Correct.  On PowerPC the vmlinux entry point *requires* passing in a
device tree, so the command line value isn't useful.

g.


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