Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

DT Overlay to force some GPIOs into HiZ from boot

Tue Feb 27, 2018 2:50 pm

Hi,

I've never played with a device tree overlay but am led to believe that I'll need to write one to force some GPIOs on a Pi 1 B+ to output HiZ from boot.

Can anyone point me in the right direction on how to go about this for GPIO5 for example?

Thanks

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Tue Feb 27, 2018 3:27 pm

For a fuller answer on the electrical characteristics of the Pi GPIO lines you would be better off asking in the Interfacing forum - I'm a software engineer - but my understanding is:

All Pi GPIOs come up as inputs by default. Pins 0-8 pull high, and pins 9-27 pull low. Higher pin numbers have a mixture of default pulls. Pins with pulls enabled have an impedance of 50KOhms, whereas pins with no pull are more like 1MOhm. There is no true HighZ mode. Be aware that a pin with no pull really ought to be driven high or low externally otherwise it will float which can have a negative effect on the chip lifetime because it can become a current source (please don't quote me on this, this is just what I've heard).

The kernel pinctrl subsystem is there to allocate pins to drivers, preconfiguring them to be in the required mode. However it will only do this for an enabled device. In order to use pinctrl to set an arbitrary(*) pin state you need a device to request the state, and its easiest if this is a device which doesn't already use pinctrl. A common choice has been the "leds" driver.

Have a look at the following overlays - dpi18 (or dpi24 or vga666). It creates a pins group under the gpio node requesting a particular state, then adds a reference to it from the leds node. In your case you want to set the pin to be an input with no pull:

Code: Select all

			my_pins_label: my_pins {
				brcm,pins = <5>;
				brcm,function = <0>; /* input */
				brcm,pull = <0>; /* no pull */
			};
The pinctrl-0 property would have to be adjusted to match the label name (the identifier before the colon, which I made different just for clarity - my_pins would have worked just as well):

Code: Select all

			pinctrl-names = "default";
			pinctrl-0 = <&my_pins_label>;
(*) The one bit of state you can't configure is whether an output pin is driving high or low - all outputs will be set to drive low.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Tue Feb 27, 2018 7:16 pm

PhilE wrote:
Tue Feb 27, 2018 3:27 pm
Thanks so much.

A few questions before i jump into the implementation tomorrow:

If i wanted to set a series of GPIOs to hiZ (noted your warnings), would i just fill 'brcm,pins = <5>;' with the bcm gpio pin numbers? so <5,16,17> for e.g. ?

if i use this method, will those gpios be set to input with no pull from boot? the gpio's will turn some hardware on if they're low, so i don't want them to go low at all until manually requested.

Using this method, can i still override the pin state, say to pull down in the userspace later on during run time?

Thanks again.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Tue Feb 27, 2018 8:47 pm

If i wanted to set a series of GPIOs to hiZ (noted your warnings), would i just fill 'brcm,pins = <5>;' with the bcm gpio pin numbers? so <5,16,17> for e.g. ?
Almost - just leave out the commas, so "<5 16 17>;". The rule for the other properties is that there must either be one "brcm,function"/"brcm,pull" (the same rule applies to both but independently) for each pin or a single value for all pins. In other words, if your functions or pulls are all the same then you just need one value, otherwise you need one per pin.
if i use this method, will those gpios be set to input with no pull from boot?
There will be a time lag - they will be inputs immediately, but it will take a few seconds before the pulls are removed - you can time this by adding a weaker external pull (~200kOhms) in the opposite direction and seeing how long it takes the level to change. You can make a change earlier than this but it relies on using a custom dt-blob.bin file (not really Device Tree at all) and that can be a maintenance headache, and even then it isn't instantaneous.
the gpio's will turn some hardware on if they're low, so i don't want them to go low at all until manually requested.
Can you explain what you mean by low? Low impedance, or low voltage? Can you say a bit more about the characteristics and requirements of the external hardware so as to avoid any misunderstanding?
Using this method, can i still override the pin state, say to pull down in the userspace later on during run time?
Yes, that works:

Code: Select all

pi@raspberrypi:~ $ cd /sys/class/gpio/gpiochip0/subsystem
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem $ echo 5 > export
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem $ cd gpio5
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem/gpio5 $ raspi-gpio get 5
GPIO 5: level=0 fsel=0 func=INPUT
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem/gpio5 $ echo out > direction
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem/gpio5 $ raspi-gpio get 5
GPIO 5: level=0 fsel=1 func=OUTPUT
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem/gpio5 $ echo 1 > value
pi@raspberrypi:/sys/class/gpio/gpiochip0/subsystem/gpio5 $ raspi-gpio get 5
GPIO 5: level=1 fsel=1 func=OUTPUT

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 1:07 pm

PhilE wrote:
Tue Feb 27, 2018 8:47 pm
if i use this method, will those gpios be set to input with no pull from boot?
There will be a time lag - they will be inputs immediately, but it will take a few seconds before the pulls are removed - you can time this by adding a weaker external pull (~200kOhms) in the opposite direction and seeing how long it takes the level to change. You can make a change earlier than this but it relies on using a custom dt-blob.bin file (not really Device Tree at all) and that can be a maintenance headache, and even then it isn't instantaneous.
the gpio's will turn some hardware on if they're low, so i don't want them to go low at all until manually requested.
Can you explain what you mean by low? Low impedance, or low voltage? Can you say a bit more about the characteristics and requirements of the external hardware so as to avoid any misunderstanding?
Regarding the time lag, what magnitude are we talking? Less than a second? Could probably get away with something like that. DT blob does sound a bit of a headache, I'll look into it as a last resort.

I'm using a CM3L W/ breakout to control power to six Pi's. the CM3L does this on six GPIOs [5, 16, 17, 25, 32, 33]. Just to confirm, the GPIOs don't power the pi's, it just sets the signals to a power controller. That power controller sets each pi to OFF when the input GPIO signal is hiZ, and ON when the GPIOs are in a pull down state.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 1:14 pm

Can you tell me the part number of the controller? I just want to check that my understanding is correct.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 3:00 pm

PhilE wrote:
Wed Feb 28, 2018 1:14 pm
Can you tell me the part number of the controller? I just want to check that my understanding is correct.
Sorry, i am still learning to ask a question in the most efficient way.

On a CM3L / CM1, we use GPIOs [5, 16, 17, 25, 32, 33] to control 5V to each 'daughter' pi.

Each daughter board has the following setup (for each of the GPIOs listed above): The GPIO signal from the CM goes to the gate of a DMG2305UX P-Channel Enhancement MOSFET. The source of the mosfet is a high current 5V source. The Drain connects directly to a 'daughter' pi's 5V line.

Here's a schematic of what i just described
Untitled.png
Untitled.png (64.18 KiB) Viewed 1333 times
The issue is that some of those GPIOs are in different states at boot, hence I thought a dt overlay of some sort forcing them into a hiZ state (forcing each daughter pi to be 'off' until requested on) should fix things.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1748
Joined: Thu Jul 11, 2013 2:37 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 3:23 pm

I was cc'd to the thread by PhilE...

Your existing setup using a P-fet is not a recommended configuration. The source-gate resistor will pull the voltage on the GPIO up to 5V which will cause current flow through the ESD structure on the GPIO pad - eventually damaging the pin.

Use an open-drain "level shifter" for this purpose (see diagram). The added gate-source resistors will have the benefit of reinforcing the in-pad pulldown resistance and preventing power-on transients from erroneously switching the PMOS device. Note that the NMOS device must have a logic-level threshold voltage - maximum Vt = 2V so it turns on properly from a GPIO high signal.
Attachments
pmos power control.png
pmos power control.png (6.74 KiB) Viewed 1321 times
Rockets are loud.
https://astro-pi.org

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 3:41 pm

Thanks so much for the help.

Currently trying to get a proof of concept going, and the hardware guy has already made a PCB that sits between all the pi's, so would there be a way to get a solution to the original question (gpio's set to a certain state at boot) with my current setup?

I'll certainly take on-board your suggestions for rev 2.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 3:45 pm

The only way to guarantee that GPIOs have the correct state from boot is to design the surrounding circuit so that the correct state is the default for that GPIO. Using a dt-blob you will be able to reduce the length of startup glitch to around a second, maybe less (I told you how to measure the delay).

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 4:36 pm

PhilE wrote:
Wed Feb 28, 2018 3:45 pm
The only way to guarantee that GPIOs have the correct state from boot is to design the surrounding circuit so that the correct state is the default for that GPIO. Using a dt-blob you will be able to reduce the length of startup glitch to around a second, maybe less (I told you how to measure the delay).
Ok, i'll see what mods i can do to change the hardware.

How hard is it to setup a dt blob for this purpose?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 4:44 pm

Fairly easy - grab the template, rename it (say) "dt-blob.dts", change the state of the relevant pins in the "pins_cm3" section to (e.g.):

Code: Select all

        pin@p5  { function = "input";   termination = "no_pulling";    } // HighZ
Compile the resulting file:

Code: Select all

pi@raspberrypi:~$ dtc -I dts -O dtb -o dt-blob.bin dt-blob.dts
Finally, copy it to /boot:

Code: Select all

pi@raspberrypi:~$ sudo cp dt-blob.bin /boot
To revert the changes just delete the file - the default is compiled into the firmware files.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 5:52 pm

PhilE wrote:
Wed Feb 28, 2018 4:44 pm
Fairly easy - grab the template, rename it (say) "dt-blob.dts", change the state of the relevant pins in the "pins_cm3" section to (e.g.):

Code: Select all

        pin@p5  { function = "input";   termination = "no_pulling";    } // HighZ
Compile the resulting file:

Code: Select all

pi@raspberrypi:~$ dtc -I dts -O dtb -o dt-blob.bin dt-blob.dts
Finally, copy it to /boot:

Code: Select all

pi@raspberrypi:~$ sudo cp dt-blob.bin /boot
To revert the changes just delete the file - the default is compiled into the firmware files.
Thanks again, that is much easier than i imagined (since you spelled it out for me)

Just having a go now, i noticed that blob should be fine for both a cm1 and cm3, but would it also work on a pi1 / 2 ? I assume not, but i couldn't find any other .dts files in the repo.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 5:56 pm

One dt-blob.bin can cater for all included platforms, but the required changes have to be made in each of the relevant named sections for the targeted platforms. If you want to target regular Pis you will need to obtain and patch the full dt-blob.dts source (not just this cut-down version) otherwise the excluded platforms won't boot.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 6:08 pm

PhilE wrote:
Wed Feb 28, 2018 5:56 pm
One dt-blob.bin can cater for all included platforms, but the required changes have to be made in each of the relevant named sections for the targeted platforms. If you want to target regular Pis you will need to obtain and patch the full dt-blob.dts source (not just this cut-down version) otherwise the excluded platforms won't boot.
Ok, so as i understand, to do the same mod to a pi 1 or 2 i'll need to get the full dt blob source and patch that (the same way you described above, just to a different file with definitions for pi 1 and 2). If so, any idea where i can obtain the full blob.dts source, or is it closed source?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 6:35 pm


Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 7:15 pm

Looking at the pi 1 b+ below

Code: Select all

     pins_bplus2 { // Pi 1 Model B+ rev 1.2
         pin_config {
            pin@default {
               polarity = "active_high";
               termination = "pull_down";
               startup_state = "inactive";
               function = "input";
            }; // pin
            pin@p14 { function = "uart0";  termination = "no_pulling"; drive_strength_mA = < 8 >; }; // TX uart0
            pin@p15 { function = "uart0";  termination = "pull_up"; drive_strength_mA = < 8 >; }; // RX uart0
            pin@p28 { function = "input";   termination = "pull_up";    }; // I2C 0 SDA
            pin@p29 { function = "input";   termination = "pull_up";    }; // I2C 0 SCL
            pin@p31 { function = "output"; termination = "pull_down";  startup_state = "active"; }; // LAN_RUN
            pin@p32 { function = "output"; termination = "pull_down"; }; // Camera LED
            pin@p35 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Power low
            pin@p38 { function = "output"; termination = "no_pulling";    }; // USB current limit (0=600mA, 1=1200mA)
            pin@p40 { function = "pwm";    termination = "no_pulling"; drive_strength_mA = < 16 >; }; // Right audio
            pin@p41 { function = "output"; termination = "no_pulling";    }; // Camera shutdown
            pin@p44 { function = "gp_clk"; termination = "pull_down"; }; // ETH_CLK - Ethernet 25MHz output
            pin@p45 { function = "pwm";    termination = "no_pulling"; drive_strength_mA = < 16 >; }; // Left audio
            pin@p46 { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Hotplug
            pin@p47 { function = "output"; termination = "pull_down"; }; // activity LED
            pin@p48 { function = "sdcard"; termination = "pull_up";    drive_strength_mA = < 8 >; }; // SD CLK
            pin@p49 { function = "sdcard"; termination = "pull_up";    drive_strength_mA = < 8 >; }; // SD CMD
            pin@p50 { function = "sdcard"; termination = "pull_up";    drive_strength_mA = < 8 >; }; // SD D0
            pin@p51 { function = "sdcard"; termination = "pull_up";    drive_strength_mA = < 8 >; }; // SD D1
            pin@p52 { function = "sdcard"; termination = "pull_up";    drive_strength_mA = < 8 >; }; // SD D2
            pin@p53 { function = "sdcard"; termination = "pull_up";    drive_strength_mA = < 8 >; }; // SD D3
         }; // pin_config

         pin_defines {
            pin_define@HDMI_CONTROL_ATTACHED {
               type = "internal";
               number = <46>;
            };
            pin_define@NUM_CAMERAS {
               type = "internal";
               number = <1>;
            };
            pin_define@CAMERA_0_I2C_PORT {
               type = "internal";
               number = <0>;
            };
            pin_define@CAMERA_0_SDA_PIN {
               type = "internal";
               number = <28>;
            };
            pin_define@CAMERA_0_SCL_PIN {
               type = "internal";
               number = <29>;
            };
            pin_define@CAMERA_0_SHUTDOWN {
               type = "internal";
               number = <41>;
            };
            pin_define@CAMERA_0_UNICAM_PORT {
               type = "internal";
               number = <1>;
            };
            pin_define@CAMERA_0_LED {
               type = "internal";
               number = <32>;
            };
            pin_define@FLASH_0_ENABLE {
               type = "absent";
            };
            pin_define@FLASH_0_INDICATOR {
               type = "absent";
            };
            pin_define@FLASH_1_ENABLE {
               type = "absent";
            };
            pin_define@FLASH_1_INDICATOR {
               type = "absent";
            };
            pin_define@POWER_LOW {
               type = "internal";
               number = <35>;
            };
            pin_define@LEDS_DISK_ACTIVITY {
               type = "internal";
               number = <47>;
            };
            pin_define@LAN_RUN {
               type = "internal";
               number = <31>;
            };
            pin_define@SMPS_SDA {
               type = "absent";
            };
            pin_define@SMPS_SCL {
               type = "absent";
            };
            pin_define@ETH_CLK {
               type = "internal";
               number = <44>;
            };
            pin_define@USB_LIMIT_1A2 {
               type = "internal";
               number = <38>;
            };
            pin_define@SIO_1V8_SEL {
               type = "absent";
            };
            pin_define@PWML {
               type = "internal";
               number = <45>;
            };
            pin_define@PWMR {
               type = "internal";
               number = <40>;
            };
            pin_define@SAFE_MODE {
               type = "internal";
               number = <3>;
            };
            pin_define@SD_CARD_DETECT {
               type = "absent";
            };
            pin_define@ID_SDA {
               type = "internal";
               number = <0>;
            };
            pin_define@ID_SCL {
               type = "internal";
               number = <1>;
            };
            pin_define@DISPLAY_I2C_PORT {
               type = "internal";
               number = <0>;
            };
            pin_define@DISPLAY_SDA {
               type = "internal";
               number = <28>;
            };
            pin_define@DISPLAY_SCL {
               type = "internal";
               number = <29>;
            };
         }; // pin_defines
      }; // pins
noticing that GPIOs 17, 5, 16, 33 and 25 don't have 'pin@xx' defs, nor one of the unique 'pin_define@xxx' defs. Is it a matter of adding a line like:

Code: Select all

pin@p17  { function = "input";   termination = "no_pulling";    } // HighZ
pin@p5  { function = "input";   termination = "no_pulling";    } // HighZ
pin@p16  { function = "input";   termination = "no_pulling";    } // HighZ
pin@p33 { function = "input";   termination = "no_pulling";    } // HighZ
pin@p25 { function = "input";   termination = "no_pulling";    } // HighZ
With pin 32, i've noticed it's been assigned as the camera LED signal:

Code: Select all

pin@p32 { function = "output"; termination = "pull_down"; }; // Camera LED

            pin_define@CAMERA_0_LED {
               type = "internal";
               number = <32>;
            };
The lack of a camera LED doesn't bother me - would it be ok if i comment the 'pin_define' and edit the 'pin@p32' to my desired behaviour, like so:

Code: Select all

pin@p32 { function = "input"; termination = "no_pulling"; }; // HiZ
Thanks

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 7:24 pm

Your method for adding new pin declarations is correct. However, only GPIOs 0-27 are brought out onto the standard 40-pin header, so you can't use GPIO32. Be careful to distinguish between GPIO number and header pin number - the dt-blob works in GPIO numbers, despite how it may look.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 7:29 pm

PhilE wrote:
Wed Feb 28, 2018 7:24 pm
Your method for adding new pin declarations is correct. However, only GPIOs 0-27 are brought out onto the standard 40-pin header, so you can't use GPIO32. Be careful to distinguish between GPIO number and header pin number - the dt-blob works in GPIO numbers, despite how it may look.
I am just testing this method quickly on a pi 1 B+ and will use 32 33 on the CM tomorrow when i get all of the hardware :)

It should still change the behaviour of the pin as defined in the blob for the pin from the bcm8235 despite it not being pulled out, right?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Feb 28, 2018 7:32 pm

It should still change the behaviour of the pin as defined in the blob for the pin from the bcm8235 despite it not being pulled out, right?
Yes, the GPIOs will do as they're told, regardless of whether it's sensible or not.

Killertechno
Posts: 130
Joined: Wed Jan 02, 2013 8:28 am

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Apr 04, 2018 8:30 am

Oh my God!!!
Sorry guys, I'm becaming crazy........ I'm not aware about device-trees, then I come here and I find Raspberry device-tree different to ones I was used to.

Ok, please tell me if I'm correct or wrong:
- there is default (hardware) configuration provided in image I download from raspberry.org (obviously)
- I can make custom hardware configuration during kernel re-compilation using device-tree (I'm enough sure)
- I can set different hardware configuration compiling "on the fly" minimal-cm-dt-blob.dts (just for CM), while if I need same thing for previous versions (Raspberry not CM) I need this file instead: github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts, right?
- about setting GPIO pins at boot (pull-up/down, in/out) I can't do this through /boot/config.txt, is this right?

Thanks.

Killertechno
Posts: 130
Joined: Wed Jan 02, 2013 8:28 am

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Apr 04, 2018 8:49 am

Another question:

file dt-blob.dts

Code: Select all

pin@p16 { function = "output"; termination = "pull_up"; polarity="active_low"; }; // activity LED
...
pin_define@LEDS_DISK_ACTIVITY {
               type = "internal";
               number = <16>;
};
...
In this case I suppose I'm setting LED on Raspberry Pi: I set GPIO16 as output, active low with pull-up.
Then I assign GPIO16 to disk activity LED.

If I would like to have 2 disk activity LEDs, can I do this:

Code: Select all

pin@p5 { function = "output"; termination = "pull_down";polarity="active_high"; }; // CAM_LED -> my second activity led
pin@p16 { function = "output"; termination = "pull_up"; polarity="active_low"; }; // activity LED
...
pin_define@LEDS_DISK_ACTIVITY {
               type = "internal";
               number = <5>;
};
pin_define@LEDS_DISK_ACTIVITY {
               type = "internal";
               number = <16>;
};
to drive a second activity LED instead camera LED?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Apr 04, 2018 8:50 am

Ok, please tell me if I'm correct or wrong:
- there is default (hardware) configuration provided in image I download from raspberry.org (obviously)
Yes, the kernel images are supplied with Device Tree files (*.dtb) for the main Pi models.
- I can make custom hardware configuration during kernel re-compilation using device-tree (I'm enough sure)
Yes, but that's not the best way to go about it. First of all, although the DT source files live in the kernel source tree you don't need to rebuild the whole kernel - "make ARCH=arm dtbs" is enough after the configuration steps (you may already have known this, but I wanted to be clear to other readers). Secondly, if you create a custom dtb then you may need to modify it with every kernel release we make in order to stay compatible (in practise it would be nothing like as bad as that, but the possibility exists). See my next answer for the third part.
- I can set different hardware configuration compiling "on the fly" minimal-cm-dt-blob.dts (just for CM), while if I need same thing for previous versions (Raspberry not CM) I need this file instead: github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts, right?
No, ignore the unfortunate name - dt-blob.dts is not Device Tree. It's compiled using the same tools, and the purpose is similar (hardware configuration), but it is read by the firmware and only used to configure pins and clocks.

The correct way to create a custom Device Tree (and this is the third point from above) is to write an overlay, or to use one of the many (130+) that others have contributed to the standard firmware images.
- about setting GPIO pins at boot (pull-up/down, in/out) I can't do this through /boot/config.txt, is this right?
Nope, that's also incorrect now if you are running firmware dated 22nd March 2018 or later. There is now a "gpio" config setting that allows GPIOs to be set to inputs, outputs and Alt functions, driven high or low (for outputs) and with pulls (for inputs). It is described in this forum post.

You can update to a firmware that supports the new setting by running "sudo rpi-update" - it will install a 4.14 kernel and the new firmware. If you don't want to change the kernel you can run "sudo SKIP_KERNEL=1 rpi-update" instead.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1616
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Apr 04, 2018 9:19 am

Code: Select all

pin_define@LEDS_DISK_ACTIVITY {
               type = "internal";
               number = <5>;
};
pin_define@LEDS_DISK_ACTIVITY {
               type = "internal";
               number = <16>;
};
No, this won't work - the second definition will overwrite the first. Think of nodes - "name { ... }" - as being directories and properties - "name = ..." - as being files, and you are asking it create files of the same name inside directories of the same name (i.e. the same files) with different contents. Besides, the firmware is only expecting a single pin for each role.

After booting the LEDs are (largely) driven from Linux, which gets the configuration details from DT - see here to see the 3B+ LED declarations. If you really want multiple activity LEDs you can create an overlay to put additional declarations into that node, something like:

Code: Select all

/dts-v1/;
/plugin/;

/{
	compatible = "brcm,bcm2835";

	fragment@0 {
		target = <&leds>;
		__overlay__ {
			act2_led: act2 {
				label = "led2";
				linux,default-trigger = "mmc0";
				gpios = <&gpio 4 0>;
			}
		};
	};

	__overrides__ {
		gpio = <&act2_led>,"gpios:4";
		activelow = <&act2_led>,"gpios:8";
		trigger = <&act2_led>,"linux,default-trigger";
	};
};

Killertechno
Posts: 130
Joined: Wed Jan 02, 2013 8:28 am

Re: DT Overlay to force some GPIOs into HiZ from boot

Wed Apr 04, 2018 2:15 pm

Ok, first of all thanks for answer(s), I'm starting to study...
if you are running firmware dated 22nd March 2018 or later.
???
Latest image I can find is:
Raspbian Stretch Lite
Minimal image based on Debian Stretch
Version: March 2018
Release date: 2018-03-13
Kernel version: 4.9

or new firmware available only through update?

Return to “Device Tree”

Who is online

Users browsing this forum: No registered users and 3 guests