mx6cuboxi: failes to detect model
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 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
In: serial Out: serial Err: serial Net: eth0: ethernet@2188000
I did a git bisect to find the commit that broke model detection:
# good: [4459ed60cb1e0562bc5b40405e2b4b9bbf766d57] Prepare v2023.10 git bisect good 4459ed60cb1e0562bc5b40405e2b4b9bbf766d57 # bad: [873791433602281ed230486606e326983c97a285] Merge https://source.denx.de/u-boot/custodians/u-boot-riscv git bisect bad 873791433602281ed230486606e326983c97a285 # bad: [6e0a75d3162a024cb0cdedd871d435e6ee782447] configs: Resync with savedefconfig git bisect bad 6e0a75d3162a024cb0cdedd871d435e6ee782447 # good: [99b46477e3495f819f6826d11470d46f12a4f9f7] clk: Dont return error when assigned-clocks is empty or missing git bisect good 99b46477e3495f819f6826d11470d46f12a4f9f7 # bad: [50fa67d091b6ffbc1d77d3100d7b31795bf64928] arm: mach-k3: j721e_init: Move clk_k3 probe before loading TIFS git bisect bad 50fa67d091b6ffbc1d77d3100d7b31795bf64928 # bad: [827cece3aa550d41e9c08c640b3a73372c8fb14a] pinctrl: renesas: Synchronize R8A77980 V3H PFC tables with Linux 6.5.3 git bisect bad 827cece3aa550d41e9c08c640b3a73372c8fb14a # good: [623b3e8f9718a1fbd612b3e42451859e9f98a947] x86: spl: Change the condition for copying U-Boot to RAM git bisect good 623b3e8f9718a1fbd612b3e42451859e9f98a947 # good: [ad57b98e212bd15492398cea3a8d4df6297e16fd] x86: doc: Split out manual booting into its own file git bisect good ad57b98e212bd15492398cea3a8d4df6297e16fd # bad: [6d53b50888315252cdd3251551add7a9108a1300] ARM: renesas: Enable DM_ETH_PHY on 64-bit R-Car boards git bisect bad 6d53b50888315252cdd3251551add7a9108a1300 # bad: [283dcb63cb7d124fa427938f39aa9362872e02fc] buildman: Show progress when regenerating the board.cfg file git bisect bad 283dcb63cb7d124fa427938f39aa9362872e02fc # bad: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation git bisect bad 9e644284ab812f2db23f6185af77c0e771b0be73 # good: [b05a184379631d13c4a49e423aa1324dc1ae6158] Merge tag 'x86-pull-20230922' of https://source.denx.de/u-boot/custodians/u-boot-x86 into next git bisect good b05a184379631d13c4a49e423aa1324dc1ae6158 # first bad commit: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation
If I revert 9e644284ab812f2db23f6185af77c0e771b0be73 on top of git master everything is fine again. As I am not an export in that area I am seeking some directions on how to fix this issue.
Hi Christian,
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.
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));
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
In: serial Out: serial Err: serial Net: eth0: ethernet@2188000
I did a git bisect to find the commit that broke model detection:
# good: [4459ed60cb1e0562bc5b40405e2b4b9bbf766d57] Prepare v2023.10 git bisect good 4459ed60cb1e0562bc5b40405e2b4b9bbf766d57 # bad: [873791433602281ed230486606e326983c97a285] Merge https://source.denx.de/u-boot/custodians/u-boot-riscv git bisect bad 873791433602281ed230486606e326983c97a285 # bad: [6e0a75d3162a024cb0cdedd871d435e6ee782447] configs: Resync with savedefconfig git bisect bad 6e0a75d3162a024cb0cdedd871d435e6ee782447 # good: [99b46477e3495f819f6826d11470d46f12a4f9f7] clk: Dont return error when assigned-clocks is empty or missing git bisect good 99b46477e3495f819f6826d11470d46f12a4f9f7 # bad: [50fa67d091b6ffbc1d77d3100d7b31795bf64928] arm: mach-k3: j721e_init: Move clk_k3 probe before loading TIFS git bisect bad 50fa67d091b6ffbc1d77d3100d7b31795bf64928 # bad: [827cece3aa550d41e9c08c640b3a73372c8fb14a] pinctrl: renesas: Synchronize R8A77980 V3H PFC tables with Linux 6.5.3 git bisect bad 827cece3aa550d41e9c08c640b3a73372c8fb14a # good: [623b3e8f9718a1fbd612b3e42451859e9f98a947] x86: spl: Change the condition for copying U-Boot to RAM git bisect good 623b3e8f9718a1fbd612b3e42451859e9f98a947 # good: [ad57b98e212bd15492398cea3a8d4df6297e16fd] x86: doc: Split out manual booting into its own file git bisect good ad57b98e212bd15492398cea3a8d4df6297e16fd # bad: [6d53b50888315252cdd3251551add7a9108a1300] ARM: renesas: Enable DM_ETH_PHY on 64-bit R-Car boards git bisect bad 6d53b50888315252cdd3251551add7a9108a1300 # bad: [283dcb63cb7d124fa427938f39aa9362872e02fc] buildman: Show progress when regenerating the board.cfg file git bisect bad 283dcb63cb7d124fa427938f39aa9362872e02fc # bad: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation git bisect bad 9e644284ab812f2db23f6185af77c0e771b0be73 # good: [b05a184379631d13c4a49e423aa1324dc1ae6158] Merge tag 'x86-pull-20230922' of https://source.denx.de/u-boot/custodians/u-boot-x86 into next git bisect good b05a184379631d13c4a49e423aa1324dc1ae6158 # first bad commit: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation
If I revert 9e644284ab812f2db23f6185af77c0e771b0be73 on top of git master everything is fine again. As I am not an export in that area I am seeking some directions on how to fix this issue.
-- greets -- Christian Gmeiner, MSc
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
On Tue, Mar 26, 2024 at 1:11 PM Christian Gmeiner christian.gmeiner@gmail.com wrote:
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
It seems to me that there is a mix of DM GPIO and non-DM GPIO.
Does the change below help?
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,20 +336,16 @@ static enum board_type board_type(void) * HB 1 1 x */
- gpio_direction_input(IMX_GPIO_NR(2, 8)); - val3 = gpio_get_value(IMX_GPIO_NR(2, 8)); + val3 = !!dm_gpio_get_value(&(board_detect_desc[0]));
if (val3 == 0) return HUMMINGBOARD2;
- gpio_direction_input(IMX_GPIO_NR(3, 4)); - val2 = gpio_get_value(IMX_GPIO_NR(3, 4)); + val2 = !!dm_gpio_get_value(&(board_detect_desc[1]));
if (val2 == 0) return HUMMINGBOARD; - - gpio_direction_input(IMX_GPIO_NR(4, 9)); - val1 = gpio_get_value(IMX_GPIO_NR(4, 9)); + val1 = !!dm_gpio_get_value(&(board_detect_desc[2]));
if (val1 == 0) { return CUBOXI;
Hi Fabio
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
It seems to me that there is a mix of DM GPIO and non-DM GPIO.
Does the change below help?
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,20 +336,16 @@ static enum board_type board_type(void) * HB 1 1 x */
gpio_direction_input(IMX_GPIO_NR(2, 8));val3 = gpio_get_value(IMX_GPIO_NR(2, 8));
val3 = !!dm_gpio_get_value(&(board_detect_desc[0])); if (val3 == 0) return HUMMINGBOARD2;
gpio_direction_input(IMX_GPIO_NR(3, 4));val2 = gpio_get_value(IMX_GPIO_NR(3, 4));
val2 = !!dm_gpio_get_value(&(board_detect_desc[1])); if (val2 == 0) return HUMMINGBOARD;
gpio_direction_input(IMX_GPIO_NR(4, 9));val1 = gpio_get_value(IMX_GPIO_NR(4, 9));
val1 = !!dm_gpio_get_value(&(board_detect_desc[2])); if (val1 == 0) { return CUBOXI;
It does help \o/
When you send out a proper patch feel free to add Tested-by: Christian Gmeiner cgmeiner@igalia.com
Time to look into the next broken thing on the device: network :)
Hi Christian,
On Wed, Mar 27, 2024 at 3:54 AM Christian Gmeiner christian.gmeiner@gmail.com wrote:
It does help \o/
Ok, great!
When you send out a proper patch feel free to add Tested-by: Christian Gmeiner cgmeiner@igalia.com
I have sent a more complete fix, so I have not included your Tested-by.
Please test the formal version and reply with your Tested-by tag.
Time to look into the next broken thing on the device: network :)
If you still have issues with Ethernet, please share the details on a new thread.
participants (2)
-
Christian Gmeiner -
Fabio Estevam