I was trying to echo 162 > /sys/class/gpio/export
but it does not create corresponding new entry.
I just update and rebuilt stable kernel and switch to wall power
supply instead of over USB OTG. Bootloader recognizes the Trainer
board. Unfortunately there are still no corresponding entries in the
/sys/class/gpio directory. Invoking echo > export also does not help.
I would appreciate any hints about where to look for the possible
solution and possible steps to debug the issue.
I was trying to echo 162 > /sys/class/gpio/export
but it does not create corresponding new entry.
I just update and rebuilt stable kernel and switch to wall power
supply instead of over USB OTG. Bootloader recognizes the Trainer
board. Unfortunately there are still no corresponding entries in the
/sys/class/gpio directory. Invoking echo > export also does not help.
BTW, issuing shutdown -h now leads to reboot instead of shutdown with
the newer stable kernel.
Is it just me or is it a new feature?
I just update and rebuilt stable kernel and switch to wall power
supply instead of over USB OTG. Bootloader recognizes the Trainer
board. Unfortunately there are still no corresponding entries in the
/sys/class/gpio directory. Invoking echo > export also does not help.
I found out that CONFIG_OMAP_MUX is not set in
angstrom-dev/staging/beagleboard-angstrom-linux-gnueabi/kernel/.config
(from stable branch)
Could it be the reason why I can not get corresponding gpio entries in
/sys/class/gpio as I mentioned above? Are there any reasons why it is
not set there? I would appreciate if someone can shed the light on it.
I am kind of confused because it is contradicts to the statement in
PinMux Wiki: "Some additional PinMux configuration is done by Linux
kernel, too. Note that this has to be enabled by CONFIG_OMAP_MUX, else
this isn't executed."
I just update and rebuilt stable kernel and switch to wall power
supply instead of over USB OTG. Bootloader recognizes the Trainer
board. Unfortunately there are still no corresponding entries in the
/sys/class/gpio directory. Invoking echo > export also does not help.
I found out that CONFIG_OMAP_MUX is not set in
angstrom-dev/staging/beagleboard-angstrom-linux-gnueabi/kernel/.config
(from stable branch)
Could it be the reason why I can not get corresponding gpio entries in
/sys/class/gpio as I mentioned above? Are there any reasons why it is
not set there? I would appreciate if someone can shed the light on it.
I am kind of confused because it is contradicts to the statement in
PinMux Wiki: "Some additional PinMux configuration is done by Linux
kernel, too. Note that this has to be enabled by CONFIG_OMAP_MUX, else
this isn't executed."
It's disabled because the mux config in the kernel is broken. Noone wants to fix it, so we do all muxing in u-boot.
I see. Then do you have an idea what might be wrong and why even with
corresponding echo command I can not export gpio pins which are
configured in u-boot?
I just update and rebuilt stable kernel and switch to wall power
supply instead of over USB OTG. Bootloader recognizes the Trainer
board. Unfortunately there are still no corresponding entries in the
/sys/class/gpio directory. Invoking echo > export also does not help.
I found out that CONFIG_OMAP_MUX is not set in
angstrom-dev/staging/beagleboard-angstrom-linux-gnueabi/kernel/.config
(from stable branch)
Could it be the reason why I can not get corresponding gpio entries in
/sys/class/gpio as I mentioned above? Are there any reasons why it is
not set there? I would appreciate if someone can shed the light on it.
I am kind of confused because it is contradicts to the statement in
PinMux Wiki: "Some additional PinMux configuration is done by Linux
kernel, too. Note that this has to be enabled by CONFIG_OMAP_MUX, else
this isn't executed."
It's disabled because the mux config in the kernel is broken. Noone wants to fix it, so we do all muxing in u-boot.
I see. Then do you have an idea what might be wrong and why even with
corresponding echo command I can not export gpio pins which are
configured in u-boot?
I just found out that some GPIOs can be exported (for example 130),
but others (for example 162 which powers AVR on Trainer board) could
not. I will take closer look on mux settings in u-boot. Maybe there is
just a typo over there...
I just update and rebuilt stable kernel and switch to wall power
supply instead of over USB OTG. Bootloader recognizes the Trainer
board. Unfortunately there are still no corresponding entries in the
/sys/class/gpio directory. Invoking echo > export also does not help.
I found out that CONFIG_OMAP_MUX is not set in
angstrom-dev/staging/beagleboard-angstrom-linux-gnueabi/kernel/.config
(from stable branch)
Could it be the reason why I can not get corresponding gpio entries in
/sys/class/gpio as I mentioned above? Are there any reasons why it is
not set there? I would appreciate if someone can shed the light on it.
I am kind of confused because it is contradicts to the statement in
PinMux Wiki: "Some additional PinMux configuration is done by Linux
kernel, too. Note that this has to be enabled by CONFIG_OMAP_MUX, else
this isn't executed."
It's disabled because the mux config in the kernel is broken. Noone wants to fix it, so we do all muxing in u-boot.
I see. Then do you have an idea what might be wrong and why even with
corresponding echo command I can not export gpio pins which are
configured in u-boot?
I just found out that some GPIOs can be exported (for example 130),
but others (for example 162 which powers AVR on Trainer board) could
not. I will take closer look on mux settings in u-boot. Maybe there is
just a typo over there...
The could also be 'taken' by the kernel. You won't be able to export e.g. GPIO 170 either, since that's claimed by the DSS2 driver.
I've seen this stated before, yet I've successfully enabled
CONFIG_OMAP_MUX in my kernel and done some simple settings. What are
the negative effects of enabling this? Am I missing something?
The kernel has only one mux for EHCI, and we need to set different ones for <C4, C4 and xM. On xM you loose DVI and MMC with the in-kernel mux. That for 2.6.32, 2.6.29 is completely broken.
I was thinking of having u-boot has a param in bootargs that kernel sets as early_param and do muxing, i2c and spi init based on that. But doing "the right thing" in the kernel wrt muxing turns out to be quite complex
Oh - that makes sense. Since I'm specifically setting up the mux for
my hardware and letting the rest of the pins remain with the u-boot
settings it works fine. However, if the kernel attempted to set
everything, it would need to know the hardware rev, and since it
doesn't it would probably get it wrong and break things.
Also, since I've got a C2 board with a non-functioning EHCI, I
wouldn't have noticed if enabling CONFIG_OMAP_MUX had disabled that.
GPIO 162 in the default OE angstrom build is dedicated as the Card Detect for the secondary MMC slot. if you want to be able to export 162, you will need to remove the allocation in your beagle machine file.
GPIO 162 in the default OE angstrom build is dedicated as the Card Detect
for the secondary MMC slot. if you want to be able to export 162, you will
need to remove the allocation in your beagle machine file.
Would it be enough to find and correct corresponding mux setting in
u-boot or do I need to search for this place also in kernel?
u-boot just sets the pinmux to gpio, the kernel is what allocates the gpio as the card detect, so you will need to edit the beagle board machine file which has the allocation.
u-boot just sets the pinmux to gpio, the kernel is what allocates the gpio as the card detect, so you will need to edit the beagle board machine file which has the allocation.
