mx6cuboxi: failes to detect model

[Christian Gmeiner]

Hi Fabio

>
> On Tue, Mar 26, 2024 at 12:17 PM Christian Gmeiner
> <christian.gmeiner at 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 at 20a4000: set_dir_flags: error: gpio GPIO3_8 not reserved
> > gpio at 20a4000: get_value: error: gpio GPIO3_8 not reserved
> > gpio at 20a8000: set_dir_flags: error: gpio GPIO4_4 not reserved
> > gpio at 20a8000: get_value: error: gpio GPIO4_4 not reserved
> > gpio at 20b0000: set_dir_flags: error: gpio GPIO6_9 not reserved
> > gpio at 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 at kwiboo.se>
    Reviewed-by: Simon Glass <sjg at chromium.org>


-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy