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

On 06/26/2014 03:50 AM, Tony Lindgren wrote:

* Gupta, Pekon [off-list ref] [140618 01:52]:

quoted

Hi,

quoted

From: Jason Kridner [mailto:jkridner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]

quoted

On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon [off-list ref] wrote:

quoted

From: Jason Kridner

[...]

quoted

quoted

quoted

quoted

* 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.

quoted

quoted

(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@481d8000
u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc@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 [off-list ref]'
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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.