[U-Boot] Question regarding early pinctrl and driver model in u-boot
Dear All,
I've stumbled upon a following issue:
- I do have a vybrid SoC which is not using SPL. It only uses U-boot proper (u-boot.vyb).
- In the board_early_init_f() (when we are still in SRAM) I do perform pinctrl (pinmux) setup for UART1 (this is the console device).
- I also do use ucalss-serial.c for this device and have proper pinmux definition for it in the *.dts file - but this is done latter.
The problem is that, when I try to remove pinmux setup code (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(), then I do see uart output late (no U-boot early output - U-Boot 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
The reason for this is the lack of pinctrl UART pins setup.
Do you see any idea how to move to full dts support for uart? The uart driver and pinmux have defined DM_FLAG_PRE_RELOC.
The same kind of problem I do have with DDR memory controller pin setup. It would be nice to have it all in DTS, not in a board file.
[ My idea would be to manually extract relevant data from fdt blob and configure pins in board_early_init_f(), but this looks like a hack - maybe there is another, better solution? ]
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hi Lukasz,
On Mon, 3 Dec 2018 at 15:13, Lukasz Majewski lukma@denx.de wrote:
Dear All,
I've stumbled upon a following issue:
I do have a vybrid SoC which is not using SPL. It only uses U-boot proper (u-boot.vyb).
In the board_early_init_f() (when we are still in SRAM) I do perform pinctrl (pinmux) setup for UART1 (this is the console device).
I also do use ucalss-serial.c for this device and have proper pinmux definition for it in the *.dts file - but this is done latter.
The problem is that, when I try to remove pinmux setup code (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(), then I do see uart output late (no U-boot early output - U-Boot 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
The reason for this is the lack of pinctrl UART pins setup.
Do you see any idea how to move to full dts support for uart? The uart driver and pinmux have defined DM_FLAG_PRE_RELOC.
Is this due to pinconfig_post_bind() only operating after relocation?
The same kind of problem I do have with DDR memory controller pin setup. It would be nice to have it all in DTS, not in a board file.
[ My idea would be to manually extract relevant data from fdt blob and configure pins in board_early_init_f(), but this looks like a hack - maybe there is another, better solution? ]
Hopefully :-)
Regards, Simon
Hi Simon,
Hi Lukasz,
On Mon, 3 Dec 2018 at 15:13, Lukasz Majewski lukma@denx.de wrote:
Dear All,
I've stumbled upon a following issue:
I do have a vybrid SoC which is not using SPL. It only uses U-boot proper (u-boot.vyb).
In the board_early_init_f() (when we are still in SRAM) I do
perform pinctrl (pinmux) setup for UART1 (this is the console device).
- I also do use ucalss-serial.c for this device and have proper
pinmux definition for it in the *.dts file - but this is done latter.
The problem is that, when I try to remove pinmux setup code (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(), then I do see uart output late (no U-boot early output - U-Boot 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
The reason for this is the lack of pinctrl UART pins setup.
Do you see any idea how to move to full dts support for uart? The uart driver and pinmux have defined DM_FLAG_PRE_RELOC.
Is this due to pinconfig_post_bind() only operating after relocation?
Please correct me if I'm wrong, but post_bind() callback is called with device_bind_* family of functions?
Those functions - e.g. device_bind() are used in an interesting way - e.g.: drivers/gpio/s5p_gpio.c -> gpio_exynos_bind().
The problem seems to be with the time pinctrl device itself is probed (way after board_early_init_f()).
IMHO it would be enough to "probe" pinctrl itself very early (before relocation - DDR setup) to just configure pins from iomux's pictrl_hog group (and put there DDR and uart pins) - not waiting for other devices to be "discovered" (like uart).
The same kind of problem I do have with DDR memory controller pin setup. It would be nice to have it all in DTS, not in a board file.
[ My idea would be to manually extract relevant data from fdt blob and configure pins in board_early_init_f(), but this looks like a hack - maybe there is another, better solution? ]
Hopefully :-)
Regards, Simon
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
Hi Lukasz,
On Thu, 6 Dec 2018 at 01:50, Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi Lukasz,
On Mon, 3 Dec 2018 at 15:13, Lukasz Majewski lukma@denx.de wrote:
Dear All,
I've stumbled upon a following issue:
I do have a vybrid SoC which is not using SPL. It only uses U-boot proper (u-boot.vyb).
In the board_early_init_f() (when we are still in SRAM) I do
perform pinctrl (pinmux) setup for UART1 (this is the console device).
- I also do use ucalss-serial.c for this device and have proper
pinmux definition for it in the *.dts file - but this is done latter.
The problem is that, when I try to remove pinmux setup code (imx_iomux_v3_setup_multiple_pads()) from board_early_init_f(), then I do see uart output late (no U-boot early output - U-Boot 2018.11-00052-g6552299a40-dirty (Nov 23 2018 - 16:13:51 +0100)).
The reason for this is the lack of pinctrl UART pins setup.
Do you see any idea how to move to full dts support for uart? The uart driver and pinmux have defined DM_FLAG_PRE_RELOC.
Is this due to pinconfig_post_bind() only operating after relocation?
Please correct me if I'm wrong, but post_bind() callback is called with device_bind_* family of functions?
Yes
Those functions - e.g. device_bind() are used in an interesting way
- e.g.: drivers/gpio/s5p_gpio.c -> gpio_exynos_bind().
Yes, they create child devices.
The problem seems to be with the time pinctrl device itself is probed (way after board_early_init_f()).
IMHO it would be enough to "probe" pinctrl itself very early (before relocation - DDR setup) to just configure pins from iomux's pictrl_hog group (and put there DDR and uart pins) - not waiting for other devices to be "discovered" (like uart).
Well, even probing a single device will cause pinctrlt to be probed, so shouldn't this happen automatically?
Regards, Simon
participants (2)
-
Lukasz Majewski -
Simon Glass