Hi Cyrille, On Tue, Oct 25, 2016 at 2:38 PM, Jagan Teki <[email protected]> wrote: > On Mon, Oct 24, 2016 at 7:37 PM, Cyrille Pitchen > <[email protected]> wrote: >> Le 24/10/2016 à 14:09, Cyrille Pitchen a écrit : >>> Hi Jagan, >>> >>> Le 24/10/2016 à 09:41, Jagan Teki a écrit : >>>> On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut <[email protected]> wrote: >>>>> On 10/22/2016 01:00 PM, Jagan Teki wrote: >>>>>> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen >>>>>> <[email protected]> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This series extends support of SPI protocols to new protocols such as >>>>>>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the >>>>>>> right >>>>>>> op codes, timing parameters (number of mode and dummy cycles) and erase >>>>>>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP) >>>>>>> tables, when available, as defined in the JEDEC JESD216 specifications. >>>>>>> >>>>>>> When SFDP tables are not available, legacy settings are still used for >>>>>>> backward compatibility (SPI and earlier QSPI memories). >>>>>>> >>>>>>> Support of SPI memories >128Mbits is also improved by using the 4byte >>>>>>> address instruction set, when available. Using those dedicated op codes >>>>>>> is stateless as opposed to enter the 4byte address mode, hence a better >>>>>>> compatibility with some boot loaders which expect to use 3byte address >>>>>>> op codes. >>>>>> >>>>>> The memories which are > 128Mbits should have 4-bytes addressing >>>>>> support based on my experience, do you think BAR is also required >>>>>> atleast from spi-nor side? >>>>> >>>>> Yes, I believe BAR is still required for broken/dumb flash chips. >>>>> Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-( >>>> >>>> Do you have list for those broken chips? because I never find any >>>> chips which has > 16 MiB with not support of 4-byte address opcodes >>>> and I've seen the controller has dependable with BAR though it can >>>> access > 16MiB ex: zynq qspi/ >>>> >>>> thanks! >>>> >>> >>> Let's take the case of Micron n25q256* memories. Depending of the part >>> number, >>> the 12h op code is associated with either 4-byte address Page Program 1-1-1 >>> or 3-byte address Page Program 1-4-4. >>> Then considering parts where the 12h op code is used for 3-byte address Page >>> Program 1-4-4, there is no op code for a 4-byte address Page Program 1-1-1. >>> >>> Note 15, extracted from the Micron n25q_256mb_3v_65nm.pdf datasheet, about >>> the 3-byte address Page Program 1-4-4 (Extended Quad Input Fast Program): >>> The code 38h is valid only for part numbers N25Q256A83ESF40x, >>> N25Q256A83E1240x >>> and N25Q256A83ESFA0F; the code 12h is valid for the other part numbers.
I am trying to understand the conflict more clearly with an example of Micron, so on Table 18 from Micron n25q_256mb_3v_65nm.pdf datasheet, Page program 3-byte has 02h and Quad page program 3-byte has 32h but for 4-byte addressing only quad page program (no support of page program) can be either 02h/32h/12h and indeed these can change based on the n25q256* parts so why can't we rely on Quad page program for 4-byte addressing? and so there is no necessity for BAR here. And also other than the un-supported-controller can't we rely directly on supported page program opcodes for 4-byte addressing? say if it is supporting QPP on 4-byte then use it as it is and no need to take care of PP here. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.
