help on udoo_neo power up on mainline uboot

help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

Hi Simon Glass,
I'm actually trying to boot up udoo_neo board with minimal configuration
(512 MB Ram) at the moment using the following cmd to flash the board
I'm no able to boot it (flashing uSD with ):
 - sudo dd if=u-boot-with-spl.imx of=/dev/sde bs=1k seek=1 conv=fsync
   (don't work)
 - sudo dd if=SPL of=/dev/sde bs=1K seek=1
 - sudo dd if=u-boot.img of=/dev/sde bs=1K seek=69
   (don't work)
I'm building uboot using:
 - make udoo_neo_defconfig
 - make
Are you able to boot the board with basic configuration (UDOO_NEO_TYPE_BASIC)?
I found this uboot on the web and with that I'm able to boot the board:
 - https://github.com/UDOOboard/uboot-imx
Can you give me one help on that? Are you abe to boot the board?
Let me know.

Thanks,
Tommaso

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Tommaso,

[Adding Peter]

On Tue, Dec 28, 2021 at 1:52 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
>
> Hi Simon Glass,
> I'm actually trying to boot up udoo_neo board with minimal configuration
> (512 MB Ram) at the moment using the following cmd to flash the board
> I'm no able to boot it (flashing uSD with ):
>  - sudo dd if=u-boot-with-spl.imx of=/dev/sde bs=1k seek=1 conv=fsync
>    (don't work)
>  - sudo dd if=SPL of=/dev/sde bs=1K seek=1
>  - sudo dd if=u-boot.img of=/dev/sde bs=1K seek=69
>    (don't work)
> I'm building uboot using:
>  - make udoo_neo_defconfig
>  - make
> Are you able to boot the board with basic configuration (UDOO_NEO_TYPE_BASIC)?
> I found this uboot on the web and with that I'm able to boot the board:
>  - https://github.com/UDOOboard/uboot-imx
> Can you give me one help on that? Are you abe to boot the board?

Please try this patch series from Peter:
https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/

Does it boot for you after applying this series?

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Tue, Dec 28, 2021 at 04:17:01PM -0300, Fabio Estevam wrote:
> Hi Tommaso,
> 
> [Adding Peter]
> 
> On Tue, Dec 28, 2021 at 1:52 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> >
> > Hi Simon Glass,
> > I'm actually trying to boot up udoo_neo board with minimal configuration
> > (512 MB Ram) at the moment using the following cmd to flash the board
> > I'm no able to boot it (flashing uSD with ):
> >  - sudo dd if=u-boot-with-spl.imx of=/dev/sde bs=1k seek=1 conv=fsync
> >    (don't work)
> >  - sudo dd if=SPL of=/dev/sde bs=1K seek=1
> >  - sudo dd if=u-boot.img of=/dev/sde bs=1K seek=69
> >    (don't work)
> > I'm building uboot using:
> >  - make udoo_neo_defconfig
> >  - make
> > Are you able to boot the board with basic configuration (UDOO_NEO_TYPE_BASIC)?
> > I found this uboot on the web and with that I'm able to boot the board:
> >  - https://github.com/UDOOboard/uboot-imx
> > Can you give me one help on that? Are you abe to boot the board?
> 
> Please try this patch series from Peter:
> https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/
> 
> Does it boot for you after applying this series?

Hi Fabio,
Thanks for your reply, i'll try and let you know.

tommaso

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Tue, Dec 28, 2021 at 04:17:01PM -0300, Fabio Estevam wrote:
> Hi Tommaso,
> 
> [Adding Peter]
> 
> On Tue, Dec 28, 2021 at 1:52 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> >
> > Hi Simon Glass,
> > I'm actually trying to boot up udoo_neo board with minimal configuration
> > (512 MB Ram) at the moment using the following cmd to flash the board
> > I'm no able to boot it (flashing uSD with ):
> >  - sudo dd if=u-boot-with-spl.imx of=/dev/sde bs=1k seek=1 conv=fsync
> >    (don't work)
> >  - sudo dd if=SPL of=/dev/sde bs=1K seek=1
> >  - sudo dd if=u-boot.img of=/dev/sde bs=1K seek=69
> >    (don't work)
> > I'm building uboot using:
> >  - make udoo_neo_defconfig
> >  - make
> > Are you able to boot the board with basic configuration (UDOO_NEO_TYPE_BASIC)?
> > I found this uboot on the web and with that I'm able to boot the board:
> >  - https://github.com/UDOOboard/uboot-imx
> > Can you give me one help on that? Are you abe to boot the board?
> 
> Please try this patch series from Peter:
> https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/
> 
> Does it boot for you after applying this series?

Hi Fabio,
I test this series. By that I'm able to boot the board from uSD.
Thanks.

Below some log's from the board:

U-Boot SPL 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
Trying to boot from MMC1


U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)

CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo UNDEFINED
DRAM:  512 MiB
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0
=>

Why this series is not already merged on mainline?
Let me know.

Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>

Thanks,
Tommaso

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Tommaso,

On Wed, Dec 29, 2021 at 5:33 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:

> > Please try this patch series from Peter:
> > https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/
> >
> > Does it boot for you after applying this series?
>
> Hi Fabio,
> I test this series. By that I'm able to boot the board from uSD.
> Thanks.

Thanks for testing. Glad to know it is booting fine.

> Below some log's from the board:
>
> U-Boot SPL 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
> Trying to boot from MMC1
>
>
> U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
>
> CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
> Reset cause: POR
> Model: UDOO Neo Basic
> Board: UDOO Neo UNDEFINED

Could you please help to investigate this output? It should not print
"UNDEFINED".

Could you please add this debug patch below and let me know what it prints?

--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -301,6 +301,9 @@ static int get_board_value(void)

        r184 = gpio_get_value(IMX_GPIO_NR(4, 13));
        r185 = gpio_get_value(IMX_GPIO_NR(4, 0));
+
+       printf("********* r184 is %d\n", r184);
+       printf("********* r185 is %d\n", r185);

        /*
         * Machine selection -


> DRAM:  512 MiB
> MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:    serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@2188000
> Hit any key to stop autoboot:  0
> =>
>
> Why this series is not already merged on mainline?
> Let me know.

Hopefully, Tom or Stefano can pick up Peter's series in time for the
2022.01 release.

Thanks

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Hi Tommaso,

On Wed, Dec 29, 2021 at 5:51 PM Fabio Estevam <festevam@gmail.com> wrote:

> > U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
> >
> > CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> > CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
> > Reset cause: POR
> > Model: UDOO Neo Basic
> > Board: UDOO Neo UNDEFINED
>
> Could you please help to investigate this output? It should not print
> "UNDEFINED".

Please try this attached patch instead and share the U-Boot logs.

Thanks

[-- Attachment #2: 0001-udooneo_debug.patch --]
[-- Type: text/x-patch, Size: 2002 bytes --]

From 1033bf6c71c55225288a854d56abf7b9ca99e1f7 Mon Sep 17 00:00:00 2001
From: Fabio Estevam <festevam@gmail.com>
Date: Wed, 29 Dec 2021 18:03:47 -0300
Subject: [PATCH] udoo: neo: Fix the board version IOMUX

Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
 board/udoo/neo/neo.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index 92a1e084b524..8511f65ce60f 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -67,12 +67,6 @@ enum {
 #define WDOG_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PKE | PAD_CTL_SPEED_MED |	\
 	PAD_CTL_DSE_40ohm)
 
-#define BOARD_DETECT_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |		\
-	PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |		\
-	PAD_CTL_DSE_34ohm | PAD_CTL_HYS | PAD_CTL_SRE_FAST)
-#define BOARD_DETECT_PAD_CFG (MUX_PAD_CTRL(BOARD_DETECT_PAD_CTRL) |	\
-	MUX_MODE_SION)
-
 int dram_init(void)
 {
 	gd->ram_size = imx_ddr_size();
@@ -222,9 +216,9 @@ static iomux_v3_cfg_t const phy_control_pads[] = {
 
 static iomux_v3_cfg_t const board_recognition_pads[] = {
 	/*Connected to R184*/
-	MX6_PAD_NAND_READY_B__GPIO4_IO_13 | BOARD_DETECT_PAD_CFG,
+	MX6_PAD_NAND_READY_B__GPIO4_IO_13 | MUX_PAD_CTRL(NO_PAD_CTRL),
 	/*Connected to R185*/
-	MX6_PAD_NAND_ALE__GPIO4_IO_0 | BOARD_DETECT_PAD_CFG,
+	MX6_PAD_NAND_ALE__GPIO4_IO_0 | MUX_PAD_CTRL(NO_PAD_CTRL),
 };
 
 static iomux_v3_cfg_t const wdog_b_pad = {
@@ -296,12 +290,18 @@ static int get_board_value(void)
 	imx_iomux_v3_setup_multiple_pads(board_recognition_pads,
 					 ARRAY_SIZE(board_recognition_pads));
 
+	gpio_request(IMX_GPIO_NR(4, 13), "r184");
+	gpio_request(IMX_GPIO_NR(4, 0), "r185");
+
 	gpio_direction_input(IMX_GPIO_NR(4, 13));
 	gpio_direction_input(IMX_GPIO_NR(4, 0));
 
 	r184 = gpio_get_value(IMX_GPIO_NR(4, 13));
 	r185 = gpio_get_value(IMX_GPIO_NR(4, 0));
 
+	printf("********* r184 is %d\n", r184);
+	printf("********* r185 is %d\n", r185);
+
 	/*
 	 * Machine selection -
 	 * Machine          r184,    r185
-- 
2.25.1

Re: help on udoo_neo power up on mainline uboot

[Peter Robinson]

On Wed, Dec 29, 2021 at 9:06 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Tommaso,
>
> On Wed, Dec 29, 2021 at 5:51 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> > > U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
> > >
> > > CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> > > CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
> > > Reset cause: POR
> > > Model: UDOO Neo Basic
> > > Board: UDOO Neo UNDEFINED
> >
> > Could you please help to investigate this output? It should not print
> > "UNDEFINED".
>
> Please try this attached patch instead and share the U-Boot logs.

I'll give that a go shortly, that was still on my todo list do debug,
it was detecting it earlier in the boot for memory detection but
failing with a -6 when doing board detection and working later but
hadn't got to the bottom of it yet.

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Peter,

On Wed, Dec 29, 2021 at 6:14 PM Peter Robinson <pbrobinson@gmail.com> wrote:

> I'll give that a go shortly, that was still on my todo list do debug,
> it was detecting it earlier in the boot for memory detection but
> failing with a -6 when doing board detection and working later but
> hadn't got to the bottom of it yet.

I think I understand the issue: since get_board_value() is called from
SPL and U-Boot
proper, we need to call gpio_free(), otherwise, the gpio_request()
will be called on GPIOs
that were already requested.

Does the patch below fix the problem?

diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index 62f81fff6817..075c4f208f23 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -333,6 +333,8 @@ static int get_board_value(void)
         * Extended           1        1
         */

+       gpio_free(IMX_GPIO_NR(4, 13));
+       gpio_free(IMX_GPIO_NR(4, 0));
        return (r184 << 1) + r185;
 }

Thanks

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Wed, Dec 29, 2021 at 05:51:14PM -0300, Fabio Estevam wrote:
> Hi Tommaso,
> 
> On Wed, Dec 29, 2021 at 5:33 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> 
> > > Please try this patch series from Peter:
> > > https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/
> > >
> > > Does it boot for you after applying this series?
> >
> > Hi Fabio,
> > I test this series. By that I'm able to boot the board from uSD.
> > Thanks.
> 
> Thanks for testing. Glad to know it is booting fine.
> 
> > Below some log's from the board:
> >
> > U-Boot SPL 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
> > Trying to boot from MMC1
> >
> >
> > U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 29 2021 - 21:22:30 +0100)
> >
> > CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> > CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
> > Reset cause: POR
> > Model: UDOO Neo Basic
> > Board: UDOO Neo UNDEFINED
> 
> Could you please help to investigate this output? It should not print
> "UNDEFINED".
> 
> Could you please add this debug patch below and let me know what it prints?

Hi Fabio,
I'll check and let u know. This patch these gpio's to get righ ram cfg
right?

Let me know.

Thanks,
Tommaso

> 
> --- a/board/udoo/neo/neo.c
> +++ b/board/udoo/neo/neo.c
> @@ -301,6 +301,9 @@ static int get_board_value(void)
> 
>         r184 = gpio_get_value(IMX_GPIO_NR(4, 13));
>         r185 = gpio_get_value(IMX_GPIO_NR(4, 0));
> +
> +       printf("********* r184 is %d\n", r184);
> +       printf("********* r185 is %d\n", r185);
> 
>         /*
>          * Machine selection -
> 
> 
> > DRAM:  512 MiB
> > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... OK
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   eth0: ethernet@2188000
> > Hit any key to stop autoboot:  0
> > =>
> >
> > Why this series is not already merged on mainline?
> > Let me know.
> 
> Hopefully, Tom or Stefano can pick up Peter's series in time for the
> 2022.01 release.
> 
> Thanks

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Tommaso,

On Wed, Dec 29, 2021 at 7:08 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:

> Hi Fabio,
> I'll check and let u know. This patch these gpio's to get righ ram cfg
> right?
>
> Let me know.

Yes, according to Peter, the failure comes only during the second call
to get_board_value()

I think the patch below should fix it:

diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index 62f81fff6817..075c4f208f23 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -333,6 +333,8 @@ static int get_board_value(void)
         * Extended           1        1
         */

+       gpio_free(IMX_GPIO_NR(4, 13));
+       gpio_free(IMX_GPIO_NR(4, 0));
        return (r184 << 1) + r185;
 }

Thanks

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Peter and Tommaso,

On Wed, Dec 29, 2021 at 7:38 PM Fabio Estevam <festevam@gmail.com> wrote:

> Yes, according to Peter, the failure comes only during the second call
> to get_board_value()

I managed to get my Udoo Neo board working again.

With only the change below on top of Peter's series, I can get the
board version to be printed correctly:

--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -383,18 +383,13 @@ static char *board_string(void)
        return "UNDEFINED";
 }

-int checkboard(void)
-{
-       printf("Board: UDOO Neo %s\n", board_string());
-       return 0;
-}
-
 int board_late_init(void)
 {
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
        env_set("board_name", board_string());
 #endif

+       printf("Board: UDOO Neo %s\n", board_string());
        return 0;
 }

U-Boot log:

U-Boot SPL 2022.01-rc4-00031-gc5c4ced998e3-dirty (Dec 29 2021 - 20:03:26 -0300)
Trying to boot from MMC1


U-Boot 2022.01-rc4-00031-gc5c4ced998e3-dirty (Dec 29 2021 - 20:03:26 -0300)

CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 64C
Reset cause: POR
Model: UDOO Neo Basic
I2C:   ready
DRAM:  1 GiB
PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Board: UDOO Neo FULL
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0
ethernet@2188000 Waiting for PHY auto negotiation to
complete.......user interrupt!
Could not initialize PHY ethernet@2188000
BOOTP broadcast 1

Re: help on udoo_neo power up on mainline uboot

[Peter Robinson]

On Wed, Dec 29, 2021 at 9:51 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peter,
>
> On Wed, Dec 29, 2021 at 6:14 PM Peter Robinson <pbrobinson@gmail.com> wrote:
>
> > I'll give that a go shortly, that was still on my todo list do debug,
> > it was detecting it earlier in the boot for memory detection but
> > failing with a -6 when doing board detection and working later but
> > hadn't got to the bottom of it yet.
>
> I think I understand the issue: since get_board_value() is called from
> SPL and U-Boot
> proper, we need to call gpio_free(), otherwise, the gpio_request()
> will be called on GPIOs
> that were already requested.
>
> Does the patch below fix the problem?
>
> diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
> index 62f81fff6817..075c4f208f23 100644
> --- a/board/udoo/neo/neo.c
> +++ b/board/udoo/neo/neo.c
> @@ -333,6 +333,8 @@ static int get_board_value(void)
>          * Extended           1        1
>          */
>
> +       gpio_free(IMX_GPIO_NR(4, 13));
> +       gpio_free(IMX_GPIO_NR(4, 0));
>         return (r184 << 1) + r185;

I actually have a patch locally that does exactly that and tried it a
few days ago but to no avail. I was trying to work out if it could be
done via DM but I couldn't work out how to do that. I'll dig into it
more tomorrow and report back.

P

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

On Wed, Dec 29, 2021 at 8:17 PM Peter Robinson <pbrobinson@gmail.com> wrote:

> I actually have a patch locally that does exactly that and tried it a
> few days ago but to no avail. I was trying to work out if it could be
> done via DM but I couldn't work out how to do that. I'll dig into it
> more tomorrow and report back.

mx6cubox does the board type detection via DM. Take a look at
"solidrun,hummingboard-detect"

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Wed, Dec 29, 2021 at 08:07:04PM -0300, Fabio Estevam wrote:
> Hi Peter and Tommaso,
> 
> On Wed, Dec 29, 2021 at 7:38 PM Fabio Estevam <festevam@gmail.com> wrote:
> 
> > Yes, according to Peter, the failure comes only during the second call
> > to get_board_value()
> 
> I managed to get my Udoo Neo board working again.
> 
> With only the change below on top of Peter's series, I can get the
> board version to be printed correctly:
> 
> --- a/board/udoo/neo/neo.c
> +++ b/board/udoo/neo/neo.c
> @@ -383,18 +383,13 @@ static char *board_string(void)
>         return "UNDEFINED";
>  }
> 
> -int checkboard(void)
> -{
> -       printf("Board: UDOO Neo %s\n", board_string());
> -       return 0;
> -}
> -
>  int board_late_init(void)
>  {
>  #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>         env_set("board_name", board_string());
>  #endif
> 
> +       printf("Board: UDOO Neo %s\n", board_string());
>         return 0;
>  }
> 
> U-Boot log:
> 
> U-Boot SPL 2022.01-rc4-00031-gc5c4ced998e3-dirty (Dec 29 2021 - 20:03:26 -0300)
> Trying to boot from MMC1
> 
> 
> U-Boot 2022.01-rc4-00031-gc5c4ced998e3-dirty (Dec 29 2021 - 20:03:26 -0300)
> 
> CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 64C
> Reset cause: POR
> Model: UDOO Neo Basic
> I2C:   ready
> DRAM:  1 GiB
> PMIC:  PFUZE3000 DEV_ID=0x30 REV_ID=0x11
> MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:    serial
> Out:   serial
> Err:   serial
> Board: UDOO Neo FULL
> Net:   eth0: ethernet@2188000
> Hit any key to stop autoboot:  0
> ethernet@2188000 Waiting for PHY auto negotiation to
> complete.......user interrupt!
> Could not initialize PHY ethernet@2188000
> BOOTP broadcast 1

Hi Fabio,
I test BASIC board and it work too, below some log:

U-Boot SPL 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 30 2021 - 00:20:36 +0100)
Trying to boot from MMC1


U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Dec 30 2021 - 00:20:36 +0100)

CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 46C
Reset cause: POR
Model: UDOO Neo Basic
DRAM:  512 MiB
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Board: UDOO Neo BASIC
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0

Acked-by: Tommaso Merciai <tomm.merciai@gmail.com>
Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>

Well play :)

I think all the series can me merged now, what do you think
about? You need a clear series?
Let me know.

Thanks,
Tommaso

Re: help on udoo_neo power up on mainline uboot

[Peter Robinson]

On Wed, Dec 29, 2021 at 11:07 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peter and Tommaso,
>
> On Wed, Dec 29, 2021 at 7:38 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> > Yes, according to Peter, the failure comes only during the second call
> > to get_board_value()
>
> I managed to get my Udoo Neo board working again.
>
> With only the change below on top of Peter's series, I can get the
> board version to be printed correctly:
>
> --- a/board/udoo/neo/neo.c
> +++ b/board/udoo/neo/neo.c
> @@ -383,18 +383,13 @@ static char *board_string(void)
>         return "UNDEFINED";
>  }
>
> -int checkboard(void)
> -{
> -       printf("Board: UDOO Neo %s\n", board_string());
> -       return 0;
> -}
> -
>  int board_late_init(void)
>  {
>  #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>         env_set("board_name", board_string());
>  #endif
>
> +       printf("Board: UDOO Neo %s\n", board_string());
>         return 0;
>  }

That works for my Full board. Interestingly in my playing I had got to
similar and had wondered about whether the checkboard function was
needed.

One minor query on the above is it worth assigning the board_string
return to a local variable rather than called the function twice?
Either way feel free to add my RB/TB or let me know if you want me to
send a patch.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>

diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index d374b86b5d..41790df1bf 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -204,6 +204,9 @@ static int get_board_value(void)
        r184 = gpio_get_value(IMX_GPIO_NR(4, 13));
        r185 = gpio_get_value(IMX_GPIO_NR(4, 0));

+       gpio_free(IMX_GPIO_NR(4, 13));
+       gpio_free(IMX_GPIO_NR(4, 0));
+
        /*
         * Machine selection -
         * Machine          r184,    r185
@@ -260,8 +263,9 @@ static char *board_string(void)
                return "FULL";
        case UDOO_NEO_TYPE_EXTENDED:
                return "EXTENDED";
+       default:
+               return "UNDEFINED";
        }
-       return "UNDEFINED";
 }

 int checkboard(void)
@@ -270,8 +274,15 @@ int checkboard(void)
        return 0;
 }

+int show_board_info(void)
+{
+       printf("BLAH Board: UDOO Neo %s\n", board_string());
+        return 0;
+}
+
 int board_late_init(void)
 {
+       printf("Board: UDOO Neo %s\n", board_string());
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
        env_set("board_name", board_string());
 #endif

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Peter,

On Thu, Dec 30, 2021 at 11:08 AM Peter Robinson <pbrobinson@gmail.com> wrote:

> That works for my Full board. Interestingly in my playing I had got to
> similar and had wondered about whether the checkboard function was
> needed.
>
> One minor query on the above is it worth assigning the board_string
> return to a local variable rather than called the function twice?
> Either way feel free to add my RB/TB or let me know if you want me to
> send a patch.
> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
> Tested-by: Peter Robinson <pbrobinson@gmail.com>

Thanks for testing. I can send a formal patch after your series gets applied.

Re: help on udoo_neo power up on mainline uboot

[Peter Robinson]

On Thu, Dec 30, 2021 at 2:12 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peter,
>
> On Thu, Dec 30, 2021 at 11:08 AM Peter Robinson <pbrobinson@gmail.com> wrote:
>
> > That works for my Full board. Interestingly in my playing I had got to
> > similar and had wondered about whether the checkboard function was
> > needed.
> >
> > One minor query on the above is it worth assigning the board_string
> > return to a local variable rather than called the function twice?
> > Either way feel free to add my RB/TB or let me know if you want me to
> > send a patch.
> > Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
> > Tested-by: Peter Robinson <pbrobinson@gmail.com>
>
> Thanks for testing. I can send a formal patch after your series gets applied.

Actually, doing a full boot I get
ERROR: invalid device tree
Found EFI removable media binary efi/boot/bootarm.efi
1929216 bytes read in 92 ms (20 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC

And if I interrupt boot and do printenv I get fdtfile=undefined so
while it fixes the detection and printing of the actual model it seems
it's too load for the device tree file logic, which now why I remember
I was looking at the show_board_info function above, the
board_late_init seems to late for the DT logic.

P

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Thu, Dec 30, 2021 at 02:20:07PM +0000, Peter Robinson wrote:
> On Thu, Dec 30, 2021 at 2:12 PM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > Hi Peter,
> >
> > On Thu, Dec 30, 2021 at 11:08 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > > That works for my Full board. Interestingly in my playing I had got to
> > > similar and had wondered about whether the checkboard function was
> > > needed.
> > >
> > > One minor query on the above is it worth assigning the board_string
> > > return to a local variable rather than called the function twice?
> > > Either way feel free to add my RB/TB or let me know if you want me to
> > > send a patch.
> > > Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
> > > Tested-by: Peter Robinson <pbrobinson@gmail.com>
> >
> > Thanks for testing. I can send a formal patch after your series gets applied.
> 
> Actually, doing a full boot I get
> ERROR: invalid device tree
> Found EFI removable media binary efi/boot/bootarm.efi
> 1929216 bytes read in 92 ms (20 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> 
> And if I interrupt boot and do printenv I get fdtfile=undefined so
> while it fixes the detection and printing of the actual model it seems
> it's too load for the device tree file logic, which now why I remember
> I was looking at the show_board_info function above, the
> board_late_init seems to late for the DT logic.
> 
> P

Hi Peter, Fabio,
What do you think about this solution:

First create new static entry in gd:

+++ b/include/asm-generic/global_data.h
@@ -459,6 +459,7 @@ struct global_data {
         */
        char *smbios_version;
 #endif
+       int board_cfg;
 };
 #ifndef DO_DEPS_ONLY
 static_assert(sizeof(struct global_data) == GD_SIZE);

I know maybe is not a clean solution but we can work on it.
After, I store inside this variable the configuration
calling get_board_value() function from spl:

 static void spl_dram_init(void)
 {
-       int board = get_board_value();
+       gd->board_cfg = get_board_value();

        struct mx6_ddr_sysinfo sysinfo = {
                .dsize = 1, /* width of data bus: 1 = 32 bits */
@@ -471,7 +400,7 @@ static void spl_dram_init(void)
        };

        mx6sx_dram_iocfg(32, &mx6_ddr_ioregs, &mx6_grp_ioregs);
-       if (board == UDOO_NEO_TYPE_BASIC || board == UDOO_NEO_TYPE_BASIC_KS)
+       if (gd->board_cfg == UDOO_NEO_TYPE_BASIC || gd->board_cfg == UDOO_NEO_TYPE_BASIC_KS)
                mx6_dram_cfg(&sysinfo, &neo_basic_mmcd_calib,
                             &neo_basic_mem_ddr);


Then I use gd->board_cfg in board_string function:

 static char *board_string(void)
 {
-       switch (get_board_value()) {
+       switch (gd->board_cfg) {
        case UDOO_NEO_TYPE_BASIC:
                return "BASIC";
        case UDOO_NEO_TYPE_BASIC_KS:

On full boot I get the right environment variable for fdtfile, and the
right strings on Model and Board print:

fdtfile=imx6sx-udoo-neo-basic.dtb

Environment size: 4338/8188 bytes
=>
U-Boot SPL 2022.01-rc4-00030-gb3f84a939f-dirty (Jan 02 2022 - 00:01:42 +0100)
DEBUG FUNC = get_board_value, LINE = 274, r184 = 0
DEBUG FUNC = get_board_value, LINE = 275, r184 = 0
Trying to boot from MMC1


U-Boot 2022.01-rc4-00030-gb3f84a939f-dirty (Jan 02 2022 - 00:01:42 +0100)

CPU:   Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 44C
Reset cause: POR
Model: UDOO Neo Basic
Board: UDOO Neo BASIC
DRAM:  512 MiB
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2188000 [PRIME]
Hit any key to stop autoboot:  0


What do you think about this solution?
Let me know.

Thanks,
Tommaso

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Tommaso,

On Sat, Jan 1, 2022 at 8:22 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:

> Hi Peter, Fabio,
> What do you think about this solution:
>
> First create new static entry in gd:
>
> +++ b/include/asm-generic/global_data.h
> @@ -459,6 +459,7 @@ struct global_data {
>          */
>         char *smbios_version;
>  #endif
> +       int board_cfg;

No need to add this new 'board_cfg' field entry.

Please use the existing 'board_type' field instead:

#ifdef CONFIG_BOARD_TYPES
/**
* @board_type: board type
*
* If a U-Boot configuration supports multiple board types, the actual
* board type may be stored in this field.
*/
unsigned long board_type;
#endif

Please make sure to add CONFIG_BOARD_TYPES=y in the defconfig.

> What do you think about this solution?
> Let me know.

I like your solution.

The only suggestion is to use the existing 'gd->board_type' and then
feel free to submit a formal patch.

Thanks!

Fabio Estevam

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Sat, Jan 01, 2022 at 10:24:29PM -0300, Fabio Estevam wrote:
> Hi Tommaso,
> 
> On Sat, Jan 1, 2022 at 8:22 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> 
> > Hi Peter, Fabio,
> > What do you think about this solution:
> >
> > First create new static entry in gd:
> >
> > +++ b/include/asm-generic/global_data.h
> > @@ -459,6 +459,7 @@ struct global_data {
> >          */
> >         char *smbios_version;
> >  #endif
> > +       int board_cfg;
> 
> No need to add this new 'board_cfg' field entry.
> 
> Please use the existing 'board_type' field instead:
> 
> #ifdef CONFIG_BOARD_TYPES
> /**
> * @board_type: board type
> *
> * If a U-Boot configuration supports multiple board types, the actual
> * board type may be stored in this field.
> */
> unsigned long board_type;
> #endif
> 
> Please make sure to add CONFIG_BOARD_TYPES=y in the defconfig.
> 
> > What do you think about this solution?
> > Let me know.
> 
> I like your solution.
> 
> The only suggestion is to use the existing 'gd->board_type' and then
> feel free to submit a formal patch.
> 
> Thanks!
> 
> Fabio Estevam

Hi Fabio,
I need to create a patch on top of your patch series that re-enable
boot from uSD. Your series is already merged? just repull from master?
If not, can you give me some reference of your branch?

Or, I just send a patch on top of you series applied locally?

Let me know.

Thanks,
Tommaso Merciai

Re: help on udoo_neo power up on mainline uboot

[Fabio Estevam]

Hi Tommaso,

On Sun, Jan 2, 2022 at 2:14 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:

> Hi Fabio,
> I need to create a patch on top of your patch series that re-enable
> boot from uSD. Your series is already merged? just repull from master?
> If not, can you give me some reference of your branch?
>
> Or, I just send a patch on top of you series applied locally?
>
> Let me know.

Actually, it is the series from Peter that adds DM support to udoo_neo
and makes it functional again:
https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/

My suggestion is that you apply Peter's series locally, then generate
a patch with your fix to the
"Board: UDOO Neo UNDEFINED" message.

Thanks

Re: help on udoo_neo power up on mainline uboot

[Tommaso Merciai]

On Sun, Jan 02, 2022 at 02:36:07PM -0300, Fabio Estevam wrote:
> Hi Tommaso,
> 
> On Sun, Jan 2, 2022 at 2:14 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> 
> > Hi Fabio,
> > I need to create a patch on top of your patch series that re-enable
> > boot from uSD. Your series is already merged? just repull from master?
> > If not, can you give me some reference of your branch?
> >
> > Or, I just send a patch on top of you series applied locally?
> >
> > Let me know.
> 
> Actually, it is the series from Peter that adds DM support to udoo_neo
> and makes it functional again:
> https://lore.kernel.org/all/20211221123249.455347-1-pbrobinson@gmail.com/T/
> 
> My suggestion is that you apply Peter's series locally, then generate
> a patch with your fix to the
> "Board: UDOO Neo UNDEFINED" message.
> 
> Thanks

Thanks Fabio for your suggestion, sent.
Let me know.

Tommaso Merciai