[PATCH v2 5/5] configs: am335x_evm: Fix BeagleBone Green DTB selection

[Lokesh Vutla]

On 21/07/21 12:10 pm, Paul Barker wrote:
> On Wed, 21 Jul 2021 11:29:04 +0530
> Lokesh Vutla <lokeshvutla at ti.com> wrote:
> 
>> On 20/07/21 1:49 pm, Paul Barker wrote:
>>> On Tue, 13 Jul 2021 11:59:06 +0530
>>> Lokesh Vutla <lokeshvutla at ti.com> wrote:
>>>   
>>>> On 13/07/21 1:44 am, Paul Barker wrote:  
>>>>> The function board_is_bone_lt() returns true for the BeagleBone Green,
>>>>> the BeagleBone Enhanced and the BeagleBone Black. Therefore when
>>>>> selecting which devicetree to use we must ensure that the more specific
>>>>> functions board_is_bbg1() and board_is_bben() are checked first
>>>>> otherwise all three devices would end up using the am335x-boneblack
>>>>> devicetree. This can be achieved by placing the relevant devicetree
>>>>> names (am335x-sancloud-bbe and am335x-bonegreen) before am335x-boneblack
>>>>> in CONFIG_OF_LIST.    
>>>>
>>>> Such restrictions should be handled inside board_fit_config_name_match() and
>>>> hiden from user configuration. Can you update the board_fit_config_name_match()
>>>> instead of updating defconfig?  
>>>
>>> Hi Lokesh,
>>>
>>> Apologies for the late reply, I lost most of last week due to illness.
>>>
>>> I first attempted to fix this by changing the order of things in
>>> `board_fit_config_name_match` but it had no effect. Looking at
>>> `fit_find_config_node` in `common/common_fit.c`, we loop through the
>>> list of dtbs and check each one in turn for a match. So to move
>>> am335x-bonegreen ahead of am335x-boneblack we need to change the order
>>> in which the dtbs are checked in `fit_find_config_node`. The simplest
>>> way I could find to do that is to change the order of the names in
>>> CONFIG_OF_LIST.  
>>
>> ahh..ok got it. But still such constraints in config file is most likely will
>> not be maintained in future when someone touching the config. Because not
>> everyone knows this.
>>
>> Is it possible to create a new macro which is true only for bbb and use it
>> instead in board_fit_config_name_match?
> 
> I'm happy to have a look for an alternative solution like that. The
> patch here is a quick fix though that can be applied as-is. Perhaps we
> should apply this and also look for an alternative implementation of
> `board_is_bone_lt`.
> 
> If you want to leave this patch out for now, can we move ahead and
> merge the other patches in this series?

You are right. Applied the first 4 patches to for-rc branch.

Thanks and regards,
Lokesh