Hello everyone
My name is Marc, I’m from Spain, and I’m interested in the Generic Device Tree Creator idea.
I’m in the middle of my Computer Science Bachelor, and I collaborate in diverse projects involving PHP and web languages, C on Linux, and Linux Kernel modifications.
I’ve already been talking with Jason, and decided to aim for this project.
I can create a software that will talk with every EEPROM in the capes of the board just after boot, get its device information, and generate valid a Device Tree. Then load it dynamically using capemgr.
EEPROMs won’t have all of the relevant information. The EEPROM format only has information about the pinmuxes. We should be able to read or generate the EEPROM contents.
What is needed is a nice UI that will expose all of the options exposed in the base device trees that aren’t enabled along with a way to enable and configure them.
Not sure if this is a valid example, but it is worth considering for someone new.
See linux/arch/arm/boot/dts/am335x-boneblack.dts at 85cba3adbb111a2198e97944f25eb5f1b97aa3ce · beagleboard/linux · GitHub
&mmc2 {
vmmc-supply = <&vmmcsd_fixed>;
bus-width = <8>;
ti,non-removable;
status = "disabled";
reset = <&rstctl 0 0>;
reset-names = "eMMC_RSTn-CONSUMER";
};
You can see there that the eMMC is disabled in the primary device tree.
There is a “virtual” cape that then overlays and enables the eMMC, specifically at linux/firmware/capes/BB-BONE-eMMC1-01-00A0.dts at 85cba3adbb111a2198e97944f25eb5f1b97aa3ce · beagleboard/linux · GitHub
fragment@1 {
target = <&mmc2>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&emmc2_pins>; /* wrong numbering */
vmmc-supply = <&ldo3_reg>;
bus-width = <8>;
ti,non-removable;
status = "okay";
ti,vcc-aux-disable-is-sleep;
reset = <&rstctl 0 0>;
reset-names = "eMMC_RSTn";
};
};
};
There are two common outputs that could be useful:
- Overlays that can modify the existing tree
- An entirely new tree to replace the existing BeagleBone Black tree (which is quite useful for generating your own fully-custom hardware)
For reproducing a new tree, I very much doubt a simple template approach would be good enough. In many cases, you’ll want to edit existing configurations and replace them with other items. The ideal case is a graphical editor that can parse some kind of super-set device tree, potentially extended with some additional descriptors, and produce any subset, including overlay subsets.
Being very familiar with parsing/compiling technology seems a prerequisite for making a quality device-tree generator, but there can be many useful subsets including purely template-generation subsets. More details on the scope are absolutely required at this point.
BTW, have you read all the docs at Index of /doc/Documentation/devicetree/ and checked out the wiki at http://www.devicetree.org/Main_Page? The wiki gives a link to the mailing list. I’d suggest starting a discussion on that list to help define a useful scope, realizing that many people on that list will likely (similar to me) push for too much.