help on udoo_neo power up on mainline uboot
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
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:
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?
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:
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
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:
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
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
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
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.
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
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
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"
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
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
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
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
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
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.
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
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
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
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
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
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
participants (3)
-
Fabio Estevam -
Peter Robinson -
Tommaso Merciai