BSP/DT clarification: "quill" vs P3310 vs Jetson TX2 SOM

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

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:

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,

#include <t18x-common-platforms/tegra186-quill-camera-modules.dtsi>

(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 Powermon configuration file for INA3221 on TX2 - Jetson TX2 - NVIDIA Developer Forums )

1 Like
2

The TX2 is the tegra 18x SoC series…the t186 is a specific implementation found on a Jetson TX2 (and perhaps other places). The 21x series is the TX1, the t210 is the specific implementation of the TX1 used in the Jetson. The t12x series is the K1, and the t124 is the specific implementation in the Jetson TK1. You will find each has some parts in common, so for example you might see a reference to a t21x kernel file used in the t18x series SoC.

Quill is another name for the TX2 SoC (I’m not positive, but this probably applies to the module as a whole…someone else may be able to provide better information). You’ll usually see it in combination with other labels for the type of module it is connected to, along with yet more labels for the carrier board type it is plugged in to.

When you look at a device tree file it implies you are interested in hardware of the SoC (tegra186-quill), the module it is on (tegra186-quill-p3310), and the carrier it is mounted to (perhaps tegra-186-quill-p3310-c03-00-base.dtb).

Historically you will find that many parts of older Tegra SoCs are inherited from when creating a newer Tegra model…but then extended. An example might be that the same GPIO controller is used going far back in time, yet a newer Tegra release has more GPIO…this is done by adding more exactly matching controllers instead of creating everything new from scratch (this has a big advantage in testing and compatibility and bring-up time). Code which works for a TK1 GPIO might be an exact drop-in match on a TX2 right down to the controller base physical address…though there might be more controllers at a new address which did not previously exist.

Note that although building the device tree is part of the kernel source it doesn’t actually embed directly into the kernel anywhere. The “make dtbs” target might choose different things to build depending on the “.config” file, but in reality choosing which dtb file to use is independent. What it does in the end under R28.1 is copy it to mmcblk0p15 partition with NULL byte padding on the end to match the partition size. It used to be the extlinux.conf FDT key/value entry could do this, but this changed at R28.1 when the TX1 and TX2 began using the same sample rootfs for the first time.

I think it was quite some time back there was concern about having a larger kernel due simply to individual settings of different specific hardware…and because of this some of the settings which could be made generic began referring to names which would be mapped from a custom device tree while keeping the drivers themselves more generic regardless of what register or other setting an individual peripheral might require. Think of the device tree as the glue between a generic driver and specific hardware settings which might be optional depending on what the SoC or motherboard connects to. Any time you see optional hardware which is in common to some other board (and using the same driver) there is a chance you will simply see that part of the device tree inherited instead of “reinventing the wheel”.

3

Thanks for your reply. I did know the t18x/t21x/t12x and associated specific nomenclature, and I had seen that there were some “tegra210” devices mentioned in the t186 device tree.

I do understand not wanting to reinvent the wheel - in fact, most of my issue I was having with the device trees is that it was making me reinvent, or at least repeat, the wheel when I’d really rather just include the modules of the wheel :) The include hierarchy is deep instead of broad, which means if I want to change something in a module, it might be “mid-level” included meaning I have to modify (I’d rather not directly modify upstream sources…) or duplicate and modify that module, as well as duplicating and modifying (the include lines of) all modules “above it” in the hierarchy (if the top-level, final dts file is at the “top” logically), in the case where the change I want to make can’t be done with a few /delete-node/, /delete-property/ or simple property overrides in my own high-level dts files.

Still hoping for some clarification, perhaps from someone at NVIDIA, on what quill specifically refers to (my guess is it’s something more specific than just a t186 SOC - either the entire jetson tx2 SOM or something else - because I’ve seen trees for other t186 devices with different codenames, e.g. drive px2), and whether my custom or third-party carrier board should bear a device tree with a root

compatible = "nvidia,quill", "nvidia,tegra186"

property, as it does now (just like “t186ref”), or if it should carry, e.g.

compatible = "cti,orbitty", "nvidia,tegra186"

or perhaps

compatible = "cti,orbitty", "nvidia,quill", "nvidia,tegra186"

Perhaps it seems nitpicky, but I prefer to do things “the right way” since it usually means less hassle in the end.

4

Sorry for reviving an old thread.

I don’t know what ‘quill’ is, but I surmise it is the devkit. Nvidia, can you confirm this ?

But, no matter, I somehow solved the same problem as yours by defining a macro

#define PHDM_BOARD

in my new main .dts file, and hacking the .dts[i] files provided by nvidia to turn off unwanted parts like

#include <t18x-common-platforms/tegra186-quill-camera-modules.dtsi>

with

#ifndef PHDM_BOARD
...
#endif
5

I can’t say for certain, but I suspect “quill” applies to the module being TX2 regardless of whether it is a dev kit carrier board or not. Usually other versions are tacked on to the end of that to designate different carrier boards and revisions.