On Wed, Jan 10, 2024 at 06:06:45PM +0200, Roger Quadros wrote:
+Lukasz & Mattijs
On 10/01/2024 11:34, Roger Quadros wrote:
On 09/01/2024 22:00, Francesco Dolcini wrote:
On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote:
On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote:
On 14:26-20240109, Roger Quadros wrote:
CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y +CONFIG_CMD_MTDPARTS=y +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)"
Why not handle this as device tree partitions?
I honestly forget what the preferred way of defining and passing NAND partition information is these days. It might even be the funny case that passing as cmdline args is "best" rather than fixed-partitions binding?
According to past discussions [1] doing the fixup in U-Boot is not advised.
Using the command line or having the partition fixed in the DT are both valid options.
[1] https://lore.kernel.org/all/20230206224838.75963-1-francesco@dolcini.it/
Francesco
This was not about passing mtdparts to kernel but about getting 'mtdparts' command to work at u-boot. I need to figure out why OF partition parser didn't work here.
For a start I didn't have CONFIG_MTD_PARTITIONS set. Maybe I'm missing something more.
The issue was the NAND driver was not setting chip->dev and chip->ofnode correctly. Now 'mtd list' shows partitions from the DT. But, 'dfu 0 nand list' still fails like so. "mtdparts variable not set, see 'help mtdparts'"
Looks like dfu_nand driver doesn't fall back to OF partitions if mtdparts environment is not defined.
Should we add OF partitions support to dfu_nand driver or is it deprecated in favor of dfu_mtd driver?
I would rather not have to populate the env variable as that will lead to confusion later on I fear (make a change and it's not populated onward).