pylo
Posts: 7
Joined: Fri Apr 23, 2021 8:08 pm

Devicetree pin_defines type

Thu Apr 29, 2021 12:57 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12997
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Devicetree pin_defines type

Thu Apr 29, 2021 8:58 am

"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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

pylo
Posts: 7
Joined: Fri Apr 23, 2021 8:08 pm

Re: Devicetree pin_defines type

Thu Apr 29, 2021 1:46 pm

6by9 wrote:
Thu Apr 29, 2021 8:58 am
"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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12997
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Devicetree pin_defines type

Thu Apr 29, 2021 1:56 pm

pylo wrote:
Thu Apr 29, 2021 1:46 pm
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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

pylo
Posts: 7
Joined: Fri Apr 23, 2021 8:08 pm

Re: Devicetree pin_defines type

Thu Apr 29, 2021 2:21 pm

6by9 wrote:
Thu Apr 29, 2021 1:56 pm
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12997
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Devicetree pin_defines type

Thu Apr 29, 2021 4:49 pm

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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

pylo
Posts: 7
Joined: Fri Apr 23, 2021 8:08 pm

Re: Devicetree pin_defines type

Thu Apr 29, 2021 5:41 pm

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.

Return to “Advanced users”