>From: Jason Kridner [mailto:jkridner@xxxxxxxxx] >>On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >>> * Gupta, Pekon <pekon@xxxxxx> [140622 22:42]: >>> >From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] [...] >>> >Based on the recent discussions on the capes, it seems that nobody >>> >wants to implement toggling of the capes in u-boot. And as there >>> >can be other capes using GPMC bus, we can't merge this. >>> >>> I have been able to get toggling of capes (enabling and disabling of DT nodes) >>> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it. >>> >>> Example: Below sequence works for NAND cape patch mentioned in this thread. >>> --------------- >>> /* 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" >> >> Cool. Now all we need is a few helper functions in u-boot >> so it can be done a bit easier :) >> > >The association of devicetree overlay files in /lib/firmware to cape >IDs made it where the kernel-based cape overlay manager could modify >the devicetree as needed without putting extensive cape-specific logic >in the kernel or bootloader. Throwing a bunch of capes into a single >class of capes won't save any work there. > I'm classifying capes based on functionality to reduce the number of DTS files, because in general people will not both LCD4 and LCD7 capes together, similarly not many will use NAND, NOR and eMMC simulataneously. - am335x-bone-memory-cape.dts: will have NAND, NOR and storage related capes - am335x-bone-display-cape.dts: will have LCD4, LCD7, ... etc capes. > If we can get the bootloader >to support the .dtbo files, then we can continue to use the ID in the >cape to provide all the DT modifications we need. If we need to do >scripts for the modifications, we'd still need to associate the cape >ID to that script. > With ID based auto-identification of Capes, we need EEPROM or e-fuses on every cape. And today I don't think all third-party capes have EEPROM on them. Also, with increase in number of cape, it will be hard to maintain ID grouping and updating firmware/software for each new cape. > >This still doesn't cover the need for run-time devicetree >modification, but I'll leave that for the other on-going thread. > I'm just proposing the u-boot way of enabling/disabling DT. This is certainly not replacing requirement for DT overlay manager, But till the time DT overlay is available in kernel, this would at-least be an placeholder and would encourage Beaglebone users to continue using mainline kernel. This why I'm trying to get basic cape DTS in mainline, so that Beaglebone community continues to be in touch with mainline. Tomorrow if DT overlay comes, then we may choose to either keep these cape DTS, or delete them from mainline without breaking any backward compatibility. >I do agree with the idea of moving more of the potential sources of >conflict that can be resolved out of the overlays and into the main >devicetree, leaving the overlays or scripts simply to deal with the >conflicts that cannot be resolved at run-time given the current >infrastructure. I just think they should go into .dtsi (include) files >for the main .dts/.dtb files for the boards, rather than additional >overlays or alternative .dts files. > Yes, that is the main motive, to resolve _known_ conflicts before Run-time. And keep things working till 'DT overlay' is mainlined. Another thing which I'm not sure is how DT overlay will work with capes which are required during boot? Example: NAND, NOR capes themselves containing file-system. I think in such scenarios using u-boot approach for enabling/disabling capes would be beneficial. If you and others are okay with this approach, I would request you to please provide your "Tested-by" for few cape DTS patches I will be posting soon. This would give confidence that cape DTS patches are not breaking anything in existing DTS. Thanks.. with regards, pekon ��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
