Generic Device Tree Creator

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.

Waiting for feedback

Thanks
Marc

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

I’ve skimmed over that documentation, I have to read it carefully.

Probably the starting point would be to generate a set of libraries to convert from/to device trees in files to/from data structures. Probably a bit of the code can be taken from the Linux Kernel (if it is not very mixed with the data processing). From this data structures, if properly defined, it should be easy to change a specific parameter.

At first I was thinking in C programming, but this probably would be better in a higher level language. Probably object orientation would simplify the data handling. I already have experience in data parsing and OO, but only small knowledge of usual user aplication languages like C++ or Python.

About the mailing list, I’ll send the basic idea. But most likely they will ask for lots of features.

One feature that I think would make a tool like that really valuable would be the ability to generate both a DT overlay and EEPROM data from the same input config file.

In the device tree mailing list, they point out Xilinx and Altera as
device-tree generators that extract information.

On the other side, I found another project that suits me better, and I
think I'll apply for that other. Thank you for your time, and I expect
somebody can continue this line of work.

Regards
Marc