dm: Generic MTD Subsystem, with SPI-NOR interface
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v10 Latest posting 2/20 of 27 patches 0 repliesNew
- v10 posting 1/22 of 27 patches 0 repliesSuperseded
Patches in v10 posting 2/2 No applies recorded yet
None of the 27 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v10 yet.
Cover letter [U-Boot] [PATCH v10 00/27] dm: Generic MTD Subsystem, with SPI-NOR interface
Quoted 2 lines · Jagan Teki
Quoted 1 line · Vignesh R
[...]
Quoted 29 lines
Quoted 18 lines
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
=======================================
cmd/spinor.c^^^^^ - this would be a new set of commands to comply with DM?
with this series yes, and we're working on supporting the same with non-dm.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
What about "sf" command which we use now to get access to SPI-NOR memory? A lot of boards already use "sf" command... which may be tricky to replace.
end-goal will be replace sf with spinor command and removal of 'sf' will be done when the new spi-nor framework stable enough to handle all scenarios which are spi-flash supporting as of now.
Quoted 10 lines
I don't agree on adding new cmd and removing sf. It would be impractical to change all boot cmds to replace sf with spinor cmd all over U-Boot. Not to forget the envs already stored on non volatile media need updation to work with new cmd.
If SPI NOR framework is to abstract all accesses to nor flash devices in U-Boot, then why cannot it replace the logic implementing cmd sf? All that is changing is that mtd/spi/* is replaced byspi-nor.c+m25p80.c. sf probe can be modified achieve what spinor dev does
sf read for spinor read and so on. Board configs would just need to enable MTD related configs.
Quoted 6 lines
I know how hard it is adding new command in u-boot, you can understood the reason for adding new command if you follow the previous versions on this series and I hope you does. we have been adding mtd, spi-nor changes to existing mtd/spi and
sf.csince from first series and observed many issue with respective to framework design(where we move spi-nor controller drivers on to mtd side) along with driver model.
I don't remember. Its been a year since RFC v8 which used cmd_sf.c. Looking at the mailing list archives, I don't see any comments opposing cmd_sf.c and move to mtd command, that you used in v9
Quoted 8 lines
In v9 we worked on designing MTD UCLASS where mtd command can be commonly interfaced to all underlying flash devices. and from continuous evaluation on driver model this series we designed MTD uclass can be a generic and make run-time creation of underlying flash devices with interface type, spi-nor is one of the interface. So to make the framework suitable to command interface the new command named as spinor. adding/supporting all these new design on top of mtd/spi or sf doesn’t smooth easy which is proved on previous version.
Could you point to/summarize the exact problems that force us to move to spinor cmd? I failed to find them on archives.
Quoted 5 lines
technically sf termed as spi-flash comprise of spinor and spinand, spinand can be another interface type with spinand command and adding new features on legacy code doesn't make sense to me it will eventually breaking legacy dependencies.
AFAIK, spinand is not yet supported and can be added under MTD with different U-Boot cmd to access it.
Signature · 2 lines
Regards Vignesh