• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 3578 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM335x GPIO during boot and kernel start

Jan Dvorak
Prodigy 30 points

Hello,


we are working with BeagleBone Black . HW engineers observed P8/P9 pin behavior and designed the hardware to match with default pin config in then shipped debian distribution. Since we moved to new debian version with 4.1.15-ti-rt-r43 kernel, some of the gpios changed. I managed to change the dts and dtsi files, recompile them and copy them to the dtbs folder to match our demands. I also modifed pin setting in u-boot /board/ti/am335x/mux.c and rebuilded u-boot. Everything looks good (all the pins are set correctly 500ms after reset), but the problem is that some pins get temporarily reconfigured during BBB startup. They are reconfigured after approx 7,5s after reset around the time when "starting kernel" appears in console. They all get back in 3,2s to the right setting - probably when dtb is loaded by kernel. See the attached figure (P9_23 is set as output, init value low and is temporarily set probably as input no pull during startup - I checked and we don't set the mmc2, pru or any other modes in our dts files on this pin with offset 0x044).

Here are my questions:

1 - can the initial setting be applied faster then these 500ms in u-boot?

2 - is the temporarily reconfiguration caused by end of u-boot process or by our particular kernel (perhaps some default cpu setting in kernel source code)?

3 - in any of these two possibilities - what should I change or what src to modify to get rid of this 3,2s gap?

Best regards

Jan

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the software team to comment.
  • 0
    TI__Guru**** 161600 points

    Hi Jan, 

    I am not familiar with the debian kernel & u-boot sources, so I would refer to latest TI SDK, however in general they should be similar. 

    Jan Dvorak said:
    1 - can the initial setting be applied faster then these 500ms in u-boot?

     

    You could try calling the init function, request_and_set_gpio(), earlier in board.c, but other than that I don't think there is much you can do. 

    Jan Dvorak said:
    2 - is the temporarily reconfiguration caused by end of u-boot process or by our particular kernel (perhaps some default cpu setting in kernel source code)?

     

    This happens, because of time between u-boot end & the kernel taking over the SoC configurations. 

    Jan Dvorak said:
    3 - in any of these two possibilities - what should I change or what src to modify to get rid of this 3,2s gap?

     

    Have you tried adding the ti,gpio-always-on in your gpio device tree node? As described in Documentation/devicetree/bindings/gpio/gpio-omap.txt, this parameter "indicates if a GPIO bank is always powered and so will never lose its logic state".

    Hope this helps. 

    Best Regards, 
    Yordan

  • 0 in reply to Yordan Kovachev
    Prodigy 30 points
    Hi Yordan,

    thank you for the answers.

    I found earlier that the board.c could be used just right after the runtime is initialized, but I rather modified the mux after cpu and clock setup. I will try it but I expect the result still in order of hundreds of ms.

    I will try the gpio-alwyas-on next week with proper equipment and let you know.

    Thanks again and best regards
    Jan
  • 0 in reply to Yordan Kovachev
    Prodigy 30 points
    Hello Yordan,

    I recompiled dtb with the ti,gpio-always-on in all gpio0-3 and copied it to the board, but id did not help. Maybe I am doing something wrong. Do I have to recompile the whole kernel, or just modify dtb? Is the dtb loaded and used before kernel starts during u-boot? I thought not. It seems that its address is only passed to the kernel and the file is used and loaded after these 3,something seconds.

    Best regards
    Jan
  • 0 in reply to Jan Dvorak
    TI__Guru**** 161600 points

    Hi Jan,

    Jan Dvorak said:
    Do I have to recompile the whole kernel, or just modify dtb?

    Just the dtb should be enough.

    I have another suggestion. Do you use these gpio pins during u-boot?  If not, you can try to implement the falcon mode, which skips the u-boot and the mlo loads the kernel directly. Have a look at u-boot sources: doc/README.falcon. 

    Another thing to check: if you configure the gpios correctly (in the desired state) in u-boot, you could check the gpio driver in the kernel... it is possible that it performs a soft reset upon initializing gpio interface (as I said I am not familiar with the debian kernel you use). 

    I am afraid that there aren't much options to manipulate pinmux settings in between u-boot & kernel loading dtb.

    Best Regards, 
    Yordan