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.

在u-boot中控制am335x管脚,卡死。求解。



我在am335x_evm.h的头文件里添加

CONFIG_GPIO

CONFIG_CMD_GPIO

两个宏,然后用命令操作管脚。

当输入pin number小于32时,正常操作,当输入大于32时,直接卡死。

跟踪后发现代码在_set_gpio_direction()这个函数里就死了。

start kit和evm均有这种情况。

求解。

  • 每个GPIO模块就32个pin,你超过32,不就是超过范围了么?

  • 这个我已经想过了,但是源代码里显示,它是会自己计算,并切换gpio的bank。

    \arch\arm\cpu\armv7\omap-common\gpio.c : get_gpio_bank(int gpio)这个函数里,通过你输入的pin number,自动计算,并切换bank。

    0-31,gpio0

    32-63,gpio1

    ...

    但是,超过31就是挂了。

    另外,u-boot没有提供手动指定bank的命令。so...难道我抓住了一个bug?

  • 你的调用循序是什么?这几个的gpio的pinmux配置好了吗

  • 我直接在u-boot输入命令:gpio input [pin number]

    pinmux我没有去深入去看,但是我做过一个小实验。

    我遍历了pin number,从0-31,都可以直接操作。看了电路图之后,gpio0的很多管脚也是复用的。

    或许跟pinmux没有关系。

  • 我觉得还是要看看这几个pin脚的配置,可以打印出对应的寄存器看看,看上去只有第一个bank是空余出来做gpio的

  • mode 7是gpio的模式,在am335x的mux.c文件里,搜mode(7),发现只有极少数io被配置成gpio。

    但是整个bank0却又能实实在在地进行操作,而其他却不行。

    这是你说的pin mux吗?

  • 对于GPIO pin来说,默认就是mode 7,问题是这个值是不是被修改了,最好能在调用GPIO操作前读下这几个寄存器的值,看看mux被修改了没有

  • 我没有仿真器,这个对寄存器的值进行跟踪太难受了,单单使用print来操作,异常痛苦。我也期待有人知道更有效的调试方法。

    我只能假设,一旦在mux中将管脚定义好,u-boot不会在任何其他位置试图修改该管脚的配置。

    目前来说,我们都觉得导致卡死的原因有可能是操作了非gpio模式的io口。

    下面是一个例子:

    被设置为function模式的gpio0管脚:

    可以清楚看到,mii接口的管脚模式都是function模式,但是,就像我之前说了一样,在我u-boot中是可以对整个gpio0进行读写操作的。

    退一步讲,确实,u-boot的gpio命令会去改变当前管脚的配置,但仅局限于改变输入输出模式,置高置低,尔后,u-boot也有一个free(gpio)的动作。那么为什么对其他bank的gpio却无效。

    可能是我个人知识的局限性,也或许ti应该认真对待这个问题。

    ps,我看见你的id在各个板块都出现了,这里就你一个人做支持?e2e论坛的员工好像更多。

  • 如果没有仿真器,我记得u-boot有命令可以读取内存的值得,你可以看看这个

    http://www.360doc.com/content/10/0827/13/496343_49168699.shtml

    GPIO函数里面的操作,我大概看了下,没有对mux操作的,所以我怀疑mux

    我们没有遇到过客户提到这个问题,而且我觉得这不是个bug,只是个使用问题,mux本来就是要根据需求配置的。

  • 首先很感谢你一直在跟进这个问题。

    不过mux.c里面的代码我并没有修改过,因为我使用的是evm。

    你怀疑是mux的问题,又不认为是bug,那么问题在于我的使用方式。

    既然在mux没有问题的前提下,我对所有设置为gpio模式的管脚都应该能操作才对。

    如之前贴的图,其中lcd_ac_bias_en这个管脚是gpio2的gpio模式,于是我在u-boot输入gpio set 57,也就是gpio2 的 第25脚。57=32+25。

    但是依旧卡死。

    我一度认为是u-boot的gpio命令有问题,尝试在代码中直接操作,依旧是同样的问题。

    虽然你提出了一些可能性,但是说服力都不足够。

    以st的芯片为例,如果它的管脚被设置成input模式,此时对管脚置1或置0的操作,虽然无效,但是也不会出现卡死的情况。

    总要有一个客户首先提出新的问题。

    或许你可以在开发板上重现一下,如果你能成功用u-boot操作其他bank,就能说明我的操作方式确实是存在问题的。

  • 我说遇到这样的问题比较少,有两一个意思,一个是说明这个问题是代码的问题的可能性相对比较少,没有现成的经验给您;另一个,如果没有问题,我看的也不多,毕竟uboot到linux东西很多,如果没有问题,也不会都看的到。这里不好意思了,不能直接给您答案。

    论坛就是个大家讨论问题的地方,大家都出点主意,提供点思路,还是要靠自己来调试的。

    出了问题,调试是必不可少的,在你调用命令前,你可以打印下相应寄存器的值,这样至少可以排除掉一些可能的原因。

    你说的GPIO2 25脚,我的理解, GPIO是从GPIO0开始的, 所以应该是32*2+25=89,你看看这个脚

  • 确实疏忽了,是89。但问题依旧。

    调试是我本职工作,但是现在我是怀疑这个是bug,并希望得到官方的解答。

    不过言下之意是解决不了。我还是直接发给技术支持去看吧。

  • 也可以的。

    不过,你在做调试,起码也要打印下寄存器的值吧。

  • 如果你想要set 某一个GPIO,你一定要去在U-boot中去查看这个GPIO有没有被pinmux成GPIO模式,如果被mux成function模式,一定要修改代码。

    我们其他的客户都是这么做的,没发现问题。

  • to  

    关于是否被设置成gpio模式,我上面贴的代码已经清清楚楚,明明白白。

    to yaoming qin

    我已经打印过寄存器的值,这些调试的基本流程都走过了。

    已经确认各个函数间传递的参数是无误的。到最终有一个对地址的操作__raw_writel(l, reg);,程序就死了。

    到这一步,我来找技术支持,很理所应当吧。

    该处的代码:

    static void _set_gpio_direction(const struct gpio_bank *bank, int gpio,
    int is_input)
    {
    void *reg = bank->base;
    u32 l;

    switch (bank->method) {
    case METHOD_GPIO_24XX:
    reg += OMAP_GPIO_OE;
    break;
    default:
    return;
    }
    l = __raw_readl(reg);
    if (is_input)
    l |= 1 << gpio;
    else
    l &= ~(1 << gpio);
    __raw_writel(l, reg);

    }

    对于这个问题,我的态度一直都是想知道是否存在这样的问题,希望得到验证。

    而不是说你一定要帮我搞定这个问题。大家都忙。

  • 那就当讨论问题好了

    我这边没有GPIO命令,没有打开。

    我用的是TI GP EVM,默认的uboot起来后,我读了下LCD_AC_BIAS_EN对应的mux 寄存器,如下:

    U-Boot# md 44e108ec 20
    44e108ec: 00000009 00000030 00000030 00000030 ....0...0...0...
    44e108fc: 00000030 00000030 00000030 00000027 0...0...0...'...
    44e1090c: 00000027 00000027 00000002 00000022 '...'......."...
    44e1091c: 00000002 00000002 00000002 00000002 ................
    44e1092c: 00000002 00000022 00000022 00000022 ...."..."..."...
    44e1093c: 00000022 00000022 00000027 00000030 "..."...'...0...
    44e1094c: 00000010 00000037 00000037 00000062 ....7...7...b...
    44e1095c: 00000062 00000035 00000027 00000037 b...5...'...7...

    可以看到0x44e108ec 对应的值是0x9,也就是说 LCD_AC_BIAS_EN工作在GPMC模式,而不是GPIO模式,所以会不正常。

  • 刚刚你回复的帖子呢。

    我的也是gp evm。0928是mii1_txd0,gpio0_28

    这是官方u-boot镜像的结果:我的是mode 7,gpio模式。

    换成添加过gpio cmd的u-boot:

    可以看到,仍然是mode 7,但是一操作就死了。

    我的boot脚是,从0-16:

    0110 1000 0000 0010

    cpld的profile是0000.

    你的设置是?

    我想传一下我的u-boot,不过我的设置是mmc0必须为raw格式。你可能用不了。

    u-boot版本u-boot-2011.09-psp04.06.00.08

  • 问题找到了。

    pll中没有启动其他gpio的interface clock。

    在board/ti/pll.c:interface_clocks_enable函数中添加初始化函数

    例如启动gpio2,添加代码:

    writel(PRCM_MOD_EN, CM_PER_GPIO2_CLKCTRL);
    while (readl(CM_PER_GPIO2_CLKCTRL) != PRCM_MOD_EN);

    来源:

    http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/211501.aspx

    感谢yaoming qin,一个人忙疯了,e2e人多势众,自然给力一点。我以为已经对u-boot中的代码足够熟悉,结果还是沉船了。。。 - -||

  • 谢谢分享,我今早也差不多debug到这个位置了。

    不过,你也可以看到,大家都是从mux来分析的,没办法,系统大,只能一步步分析。

    不好意思,没有快速解决你的问题:)

  • Hi Qin,請教個問題,目前使用GPIO3_18,GPIO3_19, GPIO3_20,在您的經驗中,有什麼情形會造成DATA_IN讀不到值!!! 或是說讀到0?有用DATA_OUT確認過pinmux,能依指示輸出0或1。INPUT 與OUTPUT有什麼不同的clock要設定嗎? 感謝!!!

  • 你好呀,我想问问,uboot中怎么加gpio 命令呀?

  • 我uboot中也遇到了这个问题,2011.09的版本,前面两组gpio控制正常,后面两组一操作直接卡死,找到寄存器,直接写也是卡死。感谢这篇问帖子