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. 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.
Regards, Siva > > thanks! > -- > Jagan | openedev. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot