[U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)

[Rajat Srivastava]

Hi Stefan

> -----Original Message-----
> From: Stefan Roese <sr at denx.de>
> Sent: Friday, October 26, 2018 3:42 PM
> To: Rajat Srivastava <rajat.srivastava at nxp.com>; York Sun
> <york.sun at nxp.com>; Jagan Teki <jagan at openedev.com>
> Cc: u-boot at lists.denx.de; simon.k.r.goldschmidt at gmail.com; Ashish Kumar
> <ashish.kumar at nxp.com>
> Subject: Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs
> standard 3-byte mode)
> 
> Hi Rajat,
> 
> On 26.10.18 11:59, Rajat Srivastava wrote:
> 
> <snip>
> 
> >>  From what I read, Rajat's method is to extend the controller driver
> >> to support read SFDP and default to 4-byte mode if supported, or
> >> overwritten by user's flag. Stefan's method is to read 4-byte status
> >> bit and doesn't change controller driver.
> >>
> >> Is the default value of this 4-byte status bit valid and correct for
> >> all cases?
> >>
> >> Rajat, without your patch set, does Stefan's solution work for your board?
> >>
> >> York
> >
> > No. Stefan's changes are specific to his boards and is not applicable
> > on ours.
> > Stefan's patch is to support only certain flash that are factory
> > strapped to work in 4-byte addressing modes only and will default to
> > old method if such a flash is not found.
> 
> That is not 100% correct. The flash does not need to be "factory strapped" to
> this 4-byte mode. It needs to be configured to this 4-byte mode. And this is
> also the case for example, when the ROM bootloader configures the flash
> this way or a soft-reboot (without hard flash chip reset) reboots into U-Boot
> after the flash was configured to 4-byte mode in Linux.
> 
> And it supports multiple vendors and can easily be extended to support
> more. The only thing needed is the detection of the 3-byte vs 4-byte address
> mode. But please note that it currently does not actively switch from 3-byte
> to 4-byte mode. This could be added though if needed / wanted.

Spansion flashes (on our boards) support both 3-byte and 4-byte addressing modes which needs active switching. What could be added to your patch is already supported in SFDP method. SFDP also provides information about page size, flash density, read/write/erase commands, etc, in addition to getting information about address width supported by flash.

> 
> > The flashes on our
> > boards (and also other vendor's board) will not work with Stefan's
> > patch.
> >
> > My patch can handle flashes with address widths of 3-byte, 4-byte or
> > both. It also takes a more generic path (as opposed to supporting only
> > specific flash models) by parsing SFDP standard parameters and then
> > deciding what address width is to be used.
> 
> I still don't see why each and every SPI controller driver needs to be
> extended to support this SFDP parameter reading. Can't this be handled by
> some generic (read common) code part in the SPI flash infrastructure?

The generic (read common) code part in the SPI flash infrastructure also lands on respective SPI drivers which ultimately sends the commands to flash. Currently every SPI driver has support for basic read command (which is called after "generic read common code") but no driver has support for SFDP reading, which is what needs to be added.
Also, only the drivers that want to make use of SFDP needs to extend support for SFDP parameter reading.

I am reiterating that this is how SFDP parsing has been implemented in Linux as well and this is the generic way. Driver support is absolutely required because SPI framework cannot directly send any command to any flash.

Thanks
Rajat

> 
> Thanks,
> Stefan