On 17 August 2015 at 14:26, Siva Durga Prasad Paladugu siva.durga.paladugu@xilinx.com wrote:
Hi Jagan,
-----Original Message----- From: Jagan Teki [mailto:jteki@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@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@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?
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!