On 17 August 2015 at 14:44, Siva Durga Prasad Paladugu <siva.durga.palad...@xilinx.com> wrote: > Hi Jagan, > >> -----Original Message----- >> From: Jagan Teki [mailto:jt...@openedev.com] >> Sent: Monday, August 17, 2015 2:42 PM >> To: Siva Durga Prasad Paladugu >> Cc: Stefan Roese; u-boot@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.palad...@xilinx.com> wrote: >> > Hi Jagan, >> > >> >> -----Original Message----- >> >> From: Jagan Teki [mailto:jt...@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.palad...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot