Hi, >From: Jason Kridner [mailto:jkridner@xxxxxxxxx] >>On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon@xxxxxx> 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@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 <tony@xxxxxxxxxxx>' was unable to accept cape related DTS into his tree [3] [1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT [2] http://www.spinics.net/lists/linux-omap/msg107307.html [3] http://www.spinics.net/lists/linux-omap/msg107354.html with regards, pekon ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
