This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GPIO output value in Pandaboard

Hi

I just want to ask some questions about u-boot in Pandaboard

Currently, I am using amstrong embedded linux to be my operating system, and I am now using some GPIOs to be outputs. The problem is now, I can set them initially as low, even if I change the uboot configuration gpio, it gives me a soft pull down which will be considered as high if it is connected to pull up resistors.

Those gpios are connected to pull-up resistors in my expansion board.

My setting is like:

in u-boot/board/ti/panda/panda_mux_data.h

{XXXXX,(PTD|OFF_EN|M3)}.

Can some one tell me how to fix that?

  • Chen,

    Do you mean that you are trying to override the pull-type set by resistors in hardware by setting the pull-type in software?

    By the way, in the Android releases for Blaze and Blaze Tablet, using the x-loader and u-boot from git.omapzoom.org, only the pin muxing in the x-loader is used.  There are pin muxing tables in the u-boot, but they are not used.  I don't know if this is the same in the Pandaboard release that you are using.  If you are not sure, you could check with the Pandaboard Google group (pandaboard@googlegroups.com).

    Regards,
    Gina 

  • No, I am not trying to override it by resisitros, actually, I just found when uboot boots up, the out put for gpio is not hard pull down, i mean even if you set it as low, it will be pulled up by resistor. But when linux successfully boots up, I can pull up or down mannually and then they work.

  • Are you using both x-loader and u-boot?  Are you sure that the pin muxing in the u-boot is being called?

    Regards,
    Gina 

  • I am using uboot now,  I am sure the pin muxing is being called because I am using omap4pandaboard default configuration, and I changed the pin mux and it works as well. 

    The problem seems to be if i want to change it to be pulled down, it doesnt go down if i have a pull up resistor

  • Chen,

    You shouldn't have conflicting pull types in the hardware and the software.  If you ultimately need a GPIO to be configured as a pull-down, then you shouldn't have any pull-up resistor attached to it in hardware, or vice-versa.  It depends on the resistor value used obviously, but typically the internal software pull-down isn't strong enough to override the hardware pull-up.  In any case, this could result in a nebulous value and should be avoided.

    Regards,
    Gina 

  • Hi 

    Thanks for your reply, and the strange thing here is I can pull down by software when linux successfully boots up even if I have a pull up resistor, so I just guess, the software should be strong enough to pull it down some how.

  • Chen,

    I assume you are using the gpio_set_value() function in the kernel to set the pull up/down?  This is implemented differently than the settings used in the bootloader, so I guess it could result in a different strength.  In any case, it is not recommended to set conflicting pull types in hardware and software.  The result is a nebulous value, and while it may seem to work in some cases, this is not a reliable method.

    Regards,
    Gina 

  • Hi, 

    Then is it possible to have a the same strength for gpio setting in uboot as gpio_set_value in linux?

  • Chen,

    You could read the value of the padconf register of interest at the bootloader level and the kernel level, using a tool such as omapconf, for example: https://github.com/omapconf/omapconf/wiki  While technically it can be done to manually overwrite the register value in the bootloader by another value, we recommend against this.  Again, it is not a good practice to have conflicting pull types in hardware and software, and this can lead to other issues.  Our recommendation is to use the external pull up/down resistor, as the internal pull up/down is not as powerful or reliable.

    Regards,
    Gina