Hi all,

I am working on updating our version of u-boot, and came across something weird - the SPL hangs after "Trying to load NAND" on the first power-on boot, but after a watchdog reset or power-on reset, the NAND works fine.

U-Boot SPL 2021.01-00010-g8c91cf967b-dirty (Aug 30 2021 - 19:03:45 -0500) Trying to boot from NAND <<<< hangs here until watchdog reset

After checking more common issues - pinmux/config/timing/NAND connections, etc. and printf-tracing it, it is actually hanging after board_nand_init and at this call to select_chip before getting to NAND_CMD_RESET:

drivers/mtd/nand/raw/am335x_spl_bch.c: nand_init() ... board_nand_init(&nand_chip);

if (nand_chip.select_chip) nand_chip.select_chip(mtd, 0); <<<< stuck here ??? <<<<

/* NAND chip may require reset after power-on */ nand_command(0, 0, 0, NAND_CMD_RESET); ...

Somehow, the first power up, nand_chip.select_chip is set to 0xFFFFFFFF, so it hangs at that point. Whereas future power-on resets have the location cleared to 0, so it works fine...

Explicitly setting select_chip to NULL in the call to board_nand_init for omap_gpmc makes everything work fine:

drivers/mtd/nand/raw/omap_gpmc.c: board_nand_init() ... writel(gpmc_config, &gpmc_cfg->config)

+ nand->select_chip = NULL; + nand->IO_ADDR_R = (void __iomem *)&gpmc_cfg->cs[cs].nand_dat; ...

But now I am worried about other things not being cleared out properly at reset... The am335x SPL NAND driver is pretty old and presumably well-tested code, so I was kinda surprised at this fix working. Would anyone know if a configuration setting, compiler setting or similar contributes to this? Or is it some artifact of the power-up state of the board?

Is there a better way of 'clearing' the static nand_chip struct in am335x_spl_bch.c, or is there really a missing setup of this function pointer somewhere for am335x_spl_bch/omap_gpmc?

This is against TI's u-boot @ d77252021a85c72d7ff9a4e151b81c4b4b9e1205 , with a Variscite VAR-SOM-AM33 module. Just wanted to check with the list to see if I am missing something...

Thanks, Kevin