[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: Thursday, August 13, 2015 5:16 PM
> To: Siva Durga Prasad Paladugu
> Cc: Stefan Roese; Hou Zhiqiang; u-boot at lists.denx.de; nofooter; York Sun
> Subject: Re: [U-Boot] [PATCH V6] sf: Turn SPI flash chip into 3-Byte address
> mode
>
> On 13 August 2015 at 16:57, Siva Durga Prasad Paladugu
> <siva.durga.paladugu at xilinx.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Stefan Roese [mailto:sr at denx.de]
> >> Sent: Thursday, August 13, 2015 4:51 PM
> >> To: Hou Zhiqiang; Siva Durga Prasad Paladugu; u-boot at lists.denx.de;
> >> jteki at openedev.com
> >> Cc: nofooter; York Sun
> >> Subject: Re: [U-Boot] [PATCH V6] sf: Turn SPI flash chip into 3-Byte
> >> address mode
> >>
> >> On 13.08.2015 12:50, Hou Zhiqiang wrote:
> >> >> -----Original Message-----
> >> >> From: Siva Durga Prasad Paladugu
> >> >> [mailto:siva.durga.paladugu at xilinx.com]
> >> >> Sent: 2015年8月13日 17:18
> >> >> To: Hou Zhiqiang-B48286; u-boot at lists.denx.de; jteki at openedev.com
> >> >> Cc: Sun York-R58495; Hu Mingkai-B21284; nofooter
> >> >> Subject: RE: [PATCH V6] sf: Turn SPI flash chip into 3-Byte
> >> >> address mode
> >> >>
> >> >> 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.

Regards,
Siva
>
> 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.