[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Hannes Schmelzer]

Hi Eldor,

just found your post in the mailinglist.

https://lists.denx.de/pipermail/u-boot/2016-December/276491.html

Reason why i'm searched there is, that i've now excactly same problem as 
you.

----

----

I'm using most current mainline u-boot.

did you ever found some solution for your trouble ?

cheers,
Hannes

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jagan Teki]

On Fri, Sep 1, 2017 at 5:23 PM, Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> Hi Eldor,
>
> just found your post in the mailinglist.
>
> https://lists.denx.de/pipermail/u-boot/2016-December/276491.html
>
> Reason why i'm searched there is, that i've now excactly same problem as
> you.

Can you give some details, issue came-up while 'sf probe' or 'sf read' ?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Hannes Schmelzer]

"U-Boot" <u-boot-bounces@lists.denx.de> schrieb am 01.09.2017 16:39:03:

> Von: Jagan Teki <jagannadh.teki@gmail.com>
> An: Hannes Schmelzer <hannes@schmelzer.or.at>
> Kopie: "u-boot at lists.denx.de >> u-boot" <u-boot@lists.denx.de>, 
er at systemsoft.no
> Datum: 01.09.2017 16:39
> Betreff: Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC 
FPGA
> Gesendet von: "U-Boot" <u-boot-bounces@lists.denx.de>
> 
> On Fri, Sep 1, 2017 at 5:23 PM, Hannes Schmelzer 
<hannes@schmelzer.or.at> wrote:
> > Hi Eldor,
> >
> > just found your post in the mailinglist.
> >
> > https://lists.denx.de/pipermail/u-boot/2016-December/276491.html
> >
> > Reason why i'm searched there is, that i've now excactly same problem 
as
> > you.
> 
> Can you give some details, issue came-up while 'sf probe' or 'sf read' ?

Hi Jagan,
please have a look into the weblink to the denx mailing list server.
I have basically same trouble as eldor reported the days ago.

A simple 'sf probe' ends up in a 
### ERROR ### Please RESET the board ###
Interesting detail is, that the information about the flash (type, size, 
...) is printed out quite before the "hang".

On wednesday i have the next time-slot to access the socfpga devkit board.
So i could bring in more details if necessary.

> 
> thanks!
> -- 
> Jagan Teki

cheers,
Hannes

[U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Hannes Schmelzer]

Hi Jagan,


On 09/04/2017 08:22 AM, Hannes Schmelzer wrote:
> "U-Boot" <u-boot-bounces@lists.denx.de> schrieb am 01.09.2017 16:39:03:
> <hannes@schmelzer.or.at> wrote:
>>> Hi Eldor,
>>>
>>> just found your post in the mailinglist.
>>>
>>> https://lists.denx.de/pipermail/u-boot/2016-December/276491.html
>>>
>>> Reason why i'm searched there is, that i've now excactly same problem
> as
>>> you.
>> Can you give some details, issue came-up while 'sf probe' or 'sf read' ?
> Hi Jagan,
> please have a look into the weblink to the denx mailing list server.
> I have basically same trouble as eldor reported the days ago.
>
> A simple 'sf probe' ends up in a
> ### ERROR ### Please RESET the board ###
> Interesting detail is, that the information about the flash (type, size,
> ...) is printed out quite before the "hang".
>
> On wednesday i have the next time-slot to access the socfpga devkit board.
> So i could bring in more details if necessary.
as told few days ago, i've now again access to my socfpga devkit board.
Here comes the console output:

---
U-Boot SPL 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35)
/home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Preparing 
to start memory calibration
/home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: CALIBRATION 
PASSED
/home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Calibration 
complete
Trying to boot from MMC1
spl: partition error


U-Boot 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35 +0200)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
        Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   dwmmc0 at ff704000: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Altera SOCFPGA Cyclone V SoC Development Kit
Net:
Error: ethernet at ff702000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0
=> sf probe
SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 
64 MiB
### ERROR ### Please RESET the board ###
----

Afterwards the board does some reset (about 20sec. later).

cheers,
Hannes

[U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Clément Péron]

Hi,

I got also somme issue with my QSPI on CycmoneV and u-boot 2017.07
I cherry-picked commits from  Jason Rush :
b90ce1c29023abe730d2b4174294bdc09acef3e0
836a0278476be94c95ff084f81c2302fc5c0265c
b0eac7e0d1e4817388543b58d30b322d0bac49a8

Also i forgot to put the
"u-boot,dm-pre-reloc;" in my device tree in the qspi node.

Now my QSPI is working fine except the sf unlock / lock
I have remove the "clear BP# bits" in the mtd/spi/spi_flash.c

Hope this can help you

Regards,
Clement

2017-09-06 8:10 GMT+02:00 Hannes Schmelzer <hannes@schmelzer.or.at>:
> Hi Jagan,
>
>
> On 09/04/2017 08:22 AM, Hannes Schmelzer wrote:
>>
>> "U-Boot" <u-boot-bounces@lists.denx.de> schrieb am 01.09.2017 16:39:03:
>> <hannes@schmelzer.or.at> wrote:
>>>>
>>>> Hi Eldor,
>>>>
>>>> just found your post in the mailinglist.
>>>>
>>>> https://lists.denx.de/pipermail/u-boot/2016-December/276491.html
>>>>
>>>> Reason why i'm searched there is, that i've now excactly same problem
>>
>> as
>>>>
>>>> you.
>>>
>>> Can you give some details, issue came-up while 'sf probe' or 'sf read' ?
>>
>> Hi Jagan,
>> please have a look into the weblink to the denx mailing list server.
>> I have basically same trouble as eldor reported the days ago.
>>
>> A simple 'sf probe' ends up in a
>> ### ERROR ### Please RESET the board ###
>> Interesting detail is, that the information about the flash (type, size,
>> ...) is printed out quite before the "hang".
>>
>> On wednesday i have the next time-slot to access the socfpga devkit board.
>> So i could bring in more details if necessary.
>
> as told few days ago, i've now again access to my socfpga devkit board.
> Here comes the console output:
>
> ---
> U-Boot SPL 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35)
> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Preparing to
> start memory calibration
> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: CALIBRATION
> PASSED
> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Calibration
> complete
> Trying to boot from MMC1
> spl: partition error
>
>
> U-Boot 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35 +0200)
>
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> BOOT:  SD/MMC Internal Transceiver (3.0V)
>        Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   dwmmc0 at ff704000: 0
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> Net:
> Error: ethernet at ff702000 address not set.
> No ethernet found.
> Hit any key to stop autoboot:  0
> => sf probe
> SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 64
> MiB
> ### ERROR ### Please RESET the board ###
> ----
>
> Afterwards the board does some reset (about 20sec. later).
>
>
> cheers,
> Hannes
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Clément Péron]

Sorry these are my local commits you can find them here :

https://patchwork.ozlabs.org/patch/765992/
https://patchwork.ozlabs.org/patch/765996/
https://patchwork.ozlabs.org/patch/765997/
https://patchwork.ozlabs.org/patch/765998/

2017-09-22 14:12 GMT+02:00 Clément Péron <peron.clem@gmail.com>:
> Hi,
>
> I got also somme issue with my QSPI on CycmoneV and u-boot 2017.07
> I cherry-picked commits from  Jason Rush :
> b90ce1c29023abe730d2b4174294bdc09acef3e0
> 836a0278476be94c95ff084f81c2302fc5c0265c
> b0eac7e0d1e4817388543b58d30b322d0bac49a8
>
> Also i forgot to put the
> "u-boot,dm-pre-reloc;" in my device tree in the qspi node.
>
> Now my QSPI is working fine except the sf unlock / lock
> I have remove the "clear BP# bits" in the mtd/spi/spi_flash.c
>
> Hope this can help you
>
> Regards,
> Clement
>
> 2017-09-06 8:10 GMT+02:00 Hannes Schmelzer <hannes@schmelzer.or.at>:
>> Hi Jagan,
>>
>>
>> On 09/04/2017 08:22 AM, Hannes Schmelzer wrote:
>>>
>>> "U-Boot" <u-boot-bounces@lists.denx.de> schrieb am 01.09.2017 16:39:03:
>>> <hannes@schmelzer.or.at> wrote:
>>>>>
>>>>> Hi Eldor,
>>>>>
>>>>> just found your post in the mailinglist.
>>>>>
>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/276491.html
>>>>>
>>>>> Reason why i'm searched there is, that i've now excactly same problem
>>>
>>> as
>>>>>
>>>>> you.
>>>>
>>>> Can you give some details, issue came-up while 'sf probe' or 'sf read' ?
>>>
>>> Hi Jagan,
>>> please have a look into the weblink to the denx mailing list server.
>>> I have basically same trouble as eldor reported the days ago.
>>>
>>> A simple 'sf probe' ends up in a
>>> ### ERROR ### Please RESET the board ###
>>> Interesting detail is, that the information about the flash (type, size,
>>> ...) is printed out quite before the "hang".
>>>
>>> On wednesday i have the next time-slot to access the socfpga devkit board.
>>> So i could bring in more details if necessary.
>>
>> as told few days ago, i've now again access to my socfpga devkit board.
>> Here comes the console output:
>>
>> ---
>> U-Boot SPL 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35)
>> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Preparing to
>> start memory calibration
>> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: CALIBRATION
>> PASSED
>> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Calibration
>> complete
>> Trying to boot from MMC1
>> spl: partition error
>>
>>
>> U-Boot 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35 +0200)
>>
>> CPU:   Altera SoCFPGA Platform
>> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>        Watchdog enabled
>> I2C:   ready
>> DRAM:  1 GiB
>> MMC:   dwmmc0 at ff704000: 0
>> *** Warning - bad CRC, using default environment
>>
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>> Net:
>> Error: ethernet at ff702000 address not set.
>> No ethernet found.
>> Hit any key to stop autoboot:  0
>> => sf probe
>> SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 64
>> MiB
>> ### ERROR ### Please RESET the board ###
>> ----
>>
>> Afterwards the board does some reset (about 20sec. later).
>>
>>
>> cheers,
>> Hannes
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot

[U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Hannes Schmelzer]

On 09/22/2017 02:20 PM, Clément Péron wrote:
> Sorry these are my local commits you can find them here :
>
> https://patchwork.ozlabs.org/patch/765992/
> https://patchwork.ozlabs.org/patch/765996/
> https://patchwork.ozlabs.org/patch/765997/
> https://patchwork.ozlabs.org/patch/765998/
Hi,
just tested this on my cyclone5 board, but unfortunately without success.

---
U-Boot SPL 2017.09-00354-g824def8 (Sep 27 2017 - 06:47:19)
(....)
Hit any key to stop autoboot:  0
=> sf probe
SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 
64 MiB
### ERROR ### Please RESET the board ###
----

same behavior as before.

But the good news are, that a colleague of mine successfully brought up 
a custom board with this patch.
Prior he had trouble in SPL accessing the flash.

I will poke him to give some "tested-by" credits on this.

cheers,
Hannes

>
> 2017-09-22 14:12 GMT+02:00 Clément Péron <peron.clem@gmail.com>:
>> Hi,
>>
>> I got also somme issue with my QSPI on CycmoneV and u-boot 2017.07
>> I cherry-picked commits from  Jason Rush :
>> b90ce1c29023abe730d2b4174294bdc09acef3e0
>> 836a0278476be94c95ff084f81c2302fc5c0265c
>> b0eac7e0d1e4817388543b58d30b322d0bac49a8
>>
>> Also i forgot to put the
>> "u-boot,dm-pre-reloc;" in my device tree in the qspi node.
>>
>> Now my QSPI is working fine except the sf unlock / lock
>> I have remove the "clear BP# bits" in the mtd/spi/spi_flash.c
>>
>> Hope this can help you
>>
>> Regards,
>> Clement
>>
>> 2017-09-06 8:10 GMT+02:00 Hannes Schmelzer <hannes@schmelzer.or.at>:
>>> Hi Jagan,
>>>
>>>
>>> On 09/04/2017 08:22 AM, Hannes Schmelzer wrote:
>>>> "U-Boot" <u-boot-bounces@lists.denx.de> schrieb am 01.09.2017 16:39:03:
>>>> <hannes@schmelzer.or.at> wrote:
>>>>>> Hi Eldor,
>>>>>>
>>>>>> just found your post in the mailinglist.
>>>>>>
>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/276491.html
>>>>>>
>>>>>> Reason why i'm searched there is, that i've now excactly same problem
>>>> as
>>>>>> you.
>>>>> Can you give some details, issue came-up while 'sf probe' or 'sf read' ?
>>>> Hi Jagan,
>>>> please have a look into the weblink to the denx mailing list server.
>>>> I have basically same trouble as eldor reported the days ago.
>>>>
>>>> A simple 'sf probe' ends up in a
>>>> ### ERROR ### Please RESET the board ###
>>>> Interesting detail is, that the information about the flash (type, size,
>>>> ...) is printed out quite before the "hang".
>>>>
>>>> On wednesday i have the next time-slot to access the socfpga devkit board.
>>>> So i could bring in more details if necessary.
>>> as told few days ago, i've now again access to my socfpga devkit board.
>>> Here comes the console output:
>>>
>>> ---
>>> U-Boot SPL 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35)
>>> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Preparing to
>>> start memory calibration
>>> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: CALIBRATION
>>> PASSED
>>> /home/schmelzerh/work/u-boot/drivers/ddr/altera/sequencer.c: Calibration
>>> complete
>>> Trying to boot from MMC1
>>> spl: partition error
>>>
>>>
>>> U-Boot 2017.09-rc4-00023-g84a4206 (Sep 06 2017 - 08:02:35 +0200)
>>>
>>> CPU:   Altera SoCFPGA Platform
>>> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>         Watchdog enabled
>>> I2C:   ready
>>> DRAM:  1 GiB
>>> MMC:   dwmmc0 at ff704000: 0
>>> *** Warning - bad CRC, using default environment
>>>
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>>> Net:
>>> Error: ethernet at ff702000 address not set.
>>> No ethernet found.
>>> Hit any key to stop autoboot:  0
>>> => sf probe
>>> SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 64
>>> MiB
>>> ### ERROR ### Please RESET the board ###
>>> ----
>>>
>>> Afterwards the board does some reset (about 20sec. later).
>>>
>>>
>>> cheers,
>>> Hannes
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Mr. goldenstreet]

it worked!
i applied the patches alone and it didn't work, but then i noticed simon's
note to add compatible = "spi-flash" so i added it on the arria 5 dts file,
and it worked.
i think it should be added to the patches.

thanks for the help!



--
Sent from: http://u-boot.10912.n7.nabble.com/

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Simon Goldschmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8-sig", Size: 3979 bytes --]


Pepperl+Fuchs GmbH, Mannheim
Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), Werner Guthier, Mehmet Hatiboglu
Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus Michael
Registergericht/Register Court: AG Mannheim HRB 4713
On 18.01.2018 06:07, Jason Rush wrote:
> On 1/17/2018 7:46 AM, RB23 wrote:
>> i checked, and if you mean these patches:
>> https://patchwork.ozlabs.org/patch/765992/
>> https://patchwork.ozlabs.org/patch/765996/
>> https://patchwork.ozlabs.org/patch/765997/
>> https://patchwork.ozlabs.org/patch/765998/
>>
>> i already applied them, and they didn't work as well.
>>
>> i also found these patches which i didn't try yet:
>> https://lists.denx.de/pipermail/u-boot/2017-May/292230.html
>>
>> should i try those instead?
>>
>> 2018-01-17 15:09 GMT+02:00 Marek Vasut <marex@denx.de>:
>>
>>> On 01/17/2018 02:06 PM, Simon Goldschmidt wrote:
>>>> On 17.01.2018 14:01, RB23 wrote:
>>>>> hey, i downloaded the september and november versions and i applied
>>>>> the patches on both of them, re-compiled the u boot,
>>>>> and still, it gives me the same error when trying the command "sf probe"
>>>>> i'm not sure what to do, is it possible that i missed something? like
>>>>> a define or something in the make menuconfig?
>>>>> i did some debugging and it seems that the crash happens on this line:
>>>>> div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
>>>>> thanks.
>>>>>
>>>> I don't know exactly which patches you are talking about, but the
>>>> divide-by-zero problem is still present with all patches I applied. To
>>>> fix it, you need to set up your device tree correctly so that the speed
>>>> is initialized.
>>>>
>>>> If I remember correctly, you need need to have a flash chip below the
>>>> qspi in the device tree. Check Jason's changes to the various socfpga
>>>> dts files.
>>>>
>>> Er, maybe a patch which checks this condition wouldn't hurt ?
>>>
>>> --
>>> Best regards,
>>> Marek Vasut
>>>
> I re-tested on a Cyclone V SoCKit devboard and a custom Arria V board using the DTS
> patches I submitted (the 4 you mentioned above) and Vignesh's patch to fix the cache
> invalidation problem, and I don't get the divide-by-zero problem.  This looks like the
> clock rate for the flash part isn't getting set and is defaulting to 0 for some reason.
> I would look at your device tree.  Are you using a stock device tree, or is this a custom
> board? Make sure the 'spi-max-frequency' is being set for the flash part that is a child
> to the cadence qspi node in the device tree.

Note that in addition to the 'spi-max-frequency' property, the flash 
part (child of the cadence qspi node) also must have 'compatible = 
"spi-flash";'.

This only seems to fail in U-Boot when loading the environment or 
executing 'sf probe' without speed argument. SPL succeeds to load U-Boot 
from qspi without a 'spi-max-frequency' because the cadence qspi driver 
has a fallback to 500 kHz which gets overridden by the code from U-Boot.

Regards,
Simon


Wichtiger Hinweis:
Diese E-Mail einschliesslich ihrer Anhaenge enthaelt vertrauliche und rechtlich geschuetzte Informationen, die nur fuer den Adressaten bestimmt sind. 
Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und loeschen Sie diese Nachricht und ihre Anhaenge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veraenderung der E-Mail ist untersagt. Der Absender haftet nicht fuer Inhalte von veraenderten E-Mails.


Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Simon Goldschmidt]

On 18.01.2018 06:07, Jason Rush wrote:
> On 1/17/2018 7:46 AM, RB23 wrote:
>> i checked, and if you mean these patches:
>> https://patchwork.ozlabs.org/patch/765992/
>> https://patchwork.ozlabs.org/patch/765996/
>> https://patchwork.ozlabs.org/patch/765997/
>> https://patchwork.ozlabs.org/patch/765998/
>>
>> i already applied them, and they didn't work as well.
>>
>> i also found these patches which i didn't try yet:
>> https://lists.denx.de/pipermail/u-boot/2017-May/292230.html
>>
>> should i try those instead?
>>
>> 2018-01-17 15:09 GMT+02:00 Marek Vasut <marex@denx.de>:
>>
>>> On 01/17/2018 02:06 PM, Simon Goldschmidt wrote:
>>>> On 17.01.2018 14:01, RB23 wrote:
>>>>> hey, i downloaded the september and november versions and i applied
>>>>> the patches on both of them, re-compiled the u boot,
>>>>> and still, it gives me the same error when trying the command "sf probe"
>>>>> i'm not sure what to do, is it possible that i missed something? like
>>>>> a define or something in the make menuconfig?
>>>>> i did some debugging and it seems that the crash happens on this line:
>>>>> div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
>>>>> thanks.
>>>>>
>>>> I don't know exactly which patches you are talking about, but the
>>>> divide-by-zero problem is still present with all patches I applied. To
>>>> fix it, you need to set up your device tree correctly so that the speed
>>>> is initialized.
>>>>
>>>> If I remember correctly, you need need to have a flash chip below the
>>>> qspi in the device tree. Check Jason's changes to the various socfpga
>>>> dts files.
>>>>
>>> Er, maybe a patch which checks this condition wouldn't hurt ?

Hmm, the problem here is not specific to cadence_qspi, but to the clock 
rate calculation in an upper layer (as Jason wrote below). From the ML, 
I got the impression it's OK like that (which I don't think it is, it 
should at least give a hint what's going wrong instead of a data abort). 
However, I'll try to prepare a patch for that as soon as I find the time.

Regards,
Simon

>>>
>>> --
>>> Best regards,
>>> Marek Vasut
>>>
> I re-tested on a Cyclone V SoCKit devboard and a custom Arria V board using the DTS
> patches I submitted (the 4 you mentioned above) and Vignesh's patch to fix the cache
> invalidation problem, and I don't get the divide-by-zero problem.  This looks like the
> clock rate for the flash part isn't getting set and is defaulting to 0 for some reason.
> I would look at your device tree.  Are you using a stock device tree, or is this a custom
> board? Make sure the 'spi-max-frequency' is being set for the flash part that is a child
> to the cadence qspi node in the device tree.
>
> -- Jason
>

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jason Rush]

On 1/17/2018 7:46 AM, RB23 wrote:
> i checked, and if you mean these patches:
> https://patchwork.ozlabs.org/patch/765992/
> https://patchwork.ozlabs.org/patch/765996/
> https://patchwork.ozlabs.org/patch/765997/
> https://patchwork.ozlabs.org/patch/765998/
>
> i already applied them, and they didn't work as well.
>
> i also found these patches which i didn't try yet:
> https://lists.denx.de/pipermail/u-boot/2017-May/292230.html
>
> should i try those instead?
>
> 2018-01-17 15:09 GMT+02:00 Marek Vasut <marex@denx.de>:
>
>> On 01/17/2018 02:06 PM, Simon Goldschmidt wrote:
>>> On 17.01.2018 14:01, RB23 wrote:
>>>> hey, i downloaded the september and november versions and i applied
>>>> the patches on both of them, re-compiled the u boot,
>>>> and still, it gives me the same error when trying the command "sf probe"
>>>> i'm not sure what to do, is it possible that i missed something? like
>>>> a define or something in the make menuconfig?
>>>> i did some debugging and it seems that the crash happens on this line:
>>>> div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
>>>> thanks.
>>>>
>>> I don't know exactly which patches you are talking about, but the
>>> divide-by-zero problem is still present with all patches I applied. To
>>> fix it, you need to set up your device tree correctly so that the speed
>>> is initialized.
>>>
>>> If I remember correctly, you need need to have a flash chip below the
>>> qspi in the device tree. Check Jason's changes to the various socfpga
>>> dts files.
>>>
>> Er, maybe a patch which checks this condition wouldn't hurt ?
>>
>> --
>> Best regards,
>> Marek Vasut
>>
I re-tested on a Cyclone V SoCKit devboard and a custom Arria V board using the DTS
patches I submitted (the 4 you mentioned above) and Vignesh's patch to fix the cache
invalidation problem, and I don't get the divide-by-zero problem.  This looks like the
clock rate for the flash part isn't getting set and is defaulting to 0 for some reason.
I would look at your device tree.  Are you using a stock device tree, or is this a custom
board? Make sure the 'spi-max-frequency' is being set for the flash part that is a child
to the cadence qspi node in the device tree.

-- Jason

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[RB23]

i checked, and if you mean these patches:
https://patchwork.ozlabs.org/patch/765992/
https://patchwork.ozlabs.org/patch/765996/
https://patchwork.ozlabs.org/patch/765997/
https://patchwork.ozlabs.org/patch/765998/

i already applied them, and they didn't work as well.

i also found these patches which i didn't try yet:
https://lists.denx.de/pipermail/u-boot/2017-May/292230.html

should i try those instead?

2018-01-17 15:09 GMT+02:00 Marek Vasut <marex@denx.de>:

> On 01/17/2018 02:06 PM, Simon Goldschmidt wrote:
> > On 17.01.2018 14:01, RB23 wrote:
> >> hey, i downloaded the september and november versions and i applied
> >> the patches on both of them, re-compiled the u boot,
> >> and still, it gives me the same error when trying the command "sf probe"
> >> i'm not sure what to do, is it possible that i missed something? like
> >> a define or something in the make menuconfig?
> >> i did some debugging and it seems that the crash happens on this line:
> >> div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
> >> thanks.
> >>
> >
> > I don't know exactly which patches you are talking about, but the
> > divide-by-zero problem is still present with all patches I applied. To
> > fix it, you need to set up your device tree correctly so that the speed
> > is initialized.
> >
> > If I remember correctly, you need need to have a flash chip below the
> > qspi in the device tree. Check Jason's changes to the various socfpga
> > dts files.
> >
>
> Er, maybe a patch which checks this condition wouldn't hurt ?
>
> --
> Best regards,
> Marek Vasut
>

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Marek Vasut]

On 01/17/2018 02:06 PM, Simon Goldschmidt wrote:
> On 17.01.2018 14:01, RB23 wrote:
>> hey, i downloaded the september and november versions and i applied
>> the patches on both of them, re-compiled the u boot,
>> and still, it gives me the same error when trying the command "sf probe"
>> i'm not sure what to do, is it possible that i missed something? like
>> a define or something in the make menuconfig?
>> i did some debugging and it seems that the crash happens on this line:
>> div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
>> thanks.
>>
> 
> I don't know exactly which patches you are talking about, but the
> divide-by-zero problem is still present with all patches I applied. To
> fix it, you need to set up your device tree correctly so that the speed
> is initialized.
> 
> If I remember correctly, you need need to have a flash chip below the
> qspi in the device tree. Check Jason's changes to the various socfpga
> dts files.
> 

Er, maybe a patch which checks this condition wouldn't hurt ?

-- 
Best regards,
Marek Vasut

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Simon Goldschmidt]

On 17.01.2018 14:01, RB23 wrote:
> hey, i downloaded the september and november versions and i applied 
> the patches on both of them, re-compiled the u boot,
> and still, it gives me the same error when trying the command "sf probe"
> i'm not sure what to do, is it possible that i missed something? like 
> a define or something in the make menuconfig?
> i did some debugging and it seems that the crash happens on this line:
> div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
> thanks.
>

I don't know exactly which patches you are talking about, but the 
divide-by-zero problem is still present with all patches I applied. To 
fix it, you need to set up your device tree correctly so that the speed 
is initialized.

If I remember correctly, you need need to have a flash chip below the 
qspi in the device tree. Check Jason's changes to the various socfpga 
dts files.

Regards,
Simon

> 2018-01-08 11:17 GMT+02:00 Goldschmidt Simon 
> <sgoldschmidt@de.pepperl-fuchs.com 
> <mailto:sgoldschmidt@de.pepperl-fuchs.com>>:
>
>     On Mon, 08/012018 06:27, Vignesh R wrote:
>     > On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
>     > [...]
>     > >>> 1. The indaddrtrig register was being programmed with an
>     incorrect
>     > >>> value for socfpga as the result of assuming it should be
>     programmed
>     > >>> with the same address as the ahbbase address.  This issue is
>     > >>> resolved by adopting the Linux DT bindings, which has an
>     independent
>     > >>> setting for the indaddrtrig register so the register can be
>     set correctly on all
>     > architectures.  Plus it aligns the DT between u-boot and Linux.
>     > >> That should be an easy patch, so this is the patchset
>     0/5..5/5 that
>     > >> you just submitted ?
>     > > Yes. I saw you Acked it, thank you.
>     > >>> 2. The cadence driver was modified at one point to use the
>     bouncebuf
>     > >>> functions to fix an issue on a TI architecture that
>     expected, where
>     > >>> if I recall correctly all reads except the last have to be
>     32-bit
>     > >>> reads.  However, since the bouncebuf was designed for DMA
>     transfers,
>     > >>> it invalidates the data cache after reading, but since the
>     cadence
>     > >>> is using cpu transfers the newly read data is thrown away
>     when the
>     > >>> cache is invalidated.  This issue is resolved by reverting
>     the commit that
>     > introduced using the bounce buffer for read operations, which
>     according to
>     > Vignesh don't cause any issues to the TI architecture.
>     > >> Hmmmmm, I wonder why you need bounce buffer at all here. The
>     CQSPI
>     > >> literally reads/writes a register space (or some FIFO in register
>     > >> space), there is no DMA involved at all. I also wonder why we
>     have to
>     > >> manipulate with cache at all here.
>     > >
>     > > I agree, I don't believe this needs a bounce buffer at all.  This
>     > > isn't a DMA, there is no need for cache manipulation.  Vignesh
>     > > understands the problem better than I do on the TI platform, but I
>     > > believe it was used since it was an easy way to ensure the
>     register read/writes
>     > were all 32-bits wide up until the last read/write.
>     >
>     > Yes, that was the intention. Unfortunately, I chose to use
>     common bounce buffer
>     > implementation which was doing cache manipulations.
>     >
>     > > I believe the bounce buffer should be removed from the CQSPI
>     driver
>     > > and a different solution should be implemented, but Vignesh should
>     > > weigh in on that since it effects his architecture.
>     > >
>     >
>     > CQSPI on TI K2G has problems with non 32 bit aligned write
>     operations.
>     > But read operations are unaffected. Therefore I have Ack'ed
>     Simon's patch
>     > reverting bouncebuf for read. For writes, I have patches to
>     revert common
>     > bouncebuf usage and use a local pagesize buffer for overcome
>     alignment issue. I
>     > am waiting for current patch backlogs to be merged so that its
>     easy for testing w/o
>     > specifying bunch of dependent patches.
>     >
>     > Or if Simon agrees, I can add his patch to my series post it to
>     mailing list (rebased
>     > on top of Jason's series)?
>
>     Well, it's not really "my" patch, anyway. It reverts a commit of
>     yours, so sure, as long as this does not stand in the way of getting
>     qspi running on 2018.03, go ahead and itegrate it in your patchset.
>
>     I'd be happy to have this sent now so I can test both patchsets on
>     top of 2018.01(-rc).
>
>     Thanks,
>     Simon
>
>

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[RB23]

hey, i downloaded the september and november versions and i applied the
patches on both of them, re-compiled the u boot,
and still, it gives me the same error when trying the command "sf probe"
i'm not sure what to do, is it possible that i missed something? like a
define or something in the make menuconfig?
i did some debugging and it seems that the crash happens on this line:
div = DIV_ROUND_UP(ref_clk_hz, sclk-hz * 2) -1;
thanks.

2018-01-08 11:17 GMT+02:00 Goldschmidt Simon <
sgoldschmidt@de.pepperl-fuchs.com>:

> On Mon, 08/012018 06:27, Vignesh R wrote:
> > On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
> > [...]
> > >>> 1. The indaddrtrig register was being programmed with an incorrect
> > >>> value for socfpga as the result of assuming it should be programmed
> > >>> with the same address as the ahbbase address.  This issue is
> > >>> resolved by adopting the Linux DT bindings, which has an independent
> > >>> setting for the indaddrtrig register so the register can be set
> correctly on all
> > architectures.  Plus it aligns the DT between u-boot and Linux.
> > >> That should be an easy patch, so this is the patchset 0/5..5/5 that
> > >> you just submitted ?
> > > Yes. I saw you Acked it, thank you.
> > >>> 2. The cadence driver was modified at one point to use the bouncebuf
> > >>> functions to fix an issue on a TI architecture that expected, where
> > >>> if I recall correctly all reads except the last have to be 32-bit
> > >>> reads.  However, since the bouncebuf was designed for DMA transfers,
> > >>> it invalidates the data cache after reading, but since the cadence
> > >>> is using cpu transfers the newly read data is thrown away when the
> > >>> cache is invalidated.  This issue is resolved by reverting the
> commit that
> > introduced using the bounce buffer for read operations, which according
> to
> > Vignesh don't cause any issues to the TI architecture.
> > >> Hmmmmm, I wonder why you need bounce buffer at all here. The CQSPI
> > >> literally reads/writes a register space (or some FIFO in register
> > >> space), there is no DMA involved at all. I also wonder why we have to
> > >> manipulate with cache at all here.
> > >
> > > I agree, I don't believe this needs a bounce buffer at all.  This
> > > isn't a DMA, there is no need for cache manipulation.  Vignesh
> > > understands the problem better than I do on the TI platform, but I
> > > believe it was used since it was an easy way to ensure the register
> read/writes
> > were all 32-bits wide up until the last read/write.
> >
> > Yes, that was the intention. Unfortunately, I chose to use common bounce
> buffer
> > implementation which was doing cache manipulations.
> >
> > > I believe the bounce buffer should be removed from the CQSPI driver
> > > and a different solution should be implemented, but Vignesh should
> > > weigh in on that since it effects his architecture.
> > >
> >
> > CQSPI on TI K2G has problems with non 32 bit aligned write operations.
> > But read operations are unaffected. Therefore I have Ack'ed Simon's patch
> > reverting bouncebuf for read. For writes, I have patches to revert common
> > bouncebuf usage and use a local pagesize buffer for overcome alignment
> issue. I
> > am waiting for current patch backlogs to be merged so that its easy for
> testing w/o
> > specifying bunch of dependent patches.
> >
> > Or if Simon agrees, I can add his patch to my series post it to mailing
> list (rebased
> > on top of Jason's series)?
>
> Well, it's not really "my" patch, anyway. It reverts a commit of
> yours, so sure, as long as this does not stand in the way of getting
> qspi running on 2018.03, go ahead and itegrate it in your patchset.
>
> I'd be happy to have this sent now so I can test both patchsets on
> top of 2018.01(-rc).
>
> Thanks,
> Simon
>

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

On Mon, 08/012018 06:27, Vignesh R wrote:
> On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
> [...]
> >>> 1. The indaddrtrig register was being programmed with an incorrect
> >>> value for socfpga as the result of assuming it should be programmed
> >>> with the same address as the ahbbase address.  This issue is
> >>> resolved by adopting the Linux DT bindings, which has an independent
> >>> setting for the indaddrtrig register so the register can be set correctly on all
> architectures.  Plus it aligns the DT between u-boot and Linux.
> >> That should be an easy patch, so this is the patchset 0/5..5/5 that
> >> you just submitted ?
> > Yes. I saw you Acked it, thank you.
> >>> 2. The cadence driver was modified at one point to use the bouncebuf
> >>> functions to fix an issue on a TI architecture that expected, where
> >>> if I recall correctly all reads except the last have to be 32-bit
> >>> reads.  However, since the bouncebuf was designed for DMA transfers,
> >>> it invalidates the data cache after reading, but since the cadence
> >>> is using cpu transfers the newly read data is thrown away when the
> >>> cache is invalidated.  This issue is resolved by reverting the commit that
> introduced using the bounce buffer for read operations, which according to
> Vignesh don't cause any issues to the TI architecture.
> >> Hmmmmm, I wonder why you need bounce buffer at all here. The CQSPI
> >> literally reads/writes a register space (or some FIFO in register
> >> space), there is no DMA involved at all. I also wonder why we have to
> >> manipulate with cache at all here.
> >
> > I agree, I don't believe this needs a bounce buffer at all.  This
> > isn't a DMA, there is no need for cache manipulation.  Vignesh
> > understands the problem better than I do on the TI platform, but I
> > believe it was used since it was an easy way to ensure the register read/writes
> were all 32-bits wide up until the last read/write.
> 
> Yes, that was the intention. Unfortunately, I chose to use common bounce buffer
> implementation which was doing cache manipulations.
> 
> > I believe the bounce buffer should be removed from the CQSPI driver
> > and a different solution should be implemented, but Vignesh should
> > weigh in on that since it effects his architecture.
> >
> 
> CQSPI on TI K2G has problems with non 32 bit aligned write operations.
> But read operations are unaffected. Therefore I have Ack'ed Simon's patch
> reverting bouncebuf for read. For writes, I have patches to revert common
> bouncebuf usage and use a local pagesize buffer for overcome alignment issue. I
> am waiting for current patch backlogs to be merged so that its easy for testing w/o
> specifying bunch of dependent patches.
> 
> Or if Simon agrees, I can add his patch to my series post it to mailing list (rebased
> on top of Jason's series)?

Well, it's not really "my" patch, anyway. It reverts a commit of
yours, so sure, as long as this does not stand in the way of getting
qspi running on 2018.03, go ahead and itegrate it in your patchset.

I'd be happy to have this sent now so I can test both patchsets on
top of 2018.01(-rc).

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Vignesh R]

On Monday 08 January 2018 09:10 AM, Jason Rush wrote:
[...]
>>> 1. The indaddrtrig register was being programmed with an incorrect value for socfpga
>>> as the result of assuming it should be programmed with the same address as the
>>> ahbbase address.  This issue is resolved by adopting the Linux DT bindings, which has
>>> an independent setting for the indaddrtrig register so the register can be set correctly
>>> on all architectures.  Plus it aligns the DT between u-boot and Linux.
>> That should be an easy patch, so this is the patchset 0/5..5/5 that you
>> just submitted ?
> Yes. I saw you Acked it, thank you.
>>> 2. The cadence driver was modified at one point to use the bouncebuf functions to fix
>>> an issue on a TI architecture that expected, where if I recall correctly all reads except
>>> the last have to be 32-bit reads.  However, since the bouncebuf was designed for DMA
>>> transfers, it invalidates the data cache after reading, but since the cadence is using cpu
>>> transfers the newly read data is thrown away when the cache is invalidated.  This issue
>>> is resolved by reverting the commit that introduced using the bounce buffer for read
>>> operations, which according to Vignesh don't cause any issues to the TI architecture.
>> Hmmmmm, I wonder why you need bounce buffer at all here. The CQSPI
>> literally reads/writes a register space (or some FIFO in register
>> space), there is no DMA involved at all. I also wonder why we have to
>> manipulate with cache at all here.
> 
> I agree, I don't believe this needs a bounce buffer at all.  This isn't a DMA, there is
> no need for cache manipulation.  Vignesh understands the problem better than I do
> on the TI platform, but I believe it was used since it was an easy way to ensure the
> register read/writes were all 32-bits wide up until the last read/write.  

Yes, that was the intention. Unfortunately, I chose to use common bounce
buffer implementation which was doing cache manipulations.

> I believe the bounce buffer should be removed from the CQSPI driver and a different solution
> should be implemented, but Vignesh should weigh in on that since it effects his
> architecture.
> 

CQSPI on TI K2G has problems with non 32 bit aligned write operations.
But read operations are unaffected. Therefore I have Ack'ed Simon's
patch reverting bouncebuf for read. For writes, I have patches to revert
common bouncebuf usage and use a local pagesize buffer for overcome
alignment issue. I am waiting for current patch backlogs to be merged so
that its easy for testing w/o specifying bunch of dependent patches.

Or if Simon agrees, I can add his patch to my series post it to mailing
list (rebased on top of Jason's series)?


-- 
Regards
Vignesh

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jason Rush]

On 1/7/2018 5:39 AM, Marek Vasut wrote:
> On 01/06/2018 10:09 PM, Jason Rush wrote:
>> On 1/6/2018 1:29 PM, Marek Vasut wrote:
>>> On 01/06/2018 07:46 PM, Jason Rush wrote:
>>>> On 1/6/2018 9:42 AM, Marek Vasut wrote:
>> <snip>
>>
>>>> There was a minor upstream change to one of the files since I submitted v4 of my
>>>> cadence device-tree patchset, so I rebased and resent the patchset as a v5.  I
>>>> included everyone that was originally involved with the patches and added a CC
>>>> for Marek.
>>>>
>>>> This is only the patchset for the device tree changes for the cadence qspi driver,
>>>> Simon will still have to add the patch that fixes the cache invalidation bug in the
>>>> cadence driver.
>>> Sigh, can we get a single patchset out which fixes the problem ?
>>>
>>> I mean, if I understand this correctly, you're all addressing one single
>>> problem, but with two patchsets, yes ?
>>>
>> Well... The one issue we're trying to fix is that the cadence QSPI hasn't worked on
>> the socfpga arch since late 2016.  However, it's two different issues that have caused
>> this bigger problem:
>>
>> 1. The indaddrtrig register was being programmed with an incorrect value for socfpga
>> as the result of assuming it should be programmed with the same address as the
>> ahbbase address.  This issue is resolved by adopting the Linux DT bindings, which has
>> an independent setting for the indaddrtrig register so the register can be set correctly
>> on all architectures.  Plus it aligns the DT between u-boot and Linux.
> That should be an easy patch, so this is the patchset 0/5..5/5 that you
> just submitted ?
Yes. I saw you Acked it, thank you.
>> 2. The cadence driver was modified at one point to use the bouncebuf functions to fix
>> an issue on a TI architecture that expected, where if I recall correctly all reads except
>> the last have to be 32-bit reads.  However, since the bouncebuf was designed for DMA
>> transfers, it invalidates the data cache after reading, but since the cadence is using cpu
>> transfers the newly read data is thrown away when the cache is invalidated.  This issue
>> is resolved by reverting the commit that introduced using the bounce buffer for read
>> operations, which according to Vignesh don't cause any issues to the TI architecture.
> Hmmmmm, I wonder why you need bounce buffer at all here. The CQSPI
> literally reads/writes a register space (or some FIFO in register
> space), there is no DMA involved at all. I also wonder why we have to
> manipulate with cache at all here.

I agree, I don't believe this needs a bounce buffer at all.  This isn't a DMA, there is
no need for cache manipulation.  Vignesh understands the problem better than I do
on the TI platform, but I believe it was used since it was an easy way to ensure the
register read/writes were all 32-bits wide up until the last read/write.  I believe the
bounce buffer should be removed from the CQSPI driver and a different solution
should be implemented, but Vignesh should weigh in on that since it effects his
architecture.

-- Jason

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Marek Vasut]

On 01/06/2018 10:09 PM, Jason Rush wrote:
> On 1/6/2018 1:29 PM, Marek Vasut wrote:
>> On 01/06/2018 07:46 PM, Jason Rush wrote:
>>> On 1/6/2018 9:42 AM, Marek Vasut wrote:
> 
> <snip>
> 
>>> There was a minor upstream change to one of the files since I submitted v4 of my
>>> cadence device-tree patchset, so I rebased and resent the patchset as a v5.  I
>>> included everyone that was originally involved with the patches and added a CC
>>> for Marek.
>>>
>>> This is only the patchset for the device tree changes for the cadence qspi driver,
>>> Simon will still have to add the patch that fixes the cache invalidation bug in the
>>> cadence driver.
>> Sigh, can we get a single patchset out which fixes the problem ?
>>
>> I mean, if I understand this correctly, you're all addressing one single
>> problem, but with two patchsets, yes ?
>>
> Well... The one issue we're trying to fix is that the cadence QSPI hasn't worked on
> the socfpga arch since late 2016.  However, it's two different issues that have caused
> this bigger problem:
> 
> 1. The indaddrtrig register was being programmed with an incorrect value for socfpga
> as the result of assuming it should be programmed with the same address as the
> ahbbase address.  This issue is resolved by adopting the Linux DT bindings, which has
> an independent setting for the indaddrtrig register so the register can be set correctly
> on all architectures.  Plus it aligns the DT between u-boot and Linux.

That should be an easy patch, so this is the patchset 0/5..5/5 that you
just submitted ?

> 2. The cadence driver was modified at one point to use the bouncebuf functions to fix
> an issue on a TI architecture that expected, where if I recall correctly all reads except
> the last have to be 32-bit reads.  However, since the bouncebuf was designed for DMA
> transfers, it invalidates the data cache after reading, but since the cadence is using cpu
> transfers the newly read data is thrown away when the cache is invalidated.  This issue
> is resolved by reverting the commit that introduced using the bounce buffer for read
> operations, which according to Vignesh don't cause any issues to the TI architecture.

Hmmmmm, I wonder why you need bounce buffer at all here. The CQSPI
literally reads/writes a register space (or some FIFO in register
space), there is no DMA involved at all. I also wonder why we have to
manipulate with cache at all here.

> So, would you prefer two patchsets or one that fixes both issues?  If you'd like just one,
> Simon can collapse my patches along with his revert patch into a single patchset and
> resubmit.

If 1) is fixed by this patchset 0/5..5/5 and 2) is fixed by some other
patchset, then that's fine as is. Thanks for explaining it like so, it
really did help.

> -- Jason
> 


-- 
Best regards,
Marek Vasut

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jason Rush]

On 1/6/2018 1:29 PM, Marek Vasut wrote:
> On 01/06/2018 07:46 PM, Jason Rush wrote:
>> On 1/6/2018 9:42 AM, Marek Vasut wrote:

<snip>

>> There was a minor upstream change to one of the files since I submitted v4 of my
>> cadence device-tree patchset, so I rebased and resent the patchset as a v5.  I
>> included everyone that was originally involved with the patches and added a CC
>> for Marek.
>>
>> This is only the patchset for the device tree changes for the cadence qspi driver,
>> Simon will still have to add the patch that fixes the cache invalidation bug in the
>> cadence driver.
> Sigh, can we get a single patchset out which fixes the problem ?
>
> I mean, if I understand this correctly, you're all addressing one single
> problem, but with two patchsets, yes ?
>
Well... The one issue we're trying to fix is that the cadence QSPI hasn't worked on
the socfpga arch since late 2016.  However, it's two different issues that have caused
this bigger problem:

1. The indaddrtrig register was being programmed with an incorrect value for socfpga
as the result of assuming it should be programmed with the same address as the
ahbbase address.  This issue is resolved by adopting the Linux DT bindings, which has
an independent setting for the indaddrtrig register so the register can be set correctly
on all architectures.  Plus it aligns the DT between u-boot and Linux.

2. The cadence driver was modified at one point to use the bouncebuf functions to fix
an issue on a TI architecture that expected, where if I recall correctly all reads except
the last have to be 32-bit reads.  However, since the bouncebuf was designed for DMA
transfers, it invalidates the data cache after reading, but since the cadence is using cpu
transfers the newly read data is thrown away when the cache is invalidated.  This issue
is resolved by reverting the commit that introduced using the bounce buffer for read
operations, which according to Vignesh don't cause any issues to the TI architecture.

So, would you prefer two patchsets or one that fixes both issues?  If you'd like just one,
Simon can collapse my patches along with his revert patch into a single patchset and
resubmit.

-- Jason

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Marek Vasut]

On 01/06/2018 07:46 PM, Jason Rush wrote:
> On 1/6/2018 9:42 AM, Marek Vasut wrote:
>> On 01/06/2018 02:39 PM, Goldschmidt Simon wrote:
>>> On Fri, 05/01/2018, Marek Vasut wrote:
>>>> On 01/05/2018 08:31 PM, Goldschmidt Simon wrote:
>>>>> On Fri, 05/01/2018 Marek Vasut wrote:
>>>>>> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:
>>>>> <snip>
>>>>>
>>>>>>>>> OK, so I need these patches to get qspi work on socfpga:
>>>>>>>>>
>>>>>>>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>>>>>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>>>>>>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>>>>>>>   https://patchwork.ozlabs.org/patch/838871/
>>>>>>>> I've waited for ack/tested-by from marek or someone who usually worked
>>>>>>>> on these cadence.
>>>>>>> Vignesh acked, who already did some of the last changes. But Ok, I've
>>>>>>> added Marek to the loop.
>>>>>>>
>>>>>>> Marek, do you see any problems here? Are you running QSPI on the
>>>>>>> socfpga platform anywhere?
>>>>>> I am not entirely sure what this partial thread is all about, do you
>>>>>> need some patches Acked ? Repost them including the Acks collected
>>>>>> already and CC me, I want to review them. PW link is not enough.
>>>>> Marek, you were one of the people addressed in "to:" when Jason Rush
>>>>> sent "[PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux"
>>>>> and successors on Nov. 16th 2017.
>>>>>
>>>>> You were also in the "to:" field when I sent "[PATCH v4 1/5] spi:
>>>>> cadence_spi: Sync DT bindings with Linux" on Nov. 17th 2017.
>>>>>
>>>>> Should I resend them anyway?
>>>> I really dunno what to make of this sparse thread, sorry. Also, I don't
>>>> quite remember what happened in this thread on November 17th, sorry.
>>>>
>>>> So maybe you should elaborate what you expect me to do ... or just
>>>> resend the patches, yes.
>>> OK, I'll resend the patches then. I'll try to combine the 2 series
>>> into one but have to check with Jason first.
>> Super, thanks. We really need to sort this QSPI stuff out, it's been
>> going on for way too long.
>>
>> Just make sure to submit it soon, MW opens on the 8th.
>>
> 
> There was a minor upstream change to one of the files since I submitted v4 of my
> cadence device-tree patchset, so I rebased and resent the patchset as a v5.  I
> included everyone that was originally involved with the patches and added a CC
> for Marek.
> 
> This is only the patchset for the device tree changes for the cadence qspi driver,
> Simon will still have to add the patch that fixes the cache invalidation bug in the
> cadence driver.

Sigh, can we get a single patchset out which fixes the problem ?

I mean, if I understand this correctly, you're all addressing one single
problem, but with two patchsets, yes ?

-- 
Best regards,
Marek Vasut

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jason Rush]

On 1/6/2018 9:42 AM, Marek Vasut wrote:
> On 01/06/2018 02:39 PM, Goldschmidt Simon wrote:
>> On Fri, 05/01/2018, Marek Vasut wrote:
>>> On 01/05/2018 08:31 PM, Goldschmidt Simon wrote:
>>>> On Fri, 05/01/2018 Marek Vasut wrote:
>>>>> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:
>>>> <snip>
>>>>
>>>>>>>> OK, so I need these patches to get qspi work on socfpga:
>>>>>>>>
>>>>>>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>>>>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>>>>>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>>>>>>   https://patchwork.ozlabs.org/patch/838871/
>>>>>>> I've waited for ack/tested-by from marek or someone who usually worked
>>>>>>> on these cadence.
>>>>>> Vignesh acked, who already did some of the last changes. But Ok, I've
>>>>>> added Marek to the loop.
>>>>>>
>>>>>> Marek, do you see any problems here? Are you running QSPI on the
>>>>>> socfpga platform anywhere?
>>>>> I am not entirely sure what this partial thread is all about, do you
>>>>> need some patches Acked ? Repost them including the Acks collected
>>>>> already and CC me, I want to review them. PW link is not enough.
>>>> Marek, you were one of the people addressed in "to:" when Jason Rush
>>>> sent "[PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux"
>>>> and successors on Nov. 16th 2017.
>>>>
>>>> You were also in the "to:" field when I sent "[PATCH v4 1/5] spi:
>>>> cadence_spi: Sync DT bindings with Linux" on Nov. 17th 2017.
>>>>
>>>> Should I resend them anyway?
>>> I really dunno what to make of this sparse thread, sorry. Also, I don't
>>> quite remember what happened in this thread on November 17th, sorry.
>>>
>>> So maybe you should elaborate what you expect me to do ... or just
>>> resend the patches, yes.
>> OK, I'll resend the patches then. I'll try to combine the 2 series
>> into one but have to check with Jason first.
> Super, thanks. We really need to sort this QSPI stuff out, it's been
> going on for way too long.
>
> Just make sure to submit it soon, MW opens on the 8th.
>

There was a minor upstream change to one of the files since I submitted v4 of my
cadence device-tree patchset, so I rebased and resent the patchset as a v5.  I
included everyone that was originally involved with the patches and added a CC
for Marek.

This is only the patchset for the device tree changes for the cadence qspi driver,
Simon will still have to add the patch that fixes the cache invalidation bug in the
cadence driver.

-- Jason

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Marek Vasut]

On 01/06/2018 02:39 PM, Goldschmidt Simon wrote:
> On Fri, 05/01/2018, Marek Vasut wrote:
>> On 01/05/2018 08:31 PM, Goldschmidt Simon wrote:
>>> On Fri, 05/01/2018 Marek Vasut wrote:
>>>> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:
>>>
>>> <snip>
>>>
>>>>>>> OK, so I need these patches to get qspi work on socfpga:
>>>>>>>
>>>>>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>>>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>>>>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>>>>>   https://patchwork.ozlabs.org/patch/838871/
>>>>>>
>>>>>> I've waited for ack/tested-by from marek or someone who usually worked
>>>>>> on these cadence.
>>>>>
>>>>> Vignesh acked, who already did some of the last changes. But Ok, I've
>>>>> added Marek to the loop.
>>>>>
>>>>> Marek, do you see any problems here? Are you running QSPI on the
>>>>> socfpga platform anywhere?
>>>> I am not entirely sure what this partial thread is all about, do you
>>>> need some patches Acked ? Repost them including the Acks collected
>>>> already and CC me, I want to review them. PW link is not enough.
>>>
>>> Marek, you were one of the people addressed in "to:" when Jason Rush
>>> sent "[PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux"
>>> and successors on Nov. 16th 2017.
>>>
>>> You were also in the "to:" field when I sent "[PATCH v4 1/5] spi:
>>> cadence_spi: Sync DT bindings with Linux" on Nov. 17th 2017.
>>>
>>> Should I resend them anyway?
>>
>> I really dunno what to make of this sparse thread, sorry. Also, I don't
>> quite remember what happened in this thread on November 17th, sorry.
>>
>> So maybe you should elaborate what you expect me to do ... or just
>> resend the patches, yes.
> 
> OK, I'll resend the patches then. I'll try to combine the 2 series
> into one but have to check with Jason first.

Super, thanks. We really need to sort this QSPI stuff out, it's been
going on for way too long.

Just make sure to submit it soon, MW opens on the 8th.

-- 
Best regards,
Marek Vasut

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

On Fri, 05/01/2018, Marek Vasut wrote:
> On 01/05/2018 08:31 PM, Goldschmidt Simon wrote:
>> On Fri, 05/01/2018 Marek Vasut wrote:
>>> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:
>>
>> <snip>
>>
>>>>>> OK, so I need these patches to get qspi work on socfpga:
>>>>>>
>>>>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>>>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>>>>   https://patchwork.ozlabs.org/patch/838871/
>>>>>
>>>>> I've waited for ack/tested-by from marek or someone who usually worked
>>>>> on these cadence.
>>>>
>>>> Vignesh acked, who already did some of the last changes. But Ok, I've
>>>> added Marek to the loop.
>>>>
>>>> Marek, do you see any problems here? Are you running QSPI on the
>>>> socfpga platform anywhere?
>>> I am not entirely sure what this partial thread is all about, do you
>>> need some patches Acked ? Repost them including the Acks collected
>>> already and CC me, I want to review them. PW link is not enough.
>>
>> Marek, you were one of the people addressed in "to:" when Jason Rush
>> sent "[PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux"
>> and successors on Nov. 16th 2017.
>>
>> You were also in the "to:" field when I sent "[PATCH v4 1/5] spi:
>> cadence_spi: Sync DT bindings with Linux" on Nov. 17th 2017.
>>
>> Should I resend them anyway?
> 
> I really dunno what to make of this sparse thread, sorry. Also, I don't
> quite remember what happened in this thread on November 17th, sorry.
> 
> So maybe you should elaborate what you expect me to do ... or just
> resend the patches, yes.

OK, I'll resend the patches then. I'll try to combine the 2 series
into one but have to check with Jason first.

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Marek Vasut]

On 01/05/2018 08:31 PM, Goldschmidt Simon wrote:
> On Fri, 05/01/2018 Marek Vasut wrote:
>> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:
> 
> <snip>
> 
>>>>> OK, so I need these patches to get qspi work on socfpga:
>>>>>
>>>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>>>   https://patchwork.ozlabs.org/patch/838871/
>>>>
>>>> I've waited for ack/tested-by from marek or someone who usually worked
>>>> on these cadence.
>>>
>>> Vignesh acked, who already did some of the last changes. But Ok, I've
>>> added Marek to the loop.
>>>
>>> Marek, do you see any problems here? Are you running QSPI on the
>>> socfpga platform anywhere?
>> I am not entirely sure what this partial thread is all about, do you
>> need some patches Acked ? Repost them including the Acks collected
>> already and CC me, I want to review them. PW link is not enough.
> 
> Marek, you were one of the people addressed in "to:" when Jason Rush
> sent "[PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux"
> and successors on Nov. 16th 2017.
> 
> You were also in the "to:" field when I sent "[PATCH v4 1/5] spi:
> cadence_spi: Sync DT bindings with Linux" on Nov. 17th 2017.
> 
> Should I resend them anyway?

I really dunno what to make of this sparse thread, sorry. Also, I don't
quite remember what happened in this thread on November 17th, sorry.

So maybe you should elaborate what you expect me to do ... or just
resend the patches, yes.

-- 
Best regards,
Marek Vasut

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

On Fri, 05/01/2018 Marek Vasut wrote:
> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:

<snip>

>>>> OK, so I need these patches to get qspi work on socfpga:
>>>>
>>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>>   https://patchwork.ozlabs.org/patch/838871/
>>>
>>> I've waited for ack/tested-by from marek or someone who usually worked
>>> on these cadence.
>>
>> Vignesh acked, who already did some of the last changes. But Ok, I've
>> added Marek to the loop.
>>
>> Marek, do you see any problems here? Are you running QSPI on the
>> socfpga platform anywhere?
> I am not entirely sure what this partial thread is all about, do you
> need some patches Acked ? Repost them including the Acks collected
> already and CC me, I want to review them. PW link is not enough.

Marek, you were one of the people addressed in "to:" when Jason Rush
sent "[PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux"
and successors on Nov. 16th 2017.

You were also in the "to:" field when I sent "[PATCH v4 1/5] spi:
cadence_spi: Sync DT bindings with Linux" on Nov. 17th 2017.

Should I resend them anyway?

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Marek Vasut]

On 01/05/2018 04:49 PM, Goldschmidt Simon wrote:
> + Marek (as Jagan wants an ack)
> 
> On 05/01/2018 Jagan Teki wrote:
>> On Fri, Jan 5, 2018 at 5:32 PM, Goldschmidt Simon wrote:
>>> + Vignesh
>>> + Jason
>>>
>>> On Wed, 03/01/2018 16:57, Goldschmidt Simon wrote:
>>>> On Wed, 03/01/2018 14:51, Jagan Teki wrote:
>>>>>> There were already patches posted on this list by me and others, but
>>>>>> unfortunately they haven't made it into the repository, yet.
>>>>>>
>>>>>> Jagan, could you comment on the status of these fixes? I can search
>>>>>> for the patchwork items related if you want me to.
>>>>>
>>>>> 2 out of 1 of this[1] have some discussion still going is it?
>>>>>
>>>>> [1] https://patchwork.ozlabs.org/patch/838195/
>>>>
>>>> No, that series should be dropped. I don't know if I can do anything about that in
>>>> patchwork though?
>>>>
>>>> Let me check the patches from my upstreaming queue when I'm back at work
>>>> tomorrow. I'll send a list of patchwork items I needed to get QSPI running on
> <>> mach-socfpga.
>>>
>>> OK, so I need these patches to get qspi work on socfpga:
>>>
>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>>   https://patchwork.ozlabs.org/patch/838871/
>>
>> I've waited for ack/tested-by from marek or someone who usually worked
>> on these cadence.
> 
> Vignesh acked, who already did some of the last changes. But Ok, I've
> added Marek to the loop.
> 
> Marek, do you see any problems here? Are you running QSPI on the
> socfpga platform anywhere?
I am not entirely sure what this partial thread is all about, do you
need some patches Acked ? Repost them including the Acks collected
already and CC me, I want to review them. PW link is not enough.

-- 
Best regards,
Marek Vasut

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

+ Marek (as Jagan wants an ack)

On 05/01/2018 Jagan Teki wrote:
> On Fri, Jan 5, 2018 at 5:32 PM, Goldschmidt Simon wrote:
>> + Vignesh
>> + Jason
>>
>> On Wed, 03/01/2018 16:57, Goldschmidt Simon wrote:
>>> On Wed, 03/01/2018 14:51, Jagan Teki wrote:
>>> >> There were already patches posted on this list by me and others, but
>>> >> unfortunately they haven't made it into the repository, yet.
>>> >>
>>> >> Jagan, could you comment on the status of these fixes? I can search
>>> >> for the patchwork items related if you want me to.
>>> >
>>> > 2 out of 1 of this[1] have some discussion still going is it?
>>> >
>>> > [1] https://patchwork.ozlabs.org/patch/838195/
>>>
>>> No, that series should be dropped. I don't know if I can do anything about that in
>>> patchwork though?
>>>
>>> Let me check the patches from my upstreaming queue when I'm back at work
>>> tomorrow. I'll send a list of patchwork items I needed to get QSPI running on
<>> mach-socfpga.
>>
>> OK, so I need these patches to get qspi work on socfpga:
>>
>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
>> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>>   https://patchwork.ozlabs.org/patch/838871/
> 
> I've waited for ack/tested-by from marek or someone who usually worked
> on these cadence.

Vignesh acked, who already did some of the last changes. But Ok, I've
added Marek to the loop.

Marek, do you see any problems here? Are you running QSPI on the
socfpga platform anywhere?

> 
>>
>> All patches were discussed with Vignesh in November. Could we make
>> sure these make it into 2018.03 now that we missed 2018.01?
>>
>> Aside from that, I have this patch running which ensures my QSPI (that
>> does not have a reset line) is put into 3 byte address mode that
>> U-Boot needs. This would be *very* helpful, too:
>> https://patchwork.ozlabs.org/patch/826919/
> 
> issue discussing with spi-nor changes as well, we will figure it out
> and try for best possible.

Ok, this is a different issue anyway. It is not related to socfpga
or cadence qspi. Maybe I can even trick my Linux to use 4 byte opcodes
instead of the 4 byte mode...

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jagan Teki]

On Fri, Jan 5, 2018 at 5:32 PM, Goldschmidt Simon
<sgoldschmidt@de.pepperl-fuchs.com> wrote:
> + Vignesh
> + Jason
>
> On Wed, 03/01/2018 16:57, Goldschmidt Simon wrote:
>> On Wed, 03/01/2018 14:51, Jagan Teki wrote:
>> >> There were already patches posted on this list by me and others, but
>> >> unfortunately they haven't made it into the repository, yet.
>> >>
>> >> Jagan, could you comment on the status of these fixes? I can search
>> >> for the patchwork items related if you want me to.
>> >
>> > 2 out of 1 of this[1] have some discussion still going is it?
>> >
>> > [1] https://patchwork.ozlabs.org/patch/838195/
>>
>> No, that series should be dropped. I don't know if I can do anything about that in
>> patchwork though?
>>
>> Let me check the patches from my upstreaming queue when I'm back at work
>> tomorrow. I'll send a list of patchwork items I needed to get QSPI running on
>> mach-socfpga.
>
> OK, so I need these patches to get qspi work on socfpga:
>
> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
>   https://patchwork.ozlabs.org/project/uboot/list/?series=13864
> - Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
>   https://patchwork.ozlabs.org/patch/838871/

I've waited for ack/tested-by from marek or someone who usually worked
on these cadence.

>
> All patches were discussed with Vignesh in November. Could we make
> sure these make it into 2018.03 now that we missed 2018.01?
>
> Aside from that, I have this patch running which ensures my QSPI (that
> does not have a reset line) is put into 3 byte address mode that
> U-Boot needs. This would be *very* helpful, too:
> https://patchwork.ozlabs.org/patch/826919/

issue discussing with spi-nor changes as well, we will figure it out
and try for best possible.

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

+ Vignesh
+ Jason

On Wed, 03/01/2018 16:57, Goldschmidt Simon wrote:
> On Wed, 03/01/2018 14:51, Jagan Teki wrote:
> >> There were already patches posted on this list by me and others, but
> >> unfortunately they haven't made it into the repository, yet.
> >>
> >> Jagan, could you comment on the status of these fixes? I can search
> >> for the patchwork items related if you want me to.
> >
> > 2 out of 1 of this[1] have some discussion still going is it?
> >
> > [1] https://patchwork.ozlabs.org/patch/838195/
> 
> No, that series should be dropped. I don't know if I can do anything about that in
> patchwork though?
> 
> Let me check the patches from my upstreaming queue when I'm back at work
> tomorrow. I'll send a list of patchwork items I needed to get QSPI running on
> mach-socfpga.

OK, so I need these patches to get qspi work on socfpga:

- Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush:
  https://patchwork.ozlabs.org/project/uboot/list/?series=13864
- Patch "Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible" (v2)
  https://patchwork.ozlabs.org/patch/838871/

All patches were discussed with Vignesh in November. Could we make
sure these make it into 2018.03 now that we missed 2018.01?

Aside from that, I have this patch running which ensures my QSPI (that
does not have a reset line) is put into 3 byte address mode that
U-Boot needs. This would be *very* helpful, too:
https://patchwork.ozlabs.org/patch/826919/

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Mr. goldenstreet]

yeah, those patches might help me a lot, i can't get it to work right now.

thanks a lot.



--
Sent from: http://u-boot.10912.n7.nabble.com/

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

On Wed, 03/01/2018 14:51, Jagan Teki wrote:
>> There were already patches posted on this list by me and others, but
>> unfortunately they haven't made it into the repository, yet.
>>
>> Jagan, could you comment on the status of these fixes? I can search
>> for the patchwork items related if you want me to.
> 
> 2 out of 1 of this[1] have some discussion still going is it?
> 
> [1] https://patchwork.ozlabs.org/patch/838195/

No, that series should be dropped. I don't know if I can do anything
about that in patchwork though?

Let me check the patches from my upstreaming queue when I'm back at
work tomorrow. I'll send a list of patchwork items I needed to get
QSPI running on mach-socfpga.

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Jagan Teki]

On Wed, Jan 3, 2018 at 7:08 PM, Goldschmidt Simon
<sgoldschmidt@de.pepperl-fuchs.com> wrote:
> + Jagan
>
> On Wed, 03/01/2018, Mr. goldenstreet wrote:
>> hey, i have looked at this thread:
>> http://u-boot.10912.n7.nabble.com/QSPI-quot-sf-probe-quot-quot-sf-read-quot-on-
>> Altera-SoC-FPGA-td304882.html
>>
>> i'm having the same problem with Arria 5, when i try to use the "sf probe"
>> command on the nor flash, the result i'm getting0 is:
>>
>> SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total
>> 64 MiB
>> ### ERROR ### Please RESET the board ###
>>
>>  i have already tried to use the patches for the uboot code and also to add more
>> defines before making the uboot, but it still doesn't work for me.
>>
>> any ideas? thanks ahead.
>
> There were already patches posted on this list by me and others, but
> unfortunately they haven't made it into the repository, yet.
>
> Jagan, could you comment on the status of these fixes? I can search
> for the patchwork items related if you want me to.

2 out of 1 of this[1] have some discussion still going is it?

[1] https://patchwork.ozlabs.org/patch/838195/

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Goldschmidt Simon]

+ Jagan

On Wed, 03/01/2018, Mr. goldenstreet wrote:
> hey, i have looked at this thread:
> http://u-boot.10912.n7.nabble.com/QSPI-quot-sf-probe-quot-quot-sf-read-quot-on-
> Altera-SoC-FPGA-td304882.html
> 
> i'm having the same problem with Arria 5, when i try to use the "sf probe"
> command on the nor flash, the result i'm getting0 is:
> 
> SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total
> 64 MiB
> ### ERROR ### Please RESET the board ###
> 
>  i have already tried to use the patches for the uboot code and also to add more
> defines before making the uboot, but it still doesn't work for me.
> 
> any ideas? thanks ahead.

There were already patches posted on this list by me and others, but
unfortunately they haven't made it into the repository, yet.

Jagan, could you comment on the status of these fixes? I can search
for the patchwork items related if you want me to.

I'd really like these fixes to go in without waiting for the new
spi-nor code.

Thanks,
Simon

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Mr. goldenstreet]

hey, i have looked at this thread:
http://u-boot.10912.n7.nabble.com/QSPI-quot-sf-probe-quot-quot-sf-read-quot-on-Altera-SoC-FPGA-td304882.html

i'm having the same problem with Arria 5,
when i try to use the "sf probe" command on the nor flash,
the result i'm getting0 is:

SF: Detected n25q512 with page size 256 Bytes, erase size 64 KiB, total 
64 MiB 
### ERROR ### Please RESET the board ### 

 i have already tried to use the patches for the uboot code and also to add
more defines before making the uboot, but it still doesn't work for me.

any ideas? thanks ahead.



--
Sent from: http://u-boot.10912.n7.nabble.com/

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Eldor Rødseth]

Hi,

 

I observe a behavior with the QSPI functionality on newer uboot versions; e.g. 2016.11 rc1 and also latest from DENX mainline.

I was wondering whether anyone else has experienced similar issue(s) and can perhaps give hints as to what can cause this.

I will try to narrow down the issue to a couple of examples related to ?sf probe ?? and ?sf read ..?.

I apologize for the long listing, but I am running with full DEBUG for additional details:

 

Example #1:

When issuing ?sf probe? with no parameters; i.e. use defaults, the command fails and causes board reboot:

=> sf probe

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

spi_find_bus_and_cs: No bus 0

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

uclass_find_device_by_seq: 1 0

   - 0 -1

   - found

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

fdtdec_get_int_array: reg

get_prop_check_min_len: reg

fdtdec_get_uint: spi-max-frequency: 0x5f5e100 (100000000)

fdtdec_get_int: page-size: 0x100 (256)

fdtdec_get_int: block-size: 0x10 (16)

fdtdec_get_int: tshsl-ns: 0x32 (50)

fdtdec_get_int: tsd2d-ns: 0x32 (50)

fdtdec_get_int: tchsh-ns: 0x4 (4)

fdtdec_get_int: tslch-ns: 0x4 (4)

fdtdec_get_int: sram-size: 0x80 (128)

cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000 max-frequency=100000000 page-size=256

fdtdec_get_int: spi-max-frequency: (not found)

spi_get_bus_and_cs: Binding new device 'spi_flash at 0:0', busnum=0, cs=0, driver=spi_flash_std

Bound device spi_flash at 0:0 to spi at ff705000

uclass_find_device_by_seq: 0 -1

uclass_find_device_by_seq: 0 0

   - -1 -1

   - not found

spi_flash_std_probe: slave=7bf49e88, cs=0

cadence_qspi_apb_config_baudrate_div: ref_clk 400000000Hz sclk 1000000Hz Div 0xf

cadence_qspi_apb_config_baudrate_div: ref_clk 400000000Hz sclk 100000Hz Div 0xf

SF: Read data capture delay calibrated to 7 (0 - 15)

cadence_spi_set_speed: speed=100000

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=5 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

SF: Got idcodes

00000000: 20 ba 22 10 44                                      .".D

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

fdtdec_get_addr_size_fixed: memory-map: (not found)

spi_flash_decode_fdt: Cannot decode address

SF: Detected MT25QL02 with page size 256 Bytes, erase size 64 KiB, total 256 MiB

cadence_qspi_apb_config_baudrate_div: ref_clk 400000000Hz sclk 1000000Hz Div 0xf

### ERROR ### Please RESET the board ###

 

--------------

 

Example #2:

When issuing ?sf probe <w/params>?; the command apparently succeeds; i.e. correct flash type is detected.

However ? look at Example #3 below.

=> sf probe 0 100000000 3 ? should be identical parameters as read from DTS in Example #1

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

spi_find_bus_and_cs: No bus 0

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

uclass_find_device_by_seq: 1 0

   - 0 -1

   - found

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

fdtdec_get_int_array: reg

get_prop_check_min_len: reg

fdtdec_get_uint: spi-max-frequency: 0x5f5e100 (100000000)

fdtdec_get_int: page-size: 0x100 (256)

fdtdec_get_int: block-size: 0x10 (16)

fdtdec_get_int: tshsl-ns: 0x32 (50)

fdtdec_get_int: tsd2d-ns: 0x32 (50)

fdtdec_get_int: tchsh-ns: 0x4 (4)

fdtdec_get_int: tslch-ns: 0x4 (4)

fdtdec_get_int: sram-size: 0x80 (128)

cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000 max-frequency=100000000 page-size=256

fdtdec_get_int: spi-max-frequency: (not found)

spi_get_bus_and_cs: Binding new device 'spi_flash at 0:0', busnum=0, cs=0, driver=spi_flash_std

Bound device spi_flash at 0:0 to spi at ff705000

uclass_find_device_by_seq: 0 -1

uclass_find_device_by_seq: 0 0

   - -1 -1

   - not found

spi_flash_std_probe: slave=7bf49ec0, cs=0

cadence_qspi_apb_config_baudrate_div: ref_clk 400000000Hz sclk 1000000Hz Div 0xf

cadence_qspi_apb_config_baudrate_div: ref_clk 400000000Hz sclk 100000000Hz Div 0x1

SF: Read data capture delay calibrated to 3 (2 - 4)

cadence_spi_set_speed: speed=100000000

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=5 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

SF: Got idcodes

00000000: 20 ba 22 10 44                                      .".D

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

fdtdec_get_addr_size_fixed: memory-map: (not found)

spi_flash_decode_fdt: Cannot decode address

SF: Detected MT25QL02 with page size 256 Bytes, erase size 64 KiB, total 256 MiB

cadence_spi_set_speed: speed=100000000

spi_get_bus_and_cs: bus=7bf48348, slave=7bf49ec0

=> 

 

------

 

Example #3:

After successful ?sf probe? in Example #2, any ?sf ??? access (except ?sf erase ?.?) causes core dump in uboot:

=> mtdparts

 

---mtdparts_init---

last_ids  : 

env_ids   : <NULL>

last_parts: 

env_parts : <NULL>

 

last_partition : 

env_partition  : <NULL>

mtdids variable not defined, using default

Initial value for argc=3

Final value for argc=3

Initial value for argc=3

Final value for argc=3

 

---parse_mtdids---

mtdids = nor0=ff705000.spi.0

 

+ id nor0              268435456 bytes  ff705000.spi.0

 

---parse_mtdparts---

mtdparts = <NULL>

 

--- current_save ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "partition"

=> partition NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

===device_parse===

--- id_find_by_mtd_id: 'ff705000.spi.0' (len = 14)

entry: 'ff705000.spi.0' (len = 14)

dev type = 1 (nor), dev num = 0, mtd-id = ff705000.spi.0

parsing partitions 256k(spl),512k(u-boot),64k(env1),256k(dtb),8m(lba),32m(lbafs),8m(fpga),128k(script),-(UBI)

+ partition: name spl                    size 0x00040000 offset 0xffffffffffffffff mask flags 0

+ partition: name u-boot                 size 0x00080000 offset 0xffffffffffffffff mask flags 0

+ partition: name env1                   size 0x00010000 offset 0xffffffffffffffff mask flags 0

+ partition: name dtb                    size 0x00040000 offset 0xffffffffffffffff mask flags 0

+ partition: name lba                    size 0x00800000 offset 0xffffffffffffffff mask flags 0

+ partition: name lbafs                  size 0x02000000 offset 0xffffffffffffffff mask flags 0

+ partition: name fpga                   size 0x00800000 offset 0xffffffffffffffff mask flags 0

+ partition: name script                 size 0x00020000 offset 0xffffffffffffffff mask flags 0

'-': remaining size assigned

+ partition: name UBI                    size 0xffffffffffffffff offset 0xffffffffffffffff mask flags 0

 

total partitions: 9

part_sort_add: list empty

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

--- index partitions ---

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevnum"

Initial value for argc=2

Final value for argc=2

hdelete: DELETE key "mtddevname"

=> mtddevnum NULL

=> mtddevname NULL

===

 

+ device: nor   0       ff705000.spi.0

--- current_save ---

Initial value for argc=3

Final value for argc=3

=> partition nor0,0

--- index partitions ---

Initial value for argc=3

Final value for argc=3

 

--- mtd_part_info: partition number 0 for device nor0 (ff705000.spi.0)

Initial value for argc=3

Final value for argc=3

=> mtddevnum 0,

=> mtddevname spl

mtdparts_init: current_mtd_dev  = nor0, current_mtd_partnum = 0

 

---list_partitions---

 

device nor0 <ff705000.spi.0>, # parts = 9

 #: name                size            offset          mask_flags

 0: spl                 0x00040000      0x00000000      0

 1: u-boot              0x00080000      0x00040000      0

 2: env1                0x00010000      0x000c0000      0

 3: dtb                 0x00040000      0x000d0000      0

 4: lba                 0x00800000      0x00110000      0

 5: lbafs               0x02000000      0x00910000      0

 6: fpga                0x00800000      0x02910000      0

 7: script              0x00020000      0x03110000      0

 8: UBI                 0x0ced0000      0x03130000      0

 

--- mtd_part_info: partition number 0 for device nor0 (ff705000.spi.0)

 

active partition: nor0,0 - (spl) 0x00040000 @ 0x00000000

 

defaults:

mtdids  : nor0=ff705000.spi.0

mtdparts: mtdparts=ff705000.spi.0:256k(spl),512k(u-boot),64k(env1),256k(dtb),8m(lba),32m(lbafs),8m(fpga),128k(script),-(UBI)

=> 

=> sf read 100 0 100

device 0 offset 0x0, size 0x100

cadence_spi_xfer: len=5 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=256 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

data abort

pc : [<7ff706c8>]          lr : [<7ff90021>]

reloc pc : [<01027708>]    lr : [<01047061>]

sp : 7bf42c18  ip : 00000000     fp : 00000002

r10: 00000000  r9 : 7bf47ee8     r8 : 7bf483a0

r7 : 0000270f  r6 : 00000100     r5 : 00000100  r4 : 7bf483a0

r3 : 00000008  r2 : 00000001     r1 : 00000100  r0 : ffa00000

Flags: nzCv  IRQs off  FIQs off  Mode SVC_32

Resetting CPU ...

 

resetting ...

 

-------

 

My QSPI is a ?cadence,qspi? compatible device, and I am using the default DTS for socfpga_cyclone5_socdk.dts.

 

Regards,

Eldor Rodseth