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

[Vignesh R]

On Wednesday 03 January 2018 02:54 PM, Jagan Teki wrote:
> On Wed, Jan 3, 2018 at 2:18 PM, Vignesh R <vigneshr at ti.com> wrote:
>>
[...]
>>>>>
>>>>> =======================================
>>>>>              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, 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.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. 

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

> 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.


> 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.


-- 
Regards
Vignesh