Hi Fabio
On Tue, Mar 26, 2024 at 12:17 PM Christian Gmeiner christian.gmeiner@gmail.com wrote:
I am seeing model detection problems with the current git master.
U-Boot 2024.04-rc5 (Mar 26 2024 - 15:59:22 +0100)
CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 26C Reset cause: POR Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) gpio@20a4000: set_dir_flags: error: gpio GPIO3_8 not reserved gpio@20a4000: get_value: error: gpio GPIO3_8 not reserved gpio@20a8000: set_dir_flags: error: gpio GPIO4_4 not reserved gpio@20a8000: get_value: error: gpio GPIO4_4 not reserved gpio@20b0000: set_dir_flags: error: gpio GPIO6_9 not reserved gpio@20b0000: get_value: error: gpio GPIO6_9 not reserved Board: MX6 HummingBoard
Unfortunately, my mx6cuboxi no longer works, so I can't test it myself.
I am adding Baruch on Cc. Hopefully, Baruch or Josua can take a look.
Thanks.
The 'not reserved' errors may be caused by the lack of gpio_request().
Do the changes below help?
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,18 +336,21 @@ static enum board_type board_type(void) * HB 1 1 x */
gpio_request(IMX_GPIO_NR(2, 8), "val3"); gpio_direction_input(IMX_GPIO_NR(2, 8)); val3 = gpio_get_value(IMX_GPIO_NR(2, 8)); if (val3 == 0) return HUMMINGBOARD2;gpio_request(IMX_GPIO_NR(3, 4), "val2"); gpio_direction_input(IMX_GPIO_NR(3, 4)); val2 = gpio_get_value(IMX_GPIO_NR(3, 4)); if (val2 == 0) return HUMMINGBOARD;gpio_request(IMX_GPIO_NR(4, 9), "val1"); gpio_direction_input(IMX_GPIO_NR(4, 9)); val1 = gpio_get_value(IMX_GPIO_NR(4, 9));
It got better but the model is (still) wrong:
U-Boot 2024.04-rc5-dirty (Mar 26 2024 - 17:03:41 +0100)
CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 20C Reset cause: POR Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) Board: MX6 HummingBoard2 DRAM: 2 GiB Core: 82 devices, 17 uclasses, devicetree: fit MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... *** Warning - bad CRC, using default environment
With the revert of 9e644284ab812f2db23f6185af77c0e771b0be73 I get:
U-Boot 2024.04-rc5-00002-g3512482aeb (Mar 26 2024 - 17:06:01 +0100)
CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 25C Reset cause: POR Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) Board: MX6 Cubox-i DRAM: 2 GiB Core: 82 devices, 17 uclasses, devicetree: fit ...
git show 9e644284ab812f2db23f6185af77c0e771b0be73 dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation
Nodes with bootph-pre-sram/ram props are bound in multiple phases: 1. At TPL (bootph-pre-sram) or SPL (bootph-pre-ram) phase 2. At U-Boot proper pre-relocation phase 3. At U-Boot proper normal phase
However the binding and U-Boot Driver Model documentation indicate that only nodes marked with bootph-all or bootph-some-ram should be bound in the U-Boot proper pre-relocation phase.
Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop with a pre-reloc status only after U-Boot proper pre-relocation phase. Also update the ofnode_pre_reloc documentation to closer reflect the binding and driver model documentation.
This changes behavior of what nodes are bound in the U-Boot proper pre-relocation phase. Change to bootph-all or add bootph-some-ram prop to restore prior behavior.
Signed-off-by: Jonas Karlman jonas@kwiboo.se Reviewed-by: Simon Glass sjg@chromium.org