When become which gpio configuration mechanisms active with relation to the overall boot procedure?
First you would have to define what exactly you mean by ‘GPIO configuration’. Are you truly only talking about GPIOs or are you mixing this with the pin configuration/muxing and/or alternate function configuration as well? As usual the big question is what exactly is it that you are trying to achieve?
That said the Config Block has really nothing to do with any of this resp. this would be WinCE/WEC only features.
As you correctly pointed out U-Boot’s board init function is the first place in time where one may influence GPIO behaviour.
The device tree(s) themselves do not directly have anything to do with any GPIO configuration per se but depending on what exactly you are talking about certain drivers/subsystems may take their configurations from there.
First you would have to define what exactly you mean by ‘GPIO configuration’. Are you truly only talking about GPIOs or are you mixing this with the pin configuration/muxing and/or alternate function configuration as well? As usual the big question is what exactly is it that you are trying to achieve?
At the moment I am only interested in GPIOs for reading GPIO states (not pins) and the configuration consideration from poweron until the 2nd stage bootloader (u-boot in my case) is left during the boot procedure but also what needs to be considered w.r.t. consistency of GPIO configuration “at the border of leaving u-boot and loading kernel dtb/entering linux kernel” (to beeing able to get the GPIO state also from user space).
W.r.t. ‘GPIO configuration’ until leaving u-boot I am interested in two different topics: (a) setting a defined state for these GPIOs as early as possible after poweron and (b) modifying these initial GPIO configuration to beeing able to read the GPIO state. (Is it necessary to distinguish between (a) and (b) at all?)
That said the Config Block has really nothing to do with any of this resp. this would be WinCE/WEC only features.
Oh, I have not recognized that “Linux”, “TK1” or alike is not included in “Applicable for:” at the top left of these pages Config Block | Toradex Developer Center GPIO config block settings | Toradex Developer Center .
As you correctly pointed out U-Boot’s board init function is the first place in time where one may influence GPIO behaviour.
Ok, that answers (a) from above partly: Is the board init function contained in the standalone u-boot binary or in the u-boot dtb?
And what about (b): I guess then the u-boot gpio command w.r.t. to configuration and reading the gpio follows? Right before u-boot is left the boot command hands over a specific dtb to the kernel when booting the kernel. The dtb information of the u-boot dtb is not considered then and does not need to be kept consistent with user space gpio “requirements”, right? (This question relates to GPIO handling in uboot - Technical Support - Toradex Community somehow.)
The device tree(s) themselves do not directly have anything to do with any GPIO configuration per se but depending on what exactly you are talking about certain drivers/subsystems may take their configurations from there.
As mentioned above in the (b) part I have some kernel dtb for my custom PCB which is referenced when booting the kernel in u-boot. To beeing able to read the GPIO also from user space I am not sure if it is sufficient to consider the kernel dtb only or something else in addition…
