Devicetree pin_defines type

[pylo]

Hello!

I'm learning about devicetrees for the RPI 4B and the CM4 (and admittedly, also about devicetrees in general), and I see some signals of the VideoCore are defined as either "external" or "absent" when not on the BCM native GPIO.

Example from the CM4:

Code: Select all

            pin_define@LAN_RUN {
               type = "absent";
            };
            pin_define@BT_ON {
               type = "external";
               number = <0>;
            };

What is the difference between external and absent? Absent probably means "not in use / ignored", but then what is external? Also, in the case of external, what is the meaning of "number" / how to interpret it?

(Kind of off-topic: Is it documented somewhere what these signals (LAN_RUN , FLASH_1_ENABLE , USB_LIMIT_1A2 and so on) exactly are / how they are used? Some are obvious but some others are not, it'd be nice if there existed a compiled list with explanations.)

Thanks for any help

[6by9]

"Absent" means that there is no such signal on this platform variant. eg because it has no Bluetooth or ethernet functionality.

"External" means that it is on an external GPIO expander (generally I2C based) rather than using one of the "internal" GPIOs of the SoC. The numbers relate to the output of that expander (generally 0-7).
From Linux you can access those GPIOs via the raspberrypi-exp-gpio driver.

[pylo]

"Absent" means that there is no such signal on this platform variant. eg because it has no Bluetooth or ethernet functionality.

"External" means that it is on an external GPIO expander (generally I2C based) rather than using one of the "internal" GPIOs of the SoC. The numbers relate to the output of that expander (generally 0-7).
From Linux you can access those GPIOs via the raspberrypi-exp-gpio driver.

Regarding "external", that was my first thought too, but then I didn't think this was possible because unrelated pins seem to be mapped to the same external GPIO. For example, on the same CM4:

pin_define@HDMI_CONTROL_ATTACHED {
type = "external";
number = <0>;
};
...
pin_define@BT_ON {
type = "external";
number = <0>;
};

These two signals cannot (shouldn't) be on the same physical pin. So does that mean they are on different GPIO-extender ICs? But then wouldn't the device-tree also need to contain which IC instead of just its pin-number "number"?

[6by9]

Regarding "external", that was my first thought too, but then I didn't think this was possible because unrelated pins seem to be mapped to the same external GPIO. For example, on the same CM4:

pin_define@HDMI_CONTROL_ATTACHED {
type = "external";
number = <0>;
};
...
pin_define@BT_ON {
type = "external";
number = <0>;
};

These two signals cannot (shouldn't) be on the same physical pin. So does that mean they are on different GPIO-extender ICs? But then wouldn't the device-tree also need to contain which IC instead of just its pin-number "number"?

That's an error for CM4, and HDMI_CONTROL_ATTACHED won't be looked at at all.
BCM2711 (ie Pi4 and CM4) has dedicated pins for HDMI hotplug detect for each of the two HDMI interfaces.
Pi4 and Pi400 are correct in listing it as

Code: Select all

            pin_define@HDMI_CONTROL_ATTACHED {
               type = "absent";
            };

Note that dt-blob.bin/dts may have the same semantics as device tree, but it is not device tree.

[pylo]

That's an error for CM4, and HDMI_CONTROL_ATTACHED won't be looked at at all.

Ah, I see, that helps clear things up. Thank you very much for your kind help. One last question:

pin_define@EMMC_ENABLE {
type = "external";
number = <1>;
};
...
pin_define@WL_ON {
type = "external";
number = <1>;
};

Is this also an error? I guess EMMC_ENABLE is somehow implicitly determined based on whether you have a Lite-version of the CM4, and that entry should also be "absent".

[6by9]

Look a few lines up and you'd see

Code: Select all

            pin@p129 { function = "output"; termination = "no_pulling"; }; // WL_ON

The expander starts at offset 128, so 129 is "external" <1>.

Booting has changed significantly from 2710 to 2711.
Read the CM4 datasheet and it documents nRPI_BOOT in section 2.15.

During boot if this pin is low booting from eMMC will be stopped and booting will be transferred to rpi boot which is via
USB.

Chapter 4 lists it as pin 93.

Looking in more detail it appears to be GPIO40 which is used internally to read the SPI bootloader EEPROM, without which the bootrom will default back to USB mode. I believe EMMC_ENABLE is therefore irrelevant for 2711.

[pylo]

Sorry if I was unclear, but yeah, that's what I meant, that WL_ON is OK, and EMMC_ENABLE is "irrelevant" as you say, so its type should be "absent" in the configuration. My point being that WL_ON and EMMC_ENABLE cannot both be on external <1>. Again thanks for clarifying things.