[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 2:42 PM
> To: Siva Durga Prasad Paladugu
> Cc: Stefan Roese; u-boot at lists.denx.de; Hou Zhiqiang; York Sun
> Subject: Re: [U-Boot] [PATCH V6] sf: Turn SPI flash chip into 3-Byte address
> mode
>
> On 17 August 2015 at 14:26, Siva Durga Prasad Paladugu
> <siva.durga.paladugu at xilinx.com> wrote:
> > 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.
>
> Does a controller exist like that, means not supporting 4-byte addressing but
> may connect flash +16MiB?

Yes Jagan It's can exist. Zynq would be an example of one such case.

Regards,
DP
>
> > 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.
>
> thanks!
> --
> Jagan | openedev.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.