GPIO access on Ubuntu 15.04 OS, DragonBoard™ 410c

Products Support DragonBoard410c
#1

Using Ubuntu 15.04 located on the 96boards website:

We flashed the OS onto the board using the microSD card method and it worked perfectly. We proceeded to begin using the GPIO’s but noticed there was no GPIO folder.

Conventionally we have always used:

/sys/class/gpio/

to locate the folder and begin exporting GPIO’s. We performed a search and could not find any other file system that would allow GPIO’s to be exported and used.

Using Android OS, we were able to access all GPIO’s but one (GPIO_25 “H”) though the shell.

Is there a different method to accusing GPIO’s in this version of Ubuntu? Is there going to be a filesystem update to fix this problem?

Thank you.

#2

hi,

thanks for reporting this. Our kernel was missing CONFIG_GPIO_SYSFS option. There are instructions to rebuild your own kernel in the release notes, in case you want to give it a try. A patch was just pushed in our kernel branch that fixes this issue:

https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/8c78553adc50da6ebdd6dc4ff4af36a63a7e4470

If you don’t want to build your own kernel, you can use the boot image from this build:

http://builds.96boards.org/snapshots/dragonboard410c/linaro/ubuntu/51

#3

Thank you,

We thought you would push this change to the downloads page for the DB410c on the 96boards website:

We re-downloaded what we thought would be the new Ubuntu and flashed it to the board, this version does not have the gpio folder within the /sys/class yet.

We are currently trying to facilitate the “bring up” for this board for a variety of users and would like to be able to refer them to this site for a simple download and SD flash process.

Is there anyways we could get a version of Ubuntu that has the GPIO folder in sys/class on the 96boards.org website for the DB410c. I have a feeling that most of our students will follow this process and end up lost.

We are currently testing out the image you referred us to.

Thank again!

#4

hi,

yes, the next release will have these changes. I was planning to wait a few weeks for feedback and issues from users, before we spin a new release. I am expecting a new release around 7/24, that would be a patch release with mostly bug fixes reported until then (and hopefully video playback support as well), and that would be the 15.07 release.

cheers

#5

Thank you ndec,

Also, we flashed the images you provided for Ubuntu and everything seems to be working just fine now.

One more quick question. We noticed that for the Ubuntu build you provided there is no 902 offset for gpio’s while for Android OS there is an offset. Do you plan on keeping Ubuntu like this, that is, without the offset, or will an offset be implemented once the actual release comes out?

I am creating pin out diagrams like this one, I can make one for each OS if needed.

If the image doesn’t show see link:
http://imgur.com/MNT9Pnd?desktop=1

As always, thank you very much for your help

#6

I believe it’s the other way around… it’s the QCOM Android kernel that introduced a non-standard (arbitrary?) offset. As far as Linux is concerned there won’t be any offset, and it will stay as it is in all new releases.

#7

@ndec,

Ok perfect, thank you for the quick response.

Yet another questions:

All GPIO worked with the Ubuntu image you provided, however, we could not gain access to the MPP04(pin28). Based on the ngpio of each gpiochip located in the /sys/class/gpio folder we thought it would be one of the GPIO’s located between GPIO_504 and GPIO_511. The only two exportable GPIO’s are GPIO_504 and GPIO_507.

When exported/set direction(out)/value high(“1”)
GPIO_507 does not enable pin 28
GPIO_504 crashes the board (in several different ways)

We followed the instructions in our other thread:

https://www.96boards.org/forums/topic/40-pin-low-speed-expansion-header/

We could not find qpnp_pin for the path provided:

/sys/kernel/debug/qpnp_pin/pm8916-mpp/4

please note: we are working with the new Ubuntu image

thank you!

#8

About your header image; note that PCM DATA I is N/C at pin 22, but does appear at pin 27.

It is documented as simply N/C, and despite being technically connected at pin27, this function for pin27 is not consistent with 96boards specification, hence it is not listed. But for anybody who actually needs that function, it should be possible to grab it at 27.

#9

@sdrobertw, we will need to investigate further on that. that’s a GPIO from the PMIC, not the SoC. will get back to you later on that.

@doitright, my understanding is that MI2S_1 interface is TX only, and does not support RX. hence the PIN LS-22 is n/c. MI2S_2 is a TX/RX. pin LS-27 is GPIO-115 which could be muxed to be the ‘missing’ D1 indeed. I will check if i can get more info about MI2S_1.

MI2S_2 is used to connect the chip to the ADV7533 (onboard DSI/HDMI bridge), for the audio data.

#10

@ndec,
Looking over the APQ8016 documentation, there is nothing at all that implies that any of the i2s channels are restricted to output-only. In fact, if you look at page 47 of the APQ data sheet, all of the i2s data pins are specifically identified as “B” (bidirectional). In fact, if you look at pin E38, which has three options (i2s data, gyro interrupt, and gpio) when it is configured as Gyro Interrupt, it is “DI” (digital input only), when it is gpio, it is B-PD:nppukp (bidirectional pulldown with optional no-pull, pull-up, and keeper). I’m certain that MI2S_1_D0 and MI2S_1_D1 can BOTH be configured as inputs, the only question is what must be done in software to enable this?

#11

Not only that, but pages 78/79 discuss timing for i2s Tx and Rx as well as use of internal or external SCK.

#12

@ndec,

Which GPIO do I export to access the MPP at pin28 on the low-speed expansion header. Our assumption was GPIO_504 or GPIO_507, but one of them didn’t work and the other caused our board to freeze up. Please help.

Thank you!

#13

@sdrobertw

MPP GPIO assigned ranges could be seen using following command:

cat /sys/kernel/debug/pinctrl/200f000.spmi:pm8916@0:mpps@a000/gpio-ranges

GPIO ranges handled:
0: 200f000.spmi:pm8916@0:mpps@a000 GPIOS [504 - 507] PINS [0 - 3]

Current allocation of the pins could be seen using:

cat /sys/kernel/debug/pinctrl/200f000.spmi:pm8916@0:mpps@a000/pinmux-pins

Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (mpp1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
…
pin 3 (mpp4): (MUX UNCLAIMED) (GPIO UNCLAIMED)

PM_MPP_1 is connected VDD_PX_BIAS, not sure what it is, but it doesn’t look good idea to mess with.

Once exported PM_MPP_4 output level could be controlled perfectly fine, on mine board

cd /sys/class/gpio/

echo 507 > export

cat gpio507/direction

in

echo out > gpio507/direction

cat gpio507/direction

out

cd gpio507/

cat value

0

echo 1 > value

cat value

1

echo 0 > value

cat value

0

And the high output level is around 3.75V