I’m working on adapting a BSP to a number of different carrier boards, and I have a terminology question. I know that T186 is the tegra x2 “Parker” chip that’s on these Jetson TX2 SOMs. My question is this: What exactly is “quill” (and its’ relatives, such as quill-pb, etc)? If I’m using a third party or custom carrier, should my BSP (device tree files, etc) derived from/inherit from the “Quill” labeled files, just P3310 labeled files (since I note this part number on the modules), or something else?
One issue I’ve run across related to this is that the devicetree files are not very modular: it’s more of a deep “inheritance tree” than “composition” of modules, in a sense: a given file is likely to both a: contain functionality in the literal text in it, and b: include one or more other device tree files . This means that in more cases than I’d like, I (or carrier vendors such as CTI) end up having to duplicate DTS files and modify them, rather than creating new files that just include a different set of includes. For example, the Orbitty board from CTI has a custom BSP that duplicates a lot of existing DTS code: it “logically” is based on:
- device/hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts http://nv-tegra.nvidia.com/gitweb/?p=device/hardware/nvidia/platform/t18x/quill.git;a=blob;f=kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts;h=772a45b639637160e8f15c397b87ef6a01795e6a;hb=l4t/l4t-r28.2-rc which is based on and includes
- tegra186-quill-p3310-1000-a00-00-base.dts http://nv-tegra.nvidia.com/gitweb/?p=device/hardware/nvidia/platform/t18x/quill.git;a=blob;f=kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts;h=f48f2ea26d58be40d383744fe5f99b2400c591ce;hb=l4t/l4t-r28.2-rc which includes a whole pile of files, as well as having lots of content in it
And, so the problem with tegra186-quill-p3310-1000-a00-00-base.dts as a “base” is that if you don’t want the effects of, for instance,
(as is the case for the CTI Orbitty carrier), you can’t just include this file in a custom DTS: even with lots of delete-node and delete-property, the effects of some of these includes, like the camera modules one, are very wide-ranging and hard to “override” out of existence, so you end up with vendors duplicating this tegra186-quill-p3310-1000-a00-00-base.dts file with just some includes changed or commented out, and thus upstream changes made to DTS files never end up affecting the ostensibly-derived custom carriers because of the duplication. (I recently went thru the Orbitty DTS files and tried as far as I could to eliminate duplication of the “upstream” NVIDIA dts files, but I eventually had to give in and duplicate the two files mentioned in the bullet points, explicitly so that I could avoid including the camera modules DTSI which was affecting the combined output far more than I was comfortable experimenting with.)
(Further, that board only has HDMI out, so you’d really like to be able to use something like this: tegra186-quill-hdmi-primary-p3310-1000-c03-00.dts http://nv-tegra.nvidia.com/gitweb/?p=device/hardware/nvidia/platform/t18x/quill.git;a=blob;f=kernel-dts/tegra186-quill-hdmi-primary-p3310-1000-c03-00.dts;h=fc978027ba64bc10233c8b9a840071beb2cb9016;hb=l4t/l4t-r28.2-rc - but that functionality, of setting HDMI primary and disabling other video outputs, is bundled into a single DTS file with an #include “tegra186-quill-p3310-1000-c03-00-base.dts” so you can’t use it as an “overlay”.)
It is this dependence on various connected modules that has me questioning whether “quill” is the codename for just the module sold commercially/on the mass market as the Jetson TX2 SOM (model P3310), or whether it refers to some larger entity. (And whether I should have compatible=“nvidia,quill” in my DT, or something else, when I’m using a non-NVIDIA carrier board, etc) On one hand:
- I see BSP files (device trees, bct configs, etc) mentioning P2597, the model of the "standard" ref board, as well as other apparent reference boards, which would suggest Quill is just the module, but...
- the Quill files include cameras, etc, and there are Quill files with different model numbers (p3489 and e3313) in the public repos...
I know lots of smart folks (who have worked with device tree far longer than me) work at NVIDIA, so it seems unlikely that the device tree is just “organized badly”, and more likely that I’m just misunderstanding the levels of products involved.
Can anyone weigh in and enlighten me? Thank you!
(ps. in the case of device tree structure, I was expecting something a little closer to upstream Linux or for example the rpi 3 device trees: a board device tree https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/bcm2837-rpi-3-b.dts that includes the soc “bcm2837.dtsi”, some board stuff “bcm2835-rpi.dtsi”, peripherals/configs e.g. “bcm283x-rpi-smsc9514.dtsi”, then has a whole variety of “overlays” available to enhance/modify the configuration that generally don’t include the module/board directly: https://github.com/raspberrypi/linux/tree/rpi-4.14.y/arch/arm/boot/dts/overlays - see also this commit message on the “strategy” used for the RPi upstreamed DTS files and overlays https://github.com/raspberrypi/linux/commit/43f9079930eb070443b2fcbdcd01b3c21f1ebc74 )
(pps. I’m not the only one confused - see also https://devtalk.nvidia.com/default/topic/1028632/jetson-tx2/powermon-configuration-file-for-ina3221-on-tx2/ )