samskiter
Posts: 24
Joined: Wed Aug 12, 2015 6:18 pm

Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 3:03 pm

So I've run into this problem previously and just avoided the pins I couldn't adjust but now I have no choice.

When changing some of the pin setups in my device tree file, the change seems to be ignored, or overwritten during device boot.

It seems to be the pins associated with the Camera that cause this so I wonder if there is some overlay causing it...

Here's my device tree file. The pin I'm having trouble with is 28 - I'd like it to be an output but it keeps coming up as an input.

Code: Select all

/dts-v1/;

/ {
  videocore {

    pins_cm {

      pin_config {

        [email protected] {
          polarity = "active_high";
          termination = "pull_down";
          startup_state = "inactive";
          function = "input";
        }; // pin

        // BANK 0 - USER GPIO //
        [email protected]  { function = "input";   termination = "pull_up";    }; // GPU WILL USE THIS PIN FOR CAMERA 0 I2C0 SDA
        [email protected]  { function = "input";   termination = "pull_up";    }; // GPU WILL USE THIS PIN FOR CAMERA 0 I2C0 SCL
        [email protected]  { function = "i2c1";    termination = "pull_up";    }; // PERIPHERAL I2C1 SDA
        [email protected]  { function = "i2c1";    termination = "pull_up";    }; // PERIPHERAL I2C1 SCL
        [email protected]  { function = "input";   termination = "pull_up";    }; // SW_SENSE - ACTIVE LOW
        [email protected]  { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected]  { function = "output";  termination = "pull_up";    polarity = "active_high"; startup_state = "active";   }; // PWR_KILL *IMPORTANT*
        [email protected]  { function = "input";   termination = "pull_up";    }; // DEFAULT STATE
        [email protected]  { function = "output";  termination = "no_pulling"; }; // CAM_EN GPU WILL USE THIS PIN FOR CAMERA 0 SHUTDOWN
        [email protected]  { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE

        // LED ENABLES
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive"; }; // LED1_BR2
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive"; }; // LED2_BR2

///////////////////////////////////////////
// TO ENABLE UART0 UNCOMMENT THESE 2 LINES:
//       [email protected] { function = "uart0";   termination = "no_pulling"; }; // UART0 TX
//       [email protected] { function = "uart0";   termination = "pull_up";    }; // UART0 RX
// AND COMMENT OUT/REMOVE THESE 2 LINES:
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
///////////////////////////////////////////
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "output";  termination = "no_pulling"; }; // GPU WILL USE THIS PIN FOR CAMERA 0 LED
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE

        // BANK 1 - USER GPIO//
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high";  startup_state = "inactive";  }; // Status LED
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE
        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE

        // LED BRIGHTNESS
        [email protected] { function = "input";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive"; }; // LED1_BR0
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive"; }; // LED2_BR0
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive"; }; // LED1_BR1
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive"; }; // LED2_BR1

        // MOTOR SENSORS
        [email protected] { function = "input";   termination = "pull_up";    polarity = "active_low";    }; // MOTX_FAULT
        [email protected] { function = "input";   termination = "pull_up";    polarity = "active_low";    }; // MOTY_FAULT
        [email protected] { function = "input";   termination = "pull_up";    polarity = "active_low";    }; // X_LEFT_OPTO
        [email protected] { function = "input";   termination = "pull_up";    polarity = "active_low";    }; // X_RIGHT_OPTO
        [email protected] { function = "input";   termination = "pull_up";    polarity = "active_low";    }; // Y_FRONT_OPTO
        [email protected] { function = "input";   termination = "pull_up";    polarity = "active_low";    }; // Y_REAR_OPTO
        [email protected] { function = "output";  termination = "pull_down";  polarity = "active_high"; startup_state = "inactive";  }; // OPTO_EN

        [email protected] { function = "input";   termination = "pull_down";  }; // DEFAULT STATE

        // BANK 2 - DON'T TOUCH UNLESS YOU KNOW WHAT YOU'RE DOING //
        [email protected] { function = "input";   termination = "no_pulling"; drive_strength_mA = <8>; polarity = "active_high"; }; // HPD_N
        [email protected] { function = "output";  termination = "no_pulling"; drive_strength_mA = <8>; polarity = "active_low"; startup_state = "active"; }; // STATUS LED / EMMC_DISABLE_N CONTROL
        [email protected] { function = "sdcard";  termination = "pull_up";    drive_strength_mA = <8>; }; // SD CLK
        [email protected] { function = "sdcard";  termination = "pull_up";    drive_strength_mA = <8>; }; // SD CMD
        [email protected] { function = "sdcard";  termination = "pull_up";    drive_strength_mA = <8>; }; // SD D0
        [email protected] { function = "sdcard";  termination = "pull_up";    drive_strength_mA = <8>; }; // SD D1
        [email protected] { function = "sdcard";  termination = "pull_up";    drive_strength_mA = <8>; }; // SD D2
        [email protected] { function = "sdcard";  termination = "pull_up";    drive_strength_mA = <8>; }; // SD D3

      }; // pin_config

      pin_defines {
          [email protected]_CAMERAS { type = "internal"; number = <1>; };
          [email protected]_0_LED { type = "internal"; number = <21>; };
          [email protected]_0_SHUTDOWN { type = "internal"; number = <8>; };
          [email protected]_0_UNICAM_PORT { type = "internal"; number = <1>; };
          [email protected]_0_I2C_PORT { type = "internal"; number = <0>; };
          [email protected]_0_SDA_PIN { type = "internal"; number = <0>; };
          [email protected]_0_SCL_PIN { type = "internal"; number = <1>; };
          // [email protected]_1_LED { type = "internal"; number = <30>; };
          // [email protected]_1_SHUTDOWN { type = "internal"; number = <31>; };
          // [email protected]_1_UNICAM_PORT { type = "internal"; number = <0>; };
          // [email protected]_1_I2C_PORT { type = "internal"; number = <0>; };
          // [email protected]_1_SDA_PIN { type = "internal"; number = <28>; };
          // [email protected]_1_SCL_PIN { type = "internal"; number = <29>; };
      }; // pin_defines

    }; // pins_cm

  };

};
You can see that I have recently sanity-tested that I am compiling the DTS file properly by changing pin 34 from an output to an input... You can also see that 28 also used to be a camera SDA pin. The previous problems I had were that SDA/SCL1 was always assigned to GPIO 2&3 meaning that I had to move CAM_EN elsewhere.

Is there any way I can debug this or anywhere I should be looking?

UPDATE:

So I read here that:
start.elf takes over and is responsible for further system setup and booting up the ARM processor subsystem, and contains the firmware that runs on the various parts of the GPU. It first reads dt-blob.bin to determine initial GPIO pin states and GPU-specific interfaces and clocks, then parses config.txt. It then loads an ARM device tree file (e.g. bcm2708-rpi-cm.dtb for a Compute Module) and any device tree overlays specified in config.txt before starting the ARM subsystem and passing the device tree data to the booting Linux kernel.
I had a look on my Pi and found that I don't have bcm2708-rpi-cm.dtb. In fact I also edited my config.txt to have `dtdebug=on` set and then used `sudo vcdbg log msg` and saw "013192.052: Failed to load DTB file 'bcm2708-rpi-cm.dtb'" in the log message.

In it's absence would bcm2708-rpi-b.dtb be loaded instead?

I looked here, at it's source and see that some of my tricky pins are listed. Do I need to compile and include https://github.com/raspberrypi/linux/bl ... rpi-cm.dts and also modify it to suite my needs?
Last edited by samskiter on Wed Jan 06, 2016 3:22 pm, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7431
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 3:19 pm

The GPU I2C driver dynamically pin muxes the defined pins between ALT0 and INPUT, so it appears you are triggering something to poll I2C on pins 28/29, and it is putting it back to input afterwards.
There was a bug in the HAT probe code that did something weird with GPIO muxing. What firmware are you running? Please try the latest.

It's just possible it is the display probing - you could try adding "ignore_lcd=1" to config.txt which memory says should disable the display totally, although I thought it was set by default on the CM (it is on the A and B).
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.

samskiter
Posts: 24
Joined: Wed Aug 12, 2015 6:18 pm

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 3:26 pm

Thanks for the quick reply. I added some information to my first post that may be relevant. Current firmware:

Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux

Not sure how far behind I am, but I assume I am behind. What's the latest firmware version?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7431
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 3:59 pm

April 2015?! A long way behind!
The potentially unstable releases are at https://github.com/raspberrypi/firmware/commits/master - latest 19th Dec 2015.
The latest stable Raspbian release was Nov 2015, and bumped up to using the Jessie branch. There's also Jessie Lite for the smaller footprint.
"vcgencmd version" will tell you the GPU firmware version, but I suspect that will be the same April 2015 as that and the kernel normally have to at least roughly track.

It sounds like you're hitting https://github.com/raspberrypi/linux/issues/1144, but I can't remember exactly when HATs came and and so when that side of things changed.
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.

samskiter
Posts: 24
Joined: Wed Aug 12, 2015 6:18 pm

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 4:08 pm

Yes 9 months off is a long way in RPi land I suppose. Just ran rpi-update and seeing much better control of the GPIO pins. But now need to carefully test the system after such a fundamental change.

Thanks for your help.

The only other change I would like to do is adjust a GPIO *before* the DTS kicks in. I'd like to make sure that pins 12/13/34/35/36/37 show a logic 0 on boot. My previous experiments showed that the pulling resistors are remembered immediately on boot, so I suspect my pulling resistor is the wrong way round. Are the pulling resistors assigned in the DT ignored if the function is set to output? If so I might need to set it to input and then flip to output in sofware later on.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7431
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 4:24 pm

Taking an old image and doing an rpi-update will only have changed the kernel and GPU firmware. All your installed packages will have stayed the same (need an "apt-get udpate", "apt-get upgrade" to do that bit).
Even so you will have jumped significantly in kernel from about 3.18.11 to 4.1.15.

GPIO state at power on really depends on the GPIO state defined in the BCM2835 hardware spec. https://www.raspberrypi.org/wp-content/ ... herals.pdf page 102 is I think the official list of default pulls. Processing of dt-blob.bin is done in software on the GPU.
PhilE may be along in a moment to confirm, or there are other discussions about this on these forums. Pins 35 & 36 look to be your only problem - those default to pulled up.

If you take the diagram on page 89 at face value, then the pull ups are still active when set as an output, but the output driver will override those. Pull state is not the same as initial state when switched to output mode.
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.

samskiter
Posts: 24
Joined: Wed Aug 12, 2015 6:18 pm

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 4:32 pm

6by9 wrote:Taking an old image and doing an rpi-update will only have changed the kernel and GPU firmware. All your installed packages will have stayed the same (need an "apt-get udpate", "apt-get upgrade" to do that bit).
Even so you will have jumped significantly in kernel from about 3.18.11 to 4.1.15.
Indeed. I'll be avoiding any more major changes to the system for now.
6by9 wrote: GPIO state at power on really depends on the GPIO state defined in the BCM2835 hardware spec. https://www.raspberrypi.org/wp-content/ ... herals.pdf page 102 is I think the official list of default pulls. Processing of dt-blob.bin is done in software on the GPU.
PhilE may be along in a moment to confirm, or there are other discussions about this on these forums. Pins 35 & 36 look to be your only problem - those default to pulled up.
34 too... I'd also seen on page 100 that the pull-ups are remembered:
Note that it is not possible to read back the current Pull-up/down settings and so it is the
users’ responsibility to ‘remember’ which pull-up/downs are active. The reason for this is
that GPIO pull-ups are maintained even in power-down mode when the core is off, when
all register contents is lost.
I hope this extends to pull-downs and is simply a shortening
6by9 wrote:
If you take the diagram on page 89 at face value, then the pull ups are still active when set as an output, but the output driver will override those. Pull state is not the same as initial state when switched to output mode.
Yes, they should be still active, I just wonder whether a software layer somewhere in the Device Tree system has optimised this to say "well you're setting this as an output, so why do you care what the pull-ups are"

samskiter
Posts: 24
Joined: Wed Aug 12, 2015 6:18 pm

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 5:57 pm

Hmm, it's slowly dawning on me that I've probably misunderstood the peripherals document and then subsequently fluked a test...

My understanding was that "GPIO pull-ups are maintained even in power-down mode when the core is off, when all register contents is lost." Meant that my pulling states would be persisted through a power cycle. I even tested it and got some convincing graphs:

Start up with pull down resistor from previous boot, then drive high output:
https://drive.google.com/file/d/0B_NPHu ... FrWEU/view
Start up with pull up resistor from previous boot, then drive high output:
https://drive.google.com/file/d/0B_NPHu ... g1aXc/view

I suppose if I didn't give the chip chance to fully discharge, the pulling resistors might have been 'remembered' across power cycles.

Looks like we got incredibly lucky on pin 6 as it needs to be high very soon after the power comes up in order to keep the Pi on.

User avatar
rpdom
Posts: 15418
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 6:31 pm

samskiter wrote:My understanding was that "GPIO pull-ups are maintained even in power-down mode when the core is off, when all register contents is lost." Meant that my pulling states would be persisted through a power cycle.
I believe this has been discussed previously, and the phrase "power-down mode" meant when the cores were shut down but power was still connected to the chip. When power is removed and reapplied, the pulls revert to the defaults.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7431
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Some GPIOs ignored in device tree on Compute Module

Wed Jan 06, 2016 9:14 pm

rpdom wrote:
samskiter wrote:My understanding was that "GPIO pull-ups are maintained even in power-down mode when the core is off, when all register contents is lost." Meant that my pulling states would be persisted through a power cycle.
I believe this has been discussed previously, and the phrase "power-down mode" meant when the cores were shut down but power was still connected to the chip. When power is removed and reapplied, the pulls revert to the defaults.
Sounds about right. Remember this chip was originally designed for mobile phones, so has numerous levels of suspend and powering down of hardware blocks, and that includes powering down the GPU processor cores.
There is no way I can think that any settings will persist over the power being fully pulled, or probably over soft reset using the RUN pin (but don't quote me on that one).
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.

paulv
Posts: 558
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

Re: Some GPIOs ignored in device tree on Compute Module

Thu Jan 07, 2016 7:08 am

The pull settings are indeed maintained through a sudo reboot, sudo poweroff and the reset through J6 or the shorting of P1-5 (GPIO-3/SCL0) to ground.

This is why only making the Pi powerless is a real reset for the GPIO pull settings.

Be aware when you use gpio.cleanup() though because that code does not put the pull's back into their original default state after a power-up anymore. The code did not keep up with the kernel changes from well over a year ago, when the default state was no-pull for the really general purpose gpio's, and that included GPCLK0/GPIO-4, CE0/GPIO-8 and CE1/GPIO-7. The latter 3 are now pull-up by default.

samskiter
Posts: 24
Joined: Wed Aug 12, 2015 6:18 pm

Re: Some GPIOs ignored in device tree on Compute Module

Thu Jan 07, 2016 10:01 pm

Thanks for clarifying all, sounds like I've been tripped up by the "power-down mode" terminology.

I think we've got away with it as we can probably live with those GPIOs high as the board comes on and we've got lucky on others that are more critical :)

Now on to fix the new kernel bugs :)

Return to “Device Tree”