5 Replies Latest reply on Jan 29, 2019 11:14 PM by saozc_3963041

    S25FL128SAGBHI210 vs S25FL128SAGBHI200




      We have been using S25FL128SAGBHI200 for developing a Zynq application with Petalinux. So far we have not faced a considerable issue. However, due to it became out of stock, we've had to switch to S25FL128SAGBHI210 in our new designs. Actually the only difference we could see was their sector sizes (S25FL128SAGBHI200 has 64, S25FL128SAGBHI210 has 256KB sectors). Additionally, according to Xilinx's website, all of the S25FL.. family is supported.


      The problem we are facing with S25FL128SAGBHI210 is Petalinux cannot boot for a second time from the QSPI flash. We are programming the flash using Xilinx SDK and then we turn off the power of the board. After turning it on, Petalinux successfully boots from QSPI flash. If we perform a reboot of POR, nothings shows up and it needs to be programmed again. We have never had an issue like these with S25FL128SAGBHI200 before. All binaries are the same and nothing has changed except the QSPI chip model.


      What's more, we have booted the device on jtag mode and dumped the S25FL128SAGBHI210's contents. We compared it with the binary we are flashing and nothing was different. I mean, even if it cannot boot for a second time, the contents of it are the same and nothing gets corrupt after power off.


      We would became appreciate if you could help us.

        • 1. Re: S25FL128SAGBHI210 vs S25FL128SAGBHI200

          Hello Ahmet,


          Thank you for contacting Cypress Semiconductor.


          When the Petalinux board is completely turned off for the second time, does the Petalinux successfully boots from QSPI flash.,

          after the second power-up?


          In order to analyze and compare the S25FL128SAGBHI200 and S25FL128SAGBHI210 during Power-On RESET (POR),

          please provide the POR sequence waveform for both FLASH devices.  This issue may be related to either sensitivity to

          noise or a marginal timing issue.


          Just to make certain, please ensure a 0.1 uF decoupling capacity is placed between VCC and GND, but

          place one end of the capacitor as close to the VCC pin as possible.


          Cypress awaits for your response.



          Best regards,


          Cypress Semiconductor


          • 2. Re: S25FL128SAGBHI210 vs S25FL128SAGBHI200

            Hi Ahmet,


            At the second boot, the FSBL/u-boot cab run but Linux cannot, or nothing can run?

            Could you send boot log from u-boot/Linux at the first (successful) and second (if you have) boot?




            • 3. Re: S25FL128SAGBHI210 vs S25FL128SAGBHI200

              Hello all,


              Thank you for your answers. AlbertB_56, we are on a custom board and it's not that easy to get the waveforms (AFAIK). And no, petalinux only boots once. In further power on's; nothings shows up; neither u-boot nor petalinux (answer to @tkuw).


              However we've solved the issue. Once we looked up the internet for similar issues, we've seen:

              After trying out, we've seen that if we turn off the board during the u-boot stage, we could successfully turn it on again. So the problem was looking like the Linux side - in other words, the driver.


              In `drivers/mtd/spi-nor/spi-nor.c`, there are an array of supported QSPI flashes, with their JEDEC IDs. According to the boot message our new S25FL128SAGBHI210 was being detected as "s25fl129p0", however it should have been detected as "s25fl128s" as our old S25FL128SAGBHI200 used to be. Inspecting more, we have seen that the issue occurs due to wrong JEDEC ID read from S25FL128SAGBHI210's corresponding register. Yes, also it could be in driver wrong JEDEC ID was typed for "s25fl129p0", so eventhough our S25..210 was giving its identity true, it was being matched to "s25fl129p0". Anyway, opening up our S25..210 as s25fl129p0 was causing some sort of paging issue; maybe "extending" a register (as stated in AR# 57744) but not resetting it back. So it was successfully booting for the first time; but not more than one due to some corrupted registers (our opinion).


              But I don't think so: Both S25..200 and S25..210 are in the same family (s25fl128s), so they must give the same JEDEC ID, right?


              Anyway, making "s25fl129p0" looking like the "s25fl128s" in the spi-nor.c solves the issue for now. This is a hacky way, however we are planning to patch the driver in mainline kernel according to your answer. What's the JEDEC ID of S25..210? Is the driver code true? Is JEDEC ID stored in the registers of S25..210 true?


              { "s25fl128s",  INFO6(0x012018, 0x4d0180, 64 * 1024, 256, SECT_4K | SPI_NOR_QUAD_READ) },

              +++{ "s25fl128s210", INFO(0x012018, 0x4d00, 64 * 1024,  256,SPI_NOR_QUAD_READ) },

              +++//{ "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024,  64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },



              • 4. Re: S25FL128SAGBHI210 vs S25FL128SAGBHI200

                Hi Ahmet,


                Thanks for sending your status. I understood what's wrong in the spi-nor.c.

                The correct ID entries for FL128S(64KB) and FL128S(256KB) should be:


                { "s25fl128s0",  INFO6(0x012018, 0x4d0080, 256 * 1024, 64, SPI_NOR_QUAD_READ) },

                { "s25fl128s1",  INFO6(0x012018, 0x4d0180, 64 * 1024, 256, SPI_NOR_QUAD_READ) },


                Please try above.




                • 5. Re: S25FL128SAGBHI210 vs S25FL128SAGBHI200

                  Hello Takahiro,


                  Thanks for the answer; seems it's working. By the way, are you sure of the naming? I see you've typed s25fl128s0 for S25FL128SAGBHI210 and s25fl128s1 for S25FL128SAGBHI200; I guess you typed reverse.


                  I am planning to notify the driver developer to update his code.




                  Edit: I see in the code other chips also have the same naming style as you wrote. It looks reverse to me, anyway, this is just naming.