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