[U-Boot] [PATCH v10 00/27] dm: Generic MTD Subsystem, with SPI-NOR interface

Wed Jan 3 10:59:42 UTC 2018

Hi Jagan,

> On Wed, Jan 3, 2018 at 2:18 PM, Vignesh R <vigneshr at ti.com> wrote:
> >
> >
> > On Tuesday 02 January 2018 03:39 PM, Jagan Teki wrote:  
> >> On Thu, Dec 28, 2017 at 8:14 PM, Lukasz Majewski <lukma at denx.de>
> >> wrote:  
> >>> Hi Jagan,
> >>>  
> >>>> Compared to previous series’s [1], [2], [3] and [4] this patch
> >>>> set redefined most of the implementation suitable to fit into
> >>>> existing driver-model.
> >>>>
> >>>> MTD is generic subsystem for underlying flash devices like nand,
> >>>> parallel nor, spinor, dataflash etc. So to drive this theory with
> >>>> driver model(with an example of block layer) mtd is common device
> >>>> interaction for most of  memory technology flashes like nand,
> >>>> parallel nor, spinor, dataflash etc, these are treated as
> >>>> interface types wrt u-boot driver model.
> >>>>
> >>>> Once the respective interface driver bind happen, the uclass
> >>>> driver will pass an 'interface type' to mtd layer to create
> >>>> device for it, for example once spinor ULASS_SPI_NOR driver bind
> >>>> happen, the uclass driver of spinor will pass MTD_IF_TYPE_SPI_NOR
> >>>> interface type to create mtd device for spinor devices.
> >>>>
> >>>> SPI-NOR:
> >>>> =======
> >>>> Some of the SPI device drivers at drivers/spi not a real
> >>>> spi controllers, Unlike normal/generic SPI controllers they
> >>>> operates only with SPI-NOR flash devices. these were technically
> >>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> >>>>
> >>>> The problem with these were resides at drivers/spi is entire
> >>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
> >>>> a wrong indication where SPI layer getting effected more with
> >>>> flash operations - So this SPI-NOR core will resolve this issue
> >>>> by separating all SPI-NOR flash operations from spi layer and
> >>>> creats a generic layer called SPI-NOR core which can be used to
> >>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> >>>> controller driver.  
> >>>
> >>> I must admit that I'm a bit confused....
> >>>
> >>> If you don't mind I would like to ask for clarification of a few
> >>> things:
> >>>
> >>>
> >>>  
> >>>>
> >>>> =======================================
> >>>>              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. 
> >>>
> >>>                 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.  
> >
> > 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 by spi-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.  
> 
> I know how hard it is adding new command in u-boot, 

Yes, it is. Especially command which duplicates already present
functionality.

> you can understood
> the reason for adding new command if you follow the previous versions
> on this series and I hope you does. 

I must admit that this is the first version, which I reviewed.

The only feasible way would be to have new Kconfig option for this
framework, force spinor for new boards and ..... wait.

After some long time (how long do we struggle with DM
conversion/Kconfig?) we could think about removing "sf" command.

I do want to emphasis that I do agree with Vignesh - there are many
boards out there, which do use sf command, with even more dangerous
situation when company X only plan to update u-boot, but has envs in a
separate partition. Breaking "sf" equals to brick of on-field
devices....

IMHO - we shall have sf command as an alias to new "spinor" command
(even by calling run_command("spinor....");).

> we have been adding mtd, spi-nor
> changes to existing mtd/spi and sf.c since 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. 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. 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.
> 
> Will all these new framework design, driver model, feasibility to sync
> Linux spi-nor.c we adding relevant command, and env.
> 

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180103/bd12ca0b/attachment.sig>