[U-Boot] [PATCH V6] sf: Turn SPI flash chip into 3-Byte address mode

[Siva Durga Prasad Paladugu]

Hi Jagan,

> -----Original Message-----
> From: Jagan Teki [mailto:jteki at openedev.com]
> Sent: Monday, August 17, 2015 1:43 PM
> To: Siva Durga Prasad Paladugu
> Cc: Hou Zhiqiang; Stefan Roese; nofooter; York Sun; u-boot at lists.denx.de
> Subject: Re: [U-Boot] [PATCH V6] sf: Turn SPI flash chip into 3-Byte address
> mode
> 
> Hi Siva,
> 
> On 13 August 2015 at 18:18, Siva Durga Prasad Paladugu
> <siva.durga.paladugu at xilinx.com> wrote:
> >> >> >> Hi Zhejiang/Jagan,
> >> >> >>
> >> >> >> I think it would be good to extend this further to support
> >> >> >> 4-byte addressing in u-boot also.
> >> >> >> This would be based on the driver, We can get the data that
> >> >> >> whether the controller supports 4-byte or not from the driver
> >> >> >> level(through slave
> >> >> >> struct) and enable 4 byte addressing here based on that.
> >> >> >>
> >> >> >
> >> >> > That is a long way, and I don't think it is necessary for U-Boot.
> >> >> > The U-Boot work well using BAR to address more than 16MiB flash.
> >> >> > This patch focus on the address mode issue when warm boot up
> >> >> > base on the BAR address mode.
> >> >>
> >> >> Please correct me if I'm wrong, but AFAIU this BAR thing
> >> >> (CONFIG_SPI_FLASH_BAR) doesn't support to address e.g. a 64MiB SPI
> >> >> flash contiguously. Only 16MiB areas. So for example its not
> >> >> possible to put UBI/UBIFS in such a big partition.
> >>
> >> Stefan,
> >>
> >> No, BAR is accessing flash > 16MiB in 3-byte addressing mode, for
> >> your example of 64MiB flash, it can grouped into 4 16MiB regions
> >> means 4 bank vales
> >> bank0 to bank3
> >>
> >> Based on the sf read/erase/write flash offsets, that particular bank
> >> will enable an do the relevant operations.
> >>
> >> In-spite of having 4 byte addressing operations BAR should do exactly
> >> same with existing 3-byte addressing.
> >>
> >> >>
> >> >> I have to support Siva here. We really should try to support this
> >> >> 4-byte mode correctly. This can't be too hard.
> >> >
> >> > Yeah, I think it wouldn't be too difficult to add support for 4-byte
> address.
> >> > we may just need to bypass the SPI_FLASH_BAR in read_ops ,
> >> > write_ops
> >> and erase_ops routines.
> >> >
> >> > This support need not be part of this series. It can be a separate
> >> > series. As we already added routine to disable /enable 4 byte as a
> >> > part of
> >> this, I just shared that it would be good to have 4 byte support also.
> >>
> >> Siva,
> >>
> >> Agree that adding 4-byte addressing is not too difficult, but by
> >> passing BAR is not a good idea, what if you have a flash with > 16
> >> MiB and controller have 3- byte addressing command support.
> >
> > Yes, if you look at my first mail on this, I mentioned, we should get
> > that info somehow from the driver of the respective controller, whether it
> supports four byte or not. For example from the spi_slave struct.
> > Here by-passing means that if controller supports four byte then only
> > we should bypass that BAR otherwise proceed with BAR.
> 
> So from your points, you need both BAR and 4-byte addressing need to have
> on sf, is that true? If yes some how controller will inform to sf which one can
> use?
Yes, we need both because some controllers won't support 4-byte addressing. 
This information we can get it from controller driver code or from device tree.
This would be same as slave->dual which we are getting now from driver code.

Regards,
Siva
> 
> thanks!
> --
> Jagan | openedev.