RE: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Frieder, > -Original Message- > From: Schrempf Frieder > Sent: Wednesday, December 11, 2019 6:56 PM > To: Kuldeep Singh ; u-boot@lists.denx.de; > ja...@amarulasolutions.com > Cc: Priyanka Jain ; s...@denx.de; Ashish Kumar > ; Ye Li > Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > Hi Kuldeep, > > On 11.12.19 13:23, Kuldeep Singh wrote: > > Hi Frieder, > [...] > >>>>>>> Patch 2 adds new qspi driver incorporating spi-mem framework > >>>>>>> which is ported version of linux qspi driver. Initial port was done by > Frieder. > >>>>>>> Now, no more direct access to spi-nor memory is possible. Few > >>>>>>> changes were introduced to prevent uboot crash such as to add > >>>>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on > >>>>>>> chip select number instead of 1k. Immediate effect was observed > >>>>>>> on pfe while using 1k size as it access spi-nor memory directly. > >>>>>>> Using complete flash size resolves > >>>>>> the crash but data read will not be valid. > >>>>>> > >>>>>> Can you provide more information about the problem/crash you > >>>>>> experience and the platform you are working on? > >>>>> > >>>>> I observed crash on LS1012. Also, any access to flash direct > >>>>> memory above > >>>> 1k will crash without this change. > >>>> > >>>> As I already told Ashish in the conversation referenced in my last mail: > >>>> I can't see any good reason why the direct memory access is > >>>> something that we need or should support. We should always use the > >>>> APIs provided by U-Boot to access the flash and that is mtd. > >>>> > >>>>> By adding this, crash will be resolved but data is invalid as > >>>>> mentioned in > >>>> patch-set. > >>>> > >>>> So what's the purpose of your changes at all, if they do not solve > >>>> the problem you're trying to solve? > >>> > >>> I observed booting crash on all ls1012 platforms. Control does not > >>> reach > >> even end of uboot prompt. > >>> I dig in deeper, and found that "pfe (packet forwarding engine)" was > >>> using > >> spi-nor memory directly. > >>> With this change, booting crash was resolved. Now, at least other > >>> network > >> interfaces can be used. > >>> Without this changes, I have to disable pfe on adhoc basis so as to > >>> get uboot > >> prompt. > >>> This is to make sure all intended qspi targets are booting. > >> > >> Ok, thanks for pointing out the PFE driver. I didn't know about such > >> a peripheral. So this seems to be the actual problem here. > >> > >> I don't really understand, why Ashish didn't mention this when we > >> were talking about this issue some weeks ago. > >> > >>> > >>>> Why don't you just use sf/mtd to access the flash? > >>> > >>> Pfe framework have to bring in changes to access flash using sf in uboot. > >> > >> Yes and that's something that should be done first instead of hacking > >> the QSPI controller driver. It shouldn't be too hard to modify the > >> PFE driver so that it uses the serial flash API (spi_flash_read()) to > >> access the > SPI NOR. > >> Can you try to come up with a patch for the PFE driver? > > > > I have sent out PFE driver patch upstream[1] and booting crash is now > resolved. > > Ok, good. > > > > > Moreover, After using 1k size, I faced a random crash in environment which > was resolved after enabling SYS_RELOC_GD_ENV_ADDR in defconfig. > > I am not sure why this needed when setting 1k size? Note that, same is not > required if I use my previous implementation. > > SYS_RELOC_GD_ENV_ADDR was only introduced very recently and it seems > like it should be enabled for your boards (see [1]) when using something more > recent than 8d8ee47e03ef. > > My guess would be that you're missing the > "CONFIG_SYS_RELOC_GD_ENV_ADDR=y" because of some mistake while > rebasing or merging . I checked and found that Tom had made changes in all LS1012A variants except LS101
Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Kuldeep, On 11.12.19 13:23, Kuldeep Singh wrote: > Hi Frieder, [...] >>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>> is ported version of linux qspi driver. Initial port was done by >>> Frieder. >>> Now, no more direct access to spi-nor memory is possible. Few >>> changes were introduced to prevent uboot crash such as to add >>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on >>> chip select number instead of 1k. Immediate effect was observed on >>> pfe while using 1k size as it access spi-nor memory directly. >>> Using complete flash size resolves >> the crash but data read will not be valid. >> >> Can you provide more information about the problem/crash you >> experience and the platform you are working on? > > I observed crash on LS1012. Also, any access to flash direct memory > above 1k will crash without this change. As I already told Ashish in the conversation referenced in my last mail: I can't see any good reason why the direct memory access is something that we need or should support. We should always use the APIs provided by U-Boot to access the flash and that is mtd. > By adding this, crash will be resolved but data is invalid as > mentioned in patch-set. So what's the purpose of your changes at all, if they do not solve the problem you're trying to solve? >>> >>> I observed booting crash on all ls1012 platforms. Control does not reach >> even end of uboot prompt. >>> I dig in deeper, and found that "pfe (packet forwarding engine)" was using >> spi-nor memory directly. >>> With this change, booting crash was resolved. Now, at least other network >> interfaces can be used. >>> Without this changes, I have to disable pfe on adhoc basis so as to get >>> uboot >> prompt. >>> This is to make sure all intended qspi targets are booting. >> >> Ok, thanks for pointing out the PFE driver. I didn't know about such a >> peripheral. So this seems to be the actual problem here. >> >> I don't really understand, why Ashish didn't mention this when we were >> talking >> about this issue some weeks ago. >> >>> Why don't you just use sf/mtd to access the flash? >>> >>> Pfe framework have to bring in changes to access flash using sf in uboot. >> >> Yes and that's something that should be done first instead of hacking the >> QSPI >> controller driver. It shouldn't be too hard to modify the PFE driver so that >> it >> uses the serial flash API (spi_flash_read()) to access the SPI NOR. >> Can you try to come up with a patch for the PFE driver? > > I have sent out PFE driver patch upstream[1] and booting crash is now > resolved. Ok, good. > > Moreover, After using 1k size, I faced a random crash in environment which > was resolved after enabling SYS_RELOC_GD_ENV_ADDR in defconfig. > I am not sure why this needed when setting 1k size? Note that, same is not > required if I use my previous implementation. SYS_RELOC_GD_ENV_ADDR was only introduced very recently and it seems like it should be enabled for your boards (see [1]) when using something more recent than 8d8ee47e03ef. My guess would be that you're missing the "CONFIG_SYS_RELOC_GD_ENV_ADDR=y" because of some mistake while rebasing or merging . > > Now, I found a new bug while testing read functionality in LS1012A, LS1046A > on commit "4b19b89ca4a8". > I cannot access memory above 16MB. For example, when I try to access 16M, > data read is actually from 0x0 offset. > Could you please share your views on this behavior. This is usually a problem if the addressing mode for the SPI NOR is incorrect. When using 2-bytes addresses, only the first 16MiB of the flash can be accessed. For SPI NOR flashes with sizes bigger than 16MiB, 3-byte mode is mandatory to access areas above 16MiB. What's the manufacturer and type of the SPI flash you are using? Also please try to test on latest master with all the latest changes for MTD, etc. Thanks, Frieder [1] https://gitlab.denx.de/u-boot/u-boot/commit/8d8ee47e03ef23b0d0e842ea455a30bf0d2023b9 > > --Kuldeep >> >>> >>> Thanks >>> Kuldeep >>> > >> Are you referring to the same issue as Ashish in this discussion here >> [1]? > > Yes, I had a discussion with him. > >> There are two reasons why I'd like to avoid using the whole memory >> mapped area for AHB access. >> First, I'd like to keep the U-Boot driver as close as possible to >> the Linux driver. >> Second, the intention of the spi-mem layer is to abstract the flash >> layer and therefore this driver should work independently of flash >> type or size. > > Boot from QSPI-NAND will still not be possible. Code in bootROM is > only to access QSPI-NOR. It will not be possible to use SPI NAND directly from the BootROM, but you can just load the bootloader from a different device like
RE: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Frieder, > -Original Message- > From: Schrempf Frieder > Sent: Tuesday, December 3, 2019 6:17 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; ja...@amarulasolutions.com; > s...@denx.de; Ashish Kumar ; Ye Li > Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > On 03.12.19 11:56, Kuldeep Singh wrote: > > Hi Frieder, > > > >> -Original Message- > >> From: Schrempf Frieder > >> Sent: Tuesday, December 3, 2019 2:27 PM > >> To: Kuldeep Singh ; u-boot@lists.denx.de > >> Cc: Priyanka Jain ; > >> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >> ; Ye Li > >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >> spi-mem framework > >> > >> Caution: EXT Email > >> > >> On 03.12.19 07:30, Kuldeep Singh wrote: > >>> Hi Frieder, > >>> > >>>> -Original Message- > >>>> From: Schrempf Frieder > >>>> Sent: Monday, December 2, 2019 5:35 PM > >>>> To: Kuldeep Singh ; u-boot@lists.denx.de > >>>> Cc: Priyanka Jain ; > >>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >>>> > >>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >>>> spi-mem framework > >>>> > >>>> Caution: EXT Email > >>>> > >>>> + Ashish > >>>> > >>>> Hi Kuldeep, > >>>> > >>>> On 29.11.19 06:54, Kuldeep Singh wrote: > >>>>> This entire patch series migrate freescale qspi driver to spi-mem > >> framework. > >>>> > >>>> First, thanks for working on this. I have this on my list for quite > >>>> a long time, but struggled to find enough time to actually get it done. > >>>> > >>>>> > >>>>> Patch 1 removes the old fsl qspi driver > >>>> > >>>> You shouldn't remove the old driver before the new one is in place, > >>>> as this breaks the build in between the two patches. > >>> > >>> I first merged the patch1 and patch2 and found that the diff output > >>> was very > >> much less readable. > >>> That's why I split them into 2 patches so as to make new driver > >>> changes > >> legible. > >>> Please let me know how shall I proceed. Shall I merge the two patches? > >> > >> Yes, the merged patch will not be very good to read, but as far as I > >> know there is no other option. We must not break the build to keep > bisectability. > > > > Alright I will merge the two patches. > > > >> > >>> > >>>> > >>>>> > >>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which > >>>>> is ported version of linux qspi driver. Initial port was done by > >>>>> Frieder. > >>>>> Now, no more direct access to spi-nor memory is possible. Few > >>>>> changes were introduced to prevent uboot crash such as to add > >>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on > >>>>> chip select number instead of 1k. Immediate effect was observed on > >>>>> pfe while using 1k size as it access spi-nor memory directly. > >>>>> Using complete flash size resolves > >>>> the crash but data read will not be valid. > >>>> > >>>> Can you provide more information about the problem/crash you > >>>> experience and the platform you are working on? > >>> > >>> I observed crash on LS1012. Also, any access to flash direct memory > >>> above > >> 1k will crash without this change. > >> > >> As I already told Ashish in the conversation referenced in my last mail: > >> I can't see any good reason why the direct memory access is something > >> that we need or should support. We should always use the APIs > >> provided by U-Boot to access the flash and that is mtd. > >> > >>> By adding this, crash will be resolved but data is invalid as > >>> mentioned in > >> patch-set. > >> > >> So what's the purpose of your changes at all, if they do not solve > >> the problem you're trying to solve? > > > > I observed booting crash
RE: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
> -Original Message- > From: Schrempf Frieder > Sent: Tuesday, December 3, 2019 6:17 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; ja...@amarulasolutions.com; > s...@denx.de; Ashish Kumar ; Ye Li > Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > On 03.12.19 11:56, Kuldeep Singh wrote: > > Hi Frieder, > > > >> -Original Message- > >> From: Schrempf Frieder > >> Sent: Tuesday, December 3, 2019 2:27 PM > >> To: Kuldeep Singh ; u-boot@lists.denx.de > >> Cc: Priyanka Jain ; > >> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >> ; Ye Li > >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >> spi-mem framework > >> > >> Caution: EXT Email > >> > >> On 03.12.19 07:30, Kuldeep Singh wrote: > >>> Hi Frieder, > >>> > >>>> -Original Message- > >>>> From: Schrempf Frieder > >>>> Sent: Monday, December 2, 2019 5:35 PM > >>>> To: Kuldeep Singh ; u-boot@lists.denx.de > >>>> Cc: Priyanka Jain ; > >>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >>>> > >>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >>>> spi-mem framework > >>>> > >>>> Caution: EXT Email > >>>> > >>>> + Ashish > >>>> > >>>> Hi Kuldeep, > >>>> > >>>> On 29.11.19 06:54, Kuldeep Singh wrote: > >>>>> This entire patch series migrate freescale qspi driver to spi-mem > >> framework. > >>>> > >>>> First, thanks for working on this. I have this on my list for quite > >>>> a long time, but struggled to find enough time to actually get it done. > >>>> > >>>>> > >>>>> Patch 1 removes the old fsl qspi driver > >>>> > >>>> You shouldn't remove the old driver before the new one is in place, > >>>> as this breaks the build in between the two patches. > >>> > >>> I first merged the patch1 and patch2 and found that the diff output > >>> was very > >> much less readable. > >>> That's why I split them into 2 patches so as to make new driver > >>> changes > >> legible. > >>> Please let me know how shall I proceed. Shall I merge the two patches? > >> > >> Yes, the merged patch will not be very good to read, but as far as I > >> know there is no other option. We must not break the build to keep > bisectability. > > > > Alright I will merge the two patches. > > > >> > >>> > >>>> > >>>>> > >>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which > >>>>> is ported version of linux qspi driver. Initial port was done by > >>>>> Frieder. > >>>>> Now, no more direct access to spi-nor memory is possible. Few > >>>>> changes were introduced to prevent uboot crash such as to add > >>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on > >>>>> chip select number instead of 1k. Immediate effect was observed on > >>>>> pfe while using 1k size as it access spi-nor memory directly. > >>>>> Using complete flash size resolves > >>>> the crash but data read will not be valid. > >>>> > >>>> Can you provide more information about the problem/crash you > >>>> experience and the platform you are working on? > >>> > >>> I observed crash on LS1012. Also, any access to flash direct memory > >>> above > >> 1k will crash without this change. > >> > >> As I already told Ashish in the conversation referenced in my last mail: > >> I can't see any good reason why the direct memory access is something > >> that we need or should support. We should always use the APIs > >> provided by U-Boot to access the flash and that is mtd. > >> > >>> By adding this, crash will be resolved but data is invalid as > >>> mentioned in > >> patch-set. > >> > >> So what's the purpose of your changes at all, if they do not solve > >> the problem you're trying to solve? > > > > I observed booting cr
Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
On 03.12.19 11:56, Kuldeep Singh wrote: > Hi Frieder, > >> -Original Message- >> From: Schrempf Frieder >> Sent: Tuesday, December 3, 2019 2:27 PM >> To: Kuldeep Singh ; u-boot@lists.denx.de >> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >> s...@denx.de; Ashish Kumar ; Ye Li >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> On 03.12.19 07:30, Kuldeep Singh wrote: >>> Hi Frieder, >>> >>>> -Original Message- >>>> From: Schrempf Frieder >>>> Sent: Monday, December 2, 2019 5:35 PM >>>> To: Kuldeep Singh ; u-boot@lists.denx.de >>>> Cc: Priyanka Jain ; >>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar >>>> >>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>>> spi-mem framework >>>> >>>> Caution: EXT Email >>>> >>>> + Ashish >>>> >>>> Hi Kuldeep, >>>> >>>> On 29.11.19 06:54, Kuldeep Singh wrote: >>>>> This entire patch series migrate freescale qspi driver to spi-mem >> framework. >>>> >>>> First, thanks for working on this. I have this on my list for quite a >>>> long time, but struggled to find enough time to actually get it done. >>>> >>>>> >>>>> Patch 1 removes the old fsl qspi driver >>>> >>>> You shouldn't remove the old driver before the new one is in place, >>>> as this breaks the build in between the two patches. >>> >>> I first merged the patch1 and patch2 and found that the diff output was very >> much less readable. >>> That's why I split them into 2 patches so as to make new driver changes >> legible. >>> Please let me know how shall I proceed. Shall I merge the two patches? >> >> Yes, the merged patch will not be very good to read, but as far as I know >> there >> is no other option. We must not break the build to keep bisectability. > > Alright I will merge the two patches. > >> >>> >>>> >>>>> >>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>>>> is ported version of linux qspi driver. Initial port was done by Frieder. >>>>> Now, no more direct access to spi-nor memory is possible. Few >>>>> changes were introduced to prevent uboot crash such as to add >>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip >>>>> select number instead of 1k. Immediate effect was observed on pfe >>>>> while using 1k size as it access spi-nor memory directly. Using >>>>> complete flash size resolves >>>> the crash but data read will not be valid. >>>> >>>> Can you provide more information about the problem/crash you >>>> experience and the platform you are working on? >>> >>> I observed crash on LS1012. Also, any access to flash direct memory above >> 1k will crash without this change. >> >> As I already told Ashish in the conversation referenced in my last mail: >> I can't see any good reason why the direct memory access is something that >> we need or should support. We should always use the APIs provided by U-Boot >> to access the flash and that is mtd. >> >>> By adding this, crash will be resolved but data is invalid as mentioned in >> patch-set. >> >> So what's the purpose of your changes at all, if they do not solve the >> problem >> you're trying to solve? > > I observed booting crash on all ls1012 platforms. Control does not reach even > end of uboot prompt. > I dig in deeper, and found that "pfe (packet forwarding engine)" was using > spi-nor memory directly. > With this change, booting crash was resolved. Now, at least other network > interfaces can be used. > Without this changes, I have to disable pfe on adhoc basis so as to get uboot > prompt. > This is to make sure all intended qspi targets are booting. Ok, thanks for pointing out the PFE driver. I didn't know about such a peripheral. So this seems to be the actual problem here. I don't really understand, why Ashish didn't mention this when we were talking about this issue some weeks ago. > >> Why don't you just use sf/mtd to access the flash? > > Pfe framework have to bring in changes to access flash using sf in uboot. Yes and that's something that should
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Frieder, > -Original Message- > From: Schrempf Frieder > Sent: Tuesday, December 3, 2019 2:27 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; ja...@amarulasolutions.com; > s...@denx.de; Ashish Kumar ; Ye Li > Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > On 03.12.19 07:30, Kuldeep Singh wrote: > > Hi Frieder, > > > >> -Original Message- > >> From: Schrempf Frieder > >> Sent: Monday, December 2, 2019 5:35 PM > >> To: Kuldeep Singh ; u-boot@lists.denx.de > >> Cc: Priyanka Jain ; > >> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >> > >> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >> spi-mem framework > >> > >> Caution: EXT Email > >> > >> + Ashish > >> > >> Hi Kuldeep, > >> > >> On 29.11.19 06:54, Kuldeep Singh wrote: > >>> This entire patch series migrate freescale qspi driver to spi-mem > framework. > >> > >> First, thanks for working on this. I have this on my list for quite a > >> long time, but struggled to find enough time to actually get it done. > >> > >>> > >>> Patch 1 removes the old fsl qspi driver > >> > >> You shouldn't remove the old driver before the new one is in place, > >> as this breaks the build in between the two patches. > > > > I first merged the patch1 and patch2 and found that the diff output was very > much less readable. > > That's why I split them into 2 patches so as to make new driver changes > legible. > > Please let me know how shall I proceed. Shall I merge the two patches? > > Yes, the merged patch will not be very good to read, but as far as I know > there > is no other option. We must not break the build to keep bisectability. Alright I will merge the two patches. > > > > >> > >>> > >>> Patch 2 adds new qspi driver incorporating spi-mem framework which > >>> is ported version of linux qspi driver. Initial port was done by Frieder. > >>> Now, no more direct access to spi-nor memory is possible. Few > >>> changes were introduced to prevent uboot crash such as to add > >>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip > >>> select number instead of 1k. Immediate effect was observed on pfe > >>> while using 1k size as it access spi-nor memory directly. Using > >>> complete flash size resolves > >> the crash but data read will not be valid. > >> > >> Can you provide more information about the problem/crash you > >> experience and the platform you are working on? > > > > I observed crash on LS1012. Also, any access to flash direct memory above > 1k will crash without this change. > > As I already told Ashish in the conversation referenced in my last mail: > I can't see any good reason why the direct memory access is something that > we need or should support. We should always use the APIs provided by U-Boot > to access the flash and that is mtd. > > > By adding this, crash will be resolved but data is invalid as mentioned in > patch-set. > > So what's the purpose of your changes at all, if they do not solve the problem > you're trying to solve? I observed booting crash on all ls1012 platforms. Control does not reach even end of uboot prompt. I dig in deeper, and found that "pfe (packet forwarding engine)" was using spi-nor memory directly. With this change, booting crash was resolved. Now, at least other network interfaces can be used. Without this changes, I have to disable pfe on adhoc basis so as to get uboot prompt. This is to make sure all intended qspi targets are booting. > Why don't you just use sf/mtd to access the flash? Pfe framework have to bring in changes to access flash using sf in uboot. Thanks Kuldeep > > > > >> Are you referring to the same issue as Ashish in this discussion here [1]? > > > > Yes, I had a discussion with him. > > > >> There are two reasons why I'd like to avoid using the whole memory > >> mapped area for AHB access. > >> First, I'd like to keep the U-Boot driver as close as possible to the Linux > driver. > >> Second, the intention of the spi-mem layer is to abstract the flash > >> layer and therefore this driver should work independently of flash type or > size. > > > > Boot from QSPI-NAND will still not be possible. Code in bootROM is only to > access QSPI-N
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Ashish, On 03.12.19 10:44, Frieder Schrempf wrote: > On 03.12.19 10:33, Ashish Kumar wrote: >> Hi Frieder, >> >>> -Original Message- >>> From: Schrempf Frieder >>> Sent: Tuesday, December 3, 2019 2:27 PM >>> To: Kuldeep Singh ; u-boot@lists.denx.de >>> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >>> s...@denx.de; Ashish Kumar ; Ye Li >>> >>> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>> spi-mem >>> framework >>> >>> Caution: EXT Email >>> >>> On 03.12.19 07:30, Kuldeep Singh wrote: >>>> Hi Frieder, >>>> >>>>> -Original Message- >>>>> From: Schrempf Frieder >>>>> Sent: Monday, December 2, 2019 5:35 PM >>>>> To: Kuldeep Singh ; u-boot@lists.denx.de >>>>> Cc: Priyanka Jain ; >>>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar >>>>> >>>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>>>> spi-mem framework >>>>> >>>>> Caution: EXT Email >>>>> >>>>> + Ashish >>>>> >>>>> Hi Kuldeep, >>>>> >>>>> On 29.11.19 06:54, Kuldeep Singh wrote: >>>>>> This entire patch series migrate freescale qspi driver to spi-mem >>> framework. >>>>> >>>>> First, thanks for working on this. I have this on my list for quite a >>>>> long time, but struggled to find enough time to actually get it done. >>>>> >>>>>> >>>>>> Patch 1 removes the old fsl qspi driver >>>>> >>>>> You shouldn't remove the old driver before the new one is in place, >>>>> as this breaks the build in between the two patches. >>>> >>>> I first merged the patch1 and patch2 and found that the diff output was >>> very much less readable. >>>> That's why I split them into 2 patches so as to make new driver changes >>> legible. >>>> Please let me know how shall I proceed. Shall I merge the two patches? >>> >>> Yes, the merged patch will not be very good to read, but as far as I >>> know >>> there is no other option. We must not break the build to keep >>> bisectability. >>> >>>> >>>>> >>>>>> >>>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>>>>> is ported version of linux qspi driver. Initial port was done by >>>>>> Frieder. >>>>>> Now, no more direct access to spi-nor memory is possible. Few >>>>>> changes were introduced to prevent uboot crash such as to add >>>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip >>>>>> select number instead of 1k. Immediate effect was observed on pfe >>>>>> while using 1k size as it access spi-nor memory directly. Using >>>>>> complete flash size resolves >>>>> the crash but data read will not be valid. >>>>> >>>>> Can you provide more information about the problem/crash you >>>>> experience and the platform you are working on? >>>> >>>> I observed crash on LS1012. Also, any access to flash direct memory >>>> above >>> 1k will crash without this change. >>> >>> As I already told Ashish in the conversation referenced in my last mail: >>> I can't see any good reason why the direct memory access is something >>> that >>> we need or should support. We should always use the APIs provided by U- >>> Boot to access the flash and that is mtd. >>> >>>> By adding this, crash will be resolved but data is invalid as >>>> mentioned in >>> patch-set. >>> >>> So what's the purpose of your changes at all, if they do not solve >>> the problem >>> you're trying to solve? >>> Why don't you just use sf/mtd to access the flash? >>> >>>> >>>>> Are you referring to the same issue as Ashish in this discussion >>>>> here [1]? >>>> >>>> Yes, I had a discussion with him. >>>> >>>>> There are two reasons why I'd like to avoid using the whole memory >>>>> mapped area for AHB access. >>>>> First, I'd like to keep the
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
On 03.12.19 10:33, Ashish Kumar wrote: > Hi Frieder, > >> -Original Message- >> From: Schrempf Frieder >> Sent: Tuesday, December 3, 2019 2:27 PM >> To: Kuldeep Singh ; u-boot@lists.denx.de >> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >> s...@denx.de; Ashish Kumar ; Ye Li >> >> Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> On 03.12.19 07:30, Kuldeep Singh wrote: >>> Hi Frieder, >>> >>>> -Original Message- >>>> From: Schrempf Frieder >>>> Sent: Monday, December 2, 2019 5:35 PM >>>> To: Kuldeep Singh ; u-boot@lists.denx.de >>>> Cc: Priyanka Jain ; >>>> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar >>>> >>>> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to >>>> spi-mem framework >>>> >>>> Caution: EXT Email >>>> >>>> + Ashish >>>> >>>> Hi Kuldeep, >>>> >>>> On 29.11.19 06:54, Kuldeep Singh wrote: >>>>> This entire patch series migrate freescale qspi driver to spi-mem >> framework. >>>> >>>> First, thanks for working on this. I have this on my list for quite a >>>> long time, but struggled to find enough time to actually get it done. >>>> >>>>> >>>>> Patch 1 removes the old fsl qspi driver >>>> >>>> You shouldn't remove the old driver before the new one is in place, >>>> as this breaks the build in between the two patches. >>> >>> I first merged the patch1 and patch2 and found that the diff output was >> very much less readable. >>> That's why I split them into 2 patches so as to make new driver changes >> legible. >>> Please let me know how shall I proceed. Shall I merge the two patches? >> >> Yes, the merged patch will not be very good to read, but as far as I know >> there is no other option. We must not break the build to keep bisectability. >> >>> >>>> >>>>> >>>>> Patch 2 adds new qspi driver incorporating spi-mem framework which >>>>> is ported version of linux qspi driver. Initial port was done by Frieder. >>>>> Now, no more direct access to spi-nor memory is possible. Few >>>>> changes were introduced to prevent uboot crash such as to add >>>>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip >>>>> select number instead of 1k. Immediate effect was observed on pfe >>>>> while using 1k size as it access spi-nor memory directly. Using >>>>> complete flash size resolves >>>> the crash but data read will not be valid. >>>> >>>> Can you provide more information about the problem/crash you >>>> experience and the platform you are working on? >>> >>> I observed crash on LS1012. Also, any access to flash direct memory above >> 1k will crash without this change. >> >> As I already told Ashish in the conversation referenced in my last mail: >> I can't see any good reason why the direct memory access is something that >> we need or should support. We should always use the APIs provided by U- >> Boot to access the flash and that is mtd. >> >>> By adding this, crash will be resolved but data is invalid as mentioned in >> patch-set. >> >> So what's the purpose of your changes at all, if they do not solve the >> problem >> you're trying to solve? >> Why don't you just use sf/mtd to access the flash? >> >>> >>>> Are you referring to the same issue as Ashish in this discussion here [1]? >>> >>> Yes, I had a discussion with him. >>> >>>> There are two reasons why I'd like to avoid using the whole memory >>>> mapped area for AHB access. >>>> First, I'd like to keep the U-Boot driver as close as possible to the Linux >> driver. >>>> Second, the intention of the spi-mem layer is to abstract the flash >>>> layer and therefore this driver should work independently of flash type or >> size. >>> >>> Boot from QSPI-NAND will still not be possible. Code in bootROM is only to >> access QSPI-NOR. >> >> It will not be possible to use SPI NAND directly from the BootROM, but you >> can just load the bootloader from a different device like SPI NOR and then >> fetch the r
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Frieder, > -Original Message- > From: Schrempf Frieder > Sent: Tuesday, December 3, 2019 2:27 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; ja...@amarulasolutions.com; > s...@denx.de; Ashish Kumar ; Ye Li > > Subject: Re: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > On 03.12.19 07:30, Kuldeep Singh wrote: > > Hi Frieder, > > > >> -Original Message- > >> From: Schrempf Frieder > >> Sent: Monday, December 2, 2019 5:35 PM > >> To: Kuldeep Singh ; u-boot@lists.denx.de > >> Cc: Priyanka Jain ; > >> ja...@amarulasolutions.com; s...@denx.de; Ashish Kumar > >> > >> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to > >> spi-mem framework > >> > >> Caution: EXT Email > >> > >> + Ashish > >> > >> Hi Kuldeep, > >> > >> On 29.11.19 06:54, Kuldeep Singh wrote: > >>> This entire patch series migrate freescale qspi driver to spi-mem > framework. > >> > >> First, thanks for working on this. I have this on my list for quite a > >> long time, but struggled to find enough time to actually get it done. > >> > >>> > >>> Patch 1 removes the old fsl qspi driver > >> > >> You shouldn't remove the old driver before the new one is in place, > >> as this breaks the build in between the two patches. > > > > I first merged the patch1 and patch2 and found that the diff output was > very much less readable. > > That's why I split them into 2 patches so as to make new driver changes > legible. > > Please let me know how shall I proceed. Shall I merge the two patches? > > Yes, the merged patch will not be very good to read, but as far as I know > there is no other option. We must not break the build to keep bisectability. > > > > >> > >>> > >>> Patch 2 adds new qspi driver incorporating spi-mem framework which > >>> is ported version of linux qspi driver. Initial port was done by Frieder. > >>> Now, no more direct access to spi-nor memory is possible. Few > >>> changes were introduced to prevent uboot crash such as to add > >>> complete flash size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip > >>> select number instead of 1k. Immediate effect was observed on pfe > >>> while using 1k size as it access spi-nor memory directly. Using > >>> complete flash size resolves > >> the crash but data read will not be valid. > >> > >> Can you provide more information about the problem/crash you > >> experience and the platform you are working on? > > > > I observed crash on LS1012. Also, any access to flash direct memory above > 1k will crash without this change. > > As I already told Ashish in the conversation referenced in my last mail: > I can't see any good reason why the direct memory access is something that > we need or should support. We should always use the APIs provided by U- > Boot to access the flash and that is mtd. > > > By adding this, crash will be resolved but data is invalid as mentioned in > patch-set. > > So what's the purpose of your changes at all, if they do not solve the problem > you're trying to solve? > Why don't you just use sf/mtd to access the flash? > > > > >> Are you referring to the same issue as Ashish in this discussion here [1]? > > > > Yes, I had a discussion with him. > > > >> There are two reasons why I'd like to avoid using the whole memory > >> mapped area for AHB access. > >> First, I'd like to keep the U-Boot driver as close as possible to the Linux > driver. > >> Second, the intention of the spi-mem layer is to abstract the flash > >> layer and therefore this driver should work independently of flash type or > size. > > > > Boot from QSPI-NAND will still not be possible. Code in bootROM is only to > access QSPI-NOR. > > It will not be possible to use SPI NAND directly from the BootROM, but you > can just load the bootloader from a different device like SPI NOR and then > fetch the rest of the system (Kernel, rootfs, etc.) from a SPI NAND device. > Actually that's exactly the use case, that led to the development of the SPI > MEM layer and the migration of the QSPI driver. Is setting SFA1AD, SFA2AD, SFB1AD, SFB2AD to flash size, QSPI-NAND access is broken? I cannot check this since our board does not have such configuration. If yes, then it should be reverted. oth
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
On 03.12.19 07:30, Kuldeep Singh wrote: > Hi Frieder, > >> -Original Message- >> From: Schrempf Frieder >> Sent: Monday, December 2, 2019 5:35 PM >> To: Kuldeep Singh ; u-boot@lists.denx.de >> Cc: Priyanka Jain ; ja...@amarulasolutions.com; >> s...@denx.de; Ashish Kumar >> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem >> framework >> >> Caution: EXT Email >> >> + Ashish >> >> Hi Kuldeep, >> >> On 29.11.19 06:54, Kuldeep Singh wrote: >>> This entire patch series migrate freescale qspi driver to spi-mem framework. >> >> First, thanks for working on this. I have this on my list for quite a long >> time, but >> struggled to find enough time to actually get it done. >> >>> >>> Patch 1 removes the old fsl qspi driver >> >> You shouldn't remove the old driver before the new one is in place, as this >> breaks the build in between the two patches. > > I first merged the patch1 and patch2 and found that the diff output was very > much less readable. > That's why I split them into 2 patches so as to make new driver changes > legible. > Please let me know how shall I proceed. Shall I merge the two patches? Yes, the merged patch will not be very good to read, but as far as I know there is no other option. We must not break the build to keep bisectability. > >> >>> >>> Patch 2 adds new qspi driver incorporating spi-mem framework which is >>> ported version of linux qspi driver. Initial port was done by Frieder. >>> Now, no more direct access to spi-nor memory is possible. Few changes >>> were introduced to prevent uboot crash such as to add complete flash >>> size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number >>> instead of 1k. Immediate effect was observed on pfe while using 1k >>> size as it access spi-nor memory directly. Using complete flash size >>> resolves >> the crash but data read will not be valid. >> >> Can you provide more information about the problem/crash you experience >> and the platform you are working on? > > I observed crash on LS1012. Also, any access to flash direct memory above 1k > will crash without this change. As I already told Ashish in the conversation referenced in my last mail: I can't see any good reason why the direct memory access is something that we need or should support. We should always use the APIs provided by U-Boot to access the flash and that is mtd. > By adding this, crash will be resolved but data is invalid as mentioned in > patch-set. So what's the purpose of your changes at all, if they do not solve the problem you're trying to solve? Why don't you just use sf/mtd to access the flash? > >> Are you referring to the same issue as Ashish in this discussion here [1]? > > Yes, I had a discussion with him. > >> There are two reasons why I'd like to avoid using the whole memory mapped >> area for AHB access. >> First, I'd like to keep the U-Boot driver as close as possible to the Linux >> driver. >> Second, the intention of the spi-mem layer is to abstract the flash layer and >> therefore this driver should work independently of flash type or size. > > Boot from QSPI-NAND will still not be possible. Code in bootROM is only to > access QSPI-NOR. It will not be possible to use SPI NAND directly from the BootROM, but you can just load the bootloader from a different device like SPI NOR and then fetch the rest of the system (Kernel, rootfs, etc.) from a SPI NAND device. Actually that's exactly the use case, that led to the development of the SPI MEM layer and the migration of the QSPI driver. > >> With your version this wouldn't be the case if you connect a flash that is >> bigger than the >> memory map for example. > > I agree such use case can be valid for Linux but in case of Uboot, I believe > access to flash size greater than 256M will not be required. > If in case there is a requirement, there is another region in CCSR space to > map flash memories up to 4G. > Random crashes can be avoided by adding these changes. Please let us know > your views as well. We don't even need to consider these cases, if we would just stick to the SPI MEM API and use it as intended. Apart from some possible performance penalty (that shouldn't matter too much and could be resolved by implementing the direct mapping API as in Linux), I can't see the reason for not doing so. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
Hi Frieder, > -Original Message- > From: Schrempf Frieder > Sent: Monday, December 2, 2019 5:35 PM > To: Kuldeep Singh ; u-boot@lists.denx.de > Cc: Priyanka Jain ; ja...@amarulasolutions.com; > s...@denx.de; Ashish Kumar > Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem > framework > > Caution: EXT Email > > + Ashish > > Hi Kuldeep, > > On 29.11.19 06:54, Kuldeep Singh wrote: > > This entire patch series migrate freescale qspi driver to spi-mem framework. > > First, thanks for working on this. I have this on my list for quite a long > time, but > struggled to find enough time to actually get it done. > > > > > Patch 1 removes the old fsl qspi driver > > You shouldn't remove the old driver before the new one is in place, as this > breaks the build in between the two patches. I first merged the patch1 and patch2 and found that the diff output was very much less readable. That's why I split them into 2 patches so as to make new driver changes legible. Please let me know how shall I proceed. Shall I merge the two patches? > > > > > Patch 2 adds new qspi driver incorporating spi-mem framework which is > > ported version of linux qspi driver. Initial port was done by Frieder. > > Now, no more direct access to spi-nor memory is possible. Few changes > > were introduced to prevent uboot crash such as to add complete flash > > size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number > > instead of 1k. Immediate effect was observed on pfe while using 1k > > size as it access spi-nor memory directly. Using complete flash size > > resolves > the crash but data read will not be valid. > > Can you provide more information about the problem/crash you experience > and the platform you are working on? I observed crash on LS1012. Also, any access to flash direct memory above 1k will crash without this change. By adding this, crash will be resolved but data is invalid as mentioned in patch-set. > Are you referring to the same issue as Ashish in this discussion here [1]? Yes, I had a discussion with him. > There are two reasons why I'd like to avoid using the whole memory mapped > area for AHB access. > First, I'd like to keep the U-Boot driver as close as possible to the Linux > driver. > Second, the intention of the spi-mem layer is to abstract the flash layer and > therefore this driver should work independently of flash type or size. Boot from QSPI-NAND will still not be possible. Code in bootROM is only to access QSPI-NOR. >With your version this wouldn't be the case if you connect a flash that is >bigger than the > memory map for example. I agree such use case can be valid for Linux but in case of Uboot, I believe access to flash size greater than 256M will not be required. If in case there is a requirement, there is another region in CCSR space to map flash memories up to 4G. Random crashes can be avoided by adding these changes. Please let us know your views as well. Thanks Kuldeep > Thanks, > Frieder > > [1]: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx > .de%2Fpipermail%2Fu-boot%2F2019- > October%2F387788.html&data=02%7C01%7Ckuldeep.singh%40nxp.com% > 7C5f25f29d1a2d4971c62a08d7771feb4c%7C686ea1d3bc2b4c6fa92cd99c5c30 > 1635%7C0%7C0%7C637108851370551242&sdata=OKjdpsL4BbALL3TIGh7 > EuJaVV0xC5%2FH8%2BIXoTnIowGQ%3D&reserved=0 > > > > > Patch 3 removes unused config options. > > > > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header > files. > > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR. > > > > Patch 5 removes unused num-cs property for imx platforms > > > > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is > > no longer required and can be removed. > > > > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files. > > While enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at > the same time. > > > > Patch 8 updates the device-tree properties treewide for layerscape > > boards by aligning it with linux device-tree properties. > > > > Frieder Schrempf (1): > >imx: imx6sx: Remove unused 'num-cs' property > > > > Kuldeep Singh (7): > >spi: Remove old freescale qspi driver > >spi: Transform the FSL QuadSPI driver to use the SPI MEM API > >treewide: Remove unused FSL QSPI config options > >configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig > >configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig > >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig > >
Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework
+ Ye li
Hi Stefan,
> -Original Message-
> From: Stefan Roese
> Sent: Monday, December 2, 2019 3:38 PM
> To: Kuldeep Singh ; u-boot@lists.denx.de
> Cc: Priyanka Jain ; ja...@amarulasolutions.com;
> frieder.schre...@kontron.de
> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem
> framework
>
> Caution: EXT Email
>
> Hi Kuldeep,
>
> On 29.11.19 06:54, Kuldeep Singh wrote:
> > This entire patch series migrate freescale qspi driver to spi-mem
> framework.
> >
> > Patch 1 removes the old fsl qspi driver
> >
> > Patch 2 adds new qspi driver incorporating spi-mem framework which is
> > ported version of linux qspi driver. Initial port was done by Frieder.
> > Now, no more direct access to spi-nor memory is possible. Few changes
> > were introduced to prevent uboot crash such as to add complete flash
> > size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number
> > instead of 1k. Immediate effect was observed on pfe while using 1k
> > size as it access spi-nor memory directly. Using complete flash size
> resolves the crash but data read will not be valid.
> >
> > Patch 3 removes unused config options.
> >
> > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header
> files.
> > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR.
> >
> > Patch 5 removes unused num-cs property for imx platforms
> >
> > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR
> is
> > no longer required and can be removed.
> >
> > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files.
> > While enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR
> at the same time.
> >
> > Patch 8 updates the device-tree properties treewide for layerscape
> > boards by aligning it with linux device-tree properties.
>
> Many thanks for working on this. I've tested this patchset on a new i-
> MX6ULL/ULZ based board and noticed, that I still need to add this kind of
> patch to make it work on my platform:
>
> drivers/spi/fsl_qspi.c
> index
> 788fa0416f..0946f9d6d5 100644 @@ -44,6 +44,9 @@
> DECLARE_GLOBAL_DATA_PTR;
> #define QUADSPI_IPCR 0x08
> #define QUADSPI_IPCR_SEQID(x) ((x) << 24)
>
> +#define QUADSPI_FLSHCR 0x0c
> +#define QUADSPI_FLSHCR_TDH(x) ((x) << 16)
> +
> #define QUADSPI_BUF3CR0x1c
> #define QUADSPI_BUF3CR_ALLMST_MASKBIT(31)
> #define QUADSPI_BUF3CR_ADATSZ(x) ((x) << 8)
> @@ -666,6 +669,16 @@ static int fsl_qspi_default_setup(struct fsl_qspi *q)
> QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
> base + QUADSPI_BUF3CR);
>
> + /*
> +* Clear THD bits to configure SDR mode instead of DDR mode. This
> +* might be necessary, as the BootROM in some versions and on some
> +* SoCs sets these bits to 0x1 for DDR mode. But this driver needs
> +* it set to SDR mode instead.
> +*/
> + reg = qspi_readl(q, base + QUADSPI_FLSHCR);
> + reg &= ~QUADSPI_FLSHCR_TDH(0x3);
> + qspi_writel(q, reg, base + QUADSPI_FLSHCR);
>
> This was suggested by Frieder and is also integrated in the Linux QSPI driver:
>
> Commit ID f6910679e17a ("spi: spi-fsl-qspi: Clear TDH bits in FLSHCR
> register")
>
> What is the status of SDR vs DDR mode in this driver? Is this driver version
> supposed to handle DDR mode correctly? If not, could you please integrate
> this patch (or Frieder's Linux patch) into your patchset so that the driver
> also
> works on i.MX6ULL/ULZ ?
I will port Frieder's patch for i.mx from Linux to Uboot.
Meanwhile, I am waiting for comments on other patches so that I'll incorporate
all changes in next version.
@Ye li
Please see attached email for reference.
Does Frieder's patch(f6910679e17a) resolves the fix proposed by you.
Also, can you please help in testing other i.mx platforms after including the
change.
Thanks
Kuldeep
>
> Thanks,
> Stefan
>
> > Frieder Schrempf (1):
> >imx: imx6sx: Remove unused 'num-cs' property
> >
> > Kuldeep Singh (7):
> >spi: Remove old freescale qspi driver
> >spi: Transform the FSL QuadSPI driver to use the SPI MEM API
> >treewide: Remove unused FSL QSPI config options
> >configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
> >configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
> >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
