Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tom Rini]

On 06/26/2014 03:50 AM, Tony Lindgren wrote:
> * Gupta, Pekon <pekon at ti.com> [140618 01:52]:
>> Hi,
>>
>>> From: Jason Kridner [mailto:jkridner at gmail.com]
>>>> On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon at ti.com> wrote:
>>>>> From: Jason Kridner
>> [...]
>>>>>> * The devicetree sources, including the primary boot .dts files, will
>>>>>> eventually be removed from the kernel source tree. I'm not too sure if
>>>>>> and when it'll really happen, but starting up a project to maintain
>>>>>> the definitive beagleboard.org board devicetree files outside the
>>>>>> kernel seems to make sense. Given the interdependency of the boot .dtb
>>>>>> and the overlay .dtbo files, combining them into a single repository
>>>>>> where every distribution can pick them up seems like a natural and
>>>>>> obvious choice. There are of course some dependencies on kernel
>>>>>> versions, but I believe most of those have settled out by now and we
>>>>>> should be OK moving forward.
>>>>
>>>> +1
>>>> Yes, moving cape DTS out of kernel tree should help developers.
>>>> There are quite a few cape patches floating in mail-lists, but as cape
>>>> DTS is still not accepted in mainline so they get lost and forgotten.
>>>> So one place for collecting all this is a good idea.
>>>>
>>>>
>>>> However, somehow the universal I/O DTS looked seemed complicated:
>>>> (1)
>>>> All capes work standalone, but due to share pin-mux some cape
>>>> combinations cannot be used simultaneously. But most users of
>>>> BeagleBone are already well-versed with DT and kernel infrastructure,
>>>> so they need not be spoon fed to get a out-of-box working solution
>>>> for each combination. If there is proper documentation is available
>>>> about compatibility of capes with each other, then users will figure
>>>> out themselves.
>>>
>>> I think you have too much confidence in users. If this doesn't hurt
>>> power users, then why is it bad have an option to spoon feed? This
>>> doesn't prevent anyone with knowledge of DT from doing their own
>>> thing.
>>>
>> Fair enough.
>> But plz give a try to u-boot alternative below. It works at my end.
>>
>>>>
>>>> (2)
>>>> Also, there was a talk of enabling and disabling DT fragments via u-boot.
>>>> That should also be explored instead of complicating cape DTS.
>>>
>>> Link? Relevance?
>>>
>> we can modify DT from u-boot itself [1].
>> Example:  "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
>> But using following sequence of commands, you can modify DTB via
>> u-boot and make NAND cape work _without_any_hack_ in patch [2].
>>
>> /* load DTB */
>> u-boot> tftp 0x81000000 am335x-boneblack.dtb
>> u-boot> fdt addr 0x81000000
>> /* disable MMC2 node */
>> u-boot> fdt list /ocp/mmc at 481d8000
>> u-boot> fdt set  /ocp/mmc at 481d8000 status \d\i\s\a\b\l\e\d
>> u-boot> fdt list /ocp/mmc at 481d8000 status
>> /* enable GPMC node */
>> u-boot> fdt list /ocp/gpmc
>> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
>> u-boot> fdt list /ocp/gpmc status
>> /* enable ELM node */
>> u-boot> fdt list /ocp/elm
>> u-boot> fdt set  /ocp/elm status \o\k\a\y
>> u-boot> fdt list /ocp/elm status
>> /* boot uImage */
>> tftp 0x82000000 uImage
>> bootm 0x82000000 - 0x81000000
>>
>> Note: "fdt set" command does not accept string literals
>> as binding values, it internally converts them to string, so
>> escape sequenced characters were used here..
>> "okay" == \o\k\a\y
>> "disabled" == \d\i\s\a\b\l\e\d"
>>
>>
>> Hope above solves the pre-requisite because of which 'Tony Lindgren <tony at atomide.com>'
>> was unable to accept cape related DTS into his tree [3]
> 
> Yes. If the capes are disabled by default we can have at
> least some of them included in the mainline kernel and
> enabled by the bootloader as needed. I'd like to hear back
> from the u-boot people too on this approach naturally.
> 
> And some things we still cannot merge if they overlap for
> GPMC bindings for example. So we have to carefully check
> the generated .dtb file with dtc -I dtb -O dts.

This sounds really problematic to me from an end-user horror point of
view.  And fortunately 3.17 is going to have some level of overlay
support so we can set this problem aside (and even treat the am335x gp
evm "profileN" trees as overlays too).

-- 
Tom