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

[Jagan Teki]

On 17 August 2015 at 14:44, 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 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.

OK, I thought you may refer other than zynq-qspi yes I too knew this.

Let me back again for this.

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