Hi Michael,
On 11/2/2026 3:20 pm, Michael Nazzareno Trimarchi 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.]
Hi
On Wed, Feb 11, 2026 at 8:14 AM Maniyam, Dinesh
<[email protected]> wrote:
Hi Tom,
On 3/2/2026 10:57 pm, Tom Rini wrote:
On Tue, Feb 03, 2026 at 03:47:17PM +0800,[email protected] wrote:
From: Dinesh Maniyam<[email protected]>
The SPL NAND MTD framework requires working driver model support
and sufficient memory resources, which are not available on all
platforms.
Introduce a SPL_NAND_FRAMEWORK_CAPABLE Kconfig option to allow
platforms to explicitly advertise support for compiling the full
NAND/MTD framework into SPL.
This avoids accidental enablement of the SPL NAND framework on
platforms that cannot support it and provides a clear capability
boundary for platform maintainers.
This what I have asked in the beginning, for now I don't like to have
this change
in the framework unless we have more consumer. For the patch that you sent for
make simple spl load, I will try to start to apply on one of my board
Michael
Just to clarify, when you mentioned “simple SPL load”, were you referring
to the generic MTD-based SPL NAND loader I introduced?
If you meant the generic MTD-based loader, I’m preparing a newer RFC
version that clarifies the scope and usage. It may be easier to test
against that version, if you don’t mind waiting for it.
Dinesh
Signed-off-by: Dinesh Maniyam<[email protected]>
---
drivers/mtd/nand/raw/Kconfig | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index e0ff28cb21b..d73d8ed4404 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -809,6 +809,36 @@ config SYS_NAND_HW_ECC_OOBFIRST
bool "In SPL, read the OOB first and then the data from NAND"
depends on SPL_NAND_SIMPLE
+config SPL_NAND_FRAMEWORK_CAPABLE
+ bool
+ depends on SPL_DM
+ depends on SPL_HAS_BSS_LINKER_SECTION
+ depends on SPL_MAX_SIZE >= 0x40000
+ help
+ Indicates that the platform has sufficient SPL capabilities
+ (driver model, BSS support, and SRAM size) to support the
+ full NAND/MTD framework in SPL.
+
+config SPL_NAND_USE_NAND_FRAMEWORK
+ bool "Use NAND/MTD framework in SPL"
+ depends on SPL_NAND_SUPPORT && MTD
+ depends on SPL_NAND_FRAMEWORK_CAPABLE
+ depends on SPL_ENV_SUPPORT
+ depends on ENV_IS_IN_NAND
+ select SPL_SYS_NAND_SELF_INIT
+ select SPL_NAND_BASE
+ select SPL_NAND_DRIVERS
+ select SPL_NAND_IDENT
+ select SPL_NAND_INIT
+ select SPL_NAND_ECC
+ help
+ Enable loading U-Boot from NAND in SPL using the full
+ NAND/MTD framework instead of the minimal SPL NAND loaders.
+ This provides bad-block aware reads and flexible offset
+ handling via the common NAND/MTD infrastructure.
+ Platforms enabling this option must also provide working
+ driver model support and sufficient SPL memory resources.
+
endif # if SPL
endif # if MTD_RAW_NAND
This still gets it backwards. Whatever depends on SPL_DM needs to add
it. The max size is something that needs to be set for your platforms.
The BSS requirement is not correct (there are platforms today without
that set).
Thanks for the input.
Understood — the capability-style symbol is not the right approach
here. I’ll drop SPL_NAND_FRAMEWORK_CAPABLE and instead move the
required dependencies directly onto SPL_NAND_USE_NAND_FRAMEWORK.
I’ll also remove the SPL_MAX_SIZE and BSS assumptions from the
generic Kconfig and ensure the appropriate limits and options are set
in the affected platform configurations instead.
I’ll rework the patch accordingly.
Dinesh
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
[email protected]
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
[email protected]
www.amarulasolutions.com
