Hi, > Hi, > > + Pratush, > + Vignesh, > + Marek, > > On 2/18/26 11:23 AM, Miquel Raynal wrote: > > Hello Tom, > > > > On 16/02/2026 at 09:31:10 -06, Tom Rini <[email protected]> wrote: > > > >> On Mon, Feb 16, 2026 at 09:21:55AM +0100, Michael Walle wrote: > >>> On Sat Feb 14, 2026 at 7:58 PM CET, Conor Dooley wrote: > >>>> On Fri, Feb 13, 2026 at 10:46:07AM -0600, Tom Rini wrote: > >>>>> Hey all, > >>>>> > >>>>> To be blunt, U-Boot needs help with reviewing and maintaining the SPI > >>>>> and SPI-NOR subsystems. We haven't had someone with time to actively > >>>>> work in this area for some time. I'm going through the outstanding > >>>>> changes now, but it also seems a common problem is that with respect to > >>>>> device IDs, most of the new ones also aren't in the upstream Linux > >>>>> Kernel. Is there some better and generic solution we're missing so that > >>>>> we don't have large and often growing device ID tables? I'd rather not > >>>>> make that problem worse, so I've rejected two of those types of updates > >>>>> today and I'm just setting aside a large number of others. > >>>> > >>>> Dunno if your timing was cursed on sending this, but Tudor submitted his > >>>> resignation from spi-nor maintainership in the kernel about 10 mins > >>>> after. > >>>> I think Michael Walle might be responsible for what you're talking about > >>>> here, with his 773bbe1044973 ("mtd: spi-nor: add generic flash driver"), > >>>> but idk jack about spi-nor stuff. > >>> > >>> Yeah. Nowadays SPI-NOR flashes come with self describing tables, > >>> which are already supported by u-boot, I think. The only change that > >>> seems to be missing is the fallback to it if an id isn't found in > >>> the flashdb. Only thing is, the SFDP doesn't describe all features, > >>> most prominent example being locking. So if you need that, you'll > >>> still need to have an entry per flash. > >>> > >>> In fact, in linux I'm planning to change to make it probe SFDP first > >>> and then amend it with the flashdb information (if there is an > >>> entry). > >> > >> Thanks for explaining. So in that U-Boot does have SFDP support, the > >> first thing is platforms should likely be enabling that instead of just > >> adding IDs, at least for basic support. > > Right. > > SFDP is behind a config, because of size constraints I assume. And then we > also have a tiny duplicate version of the driver for stricter size > constraints. Are these size constraints defined somewhere? We need to know > them in order to choose a direction. > > Also, I'd argue that having the tiny version of the driver was ideal. > Instead we should have tried to modularize SPI NOR, by SFDP, static > initialization of flashes, manufacturer drivers. > > > > > Yes. There will be the need for IDs anyways, for those "extra" "non > > sfdp" features, but that should reduce the load. For example, shall we > > consider block protection in U-Boot or not? This is a useful feature, > > but at the same time, do we really need it in a Bootloader? This is open > > to discussion. > > If you have write capability in u-boot, having block protection is useful > to avoid inadvertent writes. > > > > >> It still leaves us in a bad spot > >> about having SPI and SPI-NOR stuff reviewed and maintained, but at least > >> it's clearer in public now where it stands. > > Takahiro recently accepted becoming a designated reviewer for SPI NOR > in Linux, and I think his expertise would be highly valuable in U-Boot > as well. Takahiro, if you have the bandwidth, would you be open to > becoming a designated reviewer here too? Or maybe see how things are > going in Linux first? No pressure. > Yes, I'm open to do that.
To sync with Linux, we need to isolate stacked/parallel support from core first. https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ > Cheers, > ta > > > > > I guess spi-mem and SPI NAND is also in this kind of situation, even > > with the Amarula crew doing what they can to improve the situation. > > > > Thanks, > > Miquèl Thanks, Takahiro
