[PATCH v2] spl: Add generic SPL MTD loader support

[Maniyam, Dinesh]

Hi Fabio,
Thanks for the patch.

On 26/2/2026 1:10 pm, Sean Anderson wrote:
> [CAUTION: This email is from outside your organization. Unless you 
> trust the sender, do not click on links or open attachments as it may 
> be a fraudulent email attempting to steal your information and/or 
> compromise your computer.]
>
> On 2/25/26 19:08, Fabio Estevam wrote:
>> Hi Sean,
>>
>> On Wed, Feb 25, 2026 at 4:45 PM Sean Anderson <seanga2 at gmail.com> wrote:
>>
>>> Actually, I don't think this is correct. NAND devices have have 
>>> multiple MTDs for each
>>> CS, and SPI-NOR devices are UCLASS_SPI_FLASH and not UCLASS_MTD. So 
>>> I think it's better
>>> to do something like
>>>
>>>          mtd_probe_devices();
>>>          switch (bootdev->boot_device) {
>>>          case BOOT_DEVICE_NAND:
>>>                  mtd = get_mtd_device_nm(CONFIG_SPL_MTD_NAND_NAME);
>>>                  break;
>>>          case BOOT_DEVICE_SPI:
>>>                  mtd = 
>>> get_mtd_device_nm(CONFIG_SPL_MTD_SPI_FLASH_NAME);
>>>                  break;
>>>          default:
>>>                  mtd = ERR_PTR(-ENODEV);
>>>                  break;
>>>          }
>>>          if (IS_ERR(mtd)) {
>>>                  ret = PTR_ERR(mtd);
>>>                  goto out;
>>>          }
>> ...
>>
>>>> Actually, if CONFIG_SPL_NAND_SUPPORT is enabled then the native 
>>>> nand loader is compiled.
>>>> Maybe we should add a separate Kconfig for it 
>>>> (CONFIG_SPL_NAND_LOAD) defaulting to
>>>> SPL_NAND_SUPPORT. Then users can disable the "native" load method 
>>>> if they want to use MTD.
>>>
>>> I have a patch for this that I will try to send this week.
>>
>> If you would like to prepare a patch for the generic SPL MTD loader,
>> I'll be glad to test it.
>
> I can try, but I can't promise I'll be done with it in any particular 
> timeframe.
>
> But TBH I don't think a spi_nand.c-style loader is the right way to do 
> things when UBI exists.
> Maybe Dinesh can comment, but I don't really see the point except if 
> e.g. you are really short
> on space in SPL, but not so much that you can't fit in MTD.
>
> --Sean
>
> Based on our current design, we rely on the existing NAND framework 
> with only a minimal set
> of additional helper functions provided by the controller, which keeps 
> the SPL implementation simple and NAND-specific.
>
> The SPI-NAND SPL loader expects a broader set of common SPL 
> helpers which lead to compilation failures.
> Adapting to that model would require significant refactoring and 
> extensive testing,
> so for now we plan to continue using and extending the existing 
> |nand_spl_loaders.c|,
> which aligns better with the current SPL design and our constraints.
>
> --Dinesh
>