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

[Jagan Teki]

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?

thanks!
-- 
Jagan | openedev.