U-Boot GPIO console command on BBB issue


I have a rev B BeagleBone Black which I have been using for over a year as a development platform for a pseudo-clone board we are developing. We are using QNX as our OS.

Lately I have been tinkering with U-Boot to learn how the boot process works and configure our board properly. I cloned the U-boot git repository and built the 2015.10-rc2 version. The board boots fine and now the MPU frequency gets configured at 1GHz, but the thing is that the gpio console command doesn’t seem to work anymore.

Previously I used the 2013.04 version of U-Boot and could toggle leds using the gpio comand (i.e. “gpio toggle 54” ), but now the same command just returns an error message “Command ‘gpio’ failed: Error -22”.

Is there anything I’ve missed to make this command work properly? For building u-boot I used the following commands:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- distclean
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- am335x_boneblack_defconfig

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

Any help will be appreciated! If you need aditional information, please ask!



Locally i had to revert 0a9e34056fcf86fb64e70bd281875eb7bbdbabde

But i think we need to use the led labels from here:


But i'm not 100% sure on how to access them, as

gpio set led@2

returned: "Command 'gpio' failed: Error -22". for me too...


Only thing I could find on short notice in regard to error -22 . . .

Regarding errors -32 and -22 - those are low-level errors and doesn’t tell much to end user.
-32 means EPIPE (broken pipe)
-22 means EINVAL (invalid argument)

So perhaps check the uboot gpio command ( help gpio - or however it works in uboot ). To make sure you are using the command correctly. e.g. maybe it has changed more recently ?

The help of the gpio command doesn’t say much.

gpio <input|set|clear|toggle>

  • input/set/clear/toggle the specified pin
    gpio status [-a] [ | ] - show [all/claimed] GPIOs

On the previous version pin= 32*(gpio port number +1) + port pin

Maybe now they are identified differently, but I could not find a definition in the source code files. Also the command “gpio status -a” doesn’t return anything.



Sounds like it is time to “ping” the uboot maintainer perhaps . . .


I just ran into the below old issue with the ‘gpio’ command on the u-boot mainline (returning -22 on ‘gpio set 53’). Was commit 0a9e34056fcf86fb64e70bd281875eb7bbdbabde tested on AM335x?



I just ran into the below old issue with the 'gpio' command on the u-boot
mainline (returning -22 on 'gpio set 53'). Was commit
0a9e34056fcf86fb64e70bd281875eb7bbdbabde tested on AM335x?

Oh hell. I did test this at the time and I tested it again this morning
and I see what's going on. When I did my tests I was testing some other
DM related changes and so I had the device tree also included and that's
how all of the GPIOs were found. I probably also tested on an old
beagleboard without a device tree. But I did forget to test am335x
without a device tree and that's where it's failing now. I'm flashing
one of the user LEDs in my office right now and I'll post something to
the mailing lists shortly that also fixes OMAP4/OMAP5.

Well, the good news is that for OMAP4/5 (and DRA7xx and so forth so X15)
we don't enable DM_GPIO so they're not broken by this at least.