Linux hang

Linux hang

[Siegmund, Jan]

Hi all,
does anybody have an idea for the following problem.

* FPGA is programmed using an overlay
* FPGA writes to SDRAM via the FPGA2SDRAM-bridge
* Linux hangs and the watchdog resets the board (the FPGA stays programmed)
* After the reset and boot the FPGA is reprogrammed using the same overlay
* Now, the FPGA can write to the SDRAM without a problem

The environment:

*Board:   DE0-NANO-SoC
*U-Boot: 2017.11
*Kernel:  4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)

The overlay:

/dts-v1/;
/plugin/;

/ {
	fragment@0 {
		target-path = "/soc/base_fpga_region";
		#address-cells = <1>;
		#size-cells = <1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <1>;
			fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
			firmware-name = "foo_base.rbf";

			fpga-bridge@ffc25080 {
				compatible = "altr,socfpga-fpga2sdram-bridge";
				reg = <0xffc25080 0x4>;
				bridge-enable = <1>;
			};

			foo@ff200000 {
				compatible= "altr,bar";
				interrupt-parent = <&intc>;
				interrupts = <0 40 4>;
			};

		};
	};
};

Thanks

WG: Linux hang

[Siegmund, Jan]

Hi all,
does anybody have an idea for the following problem?

* FPGA is programmed using an overlay
* FPGA writes to SDRAM via the FPGA2SDRAM-bridge
* Linux hangs and the watchdog resets the board (the FPGA stays programmed)
* After the reset and boot, the FPGA is reprogrammed using the same overlay
* Now, the FPGA can write to the SDRAM without a problem

The environment:

*Board:�� DE0-NANO-SoC
*U-Boot: 2017.11
*Kernel:� 4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)

The overlay:

/dts-v1/;
/plugin/;

/ {
������� fragment@0 {
��������������� target-path = "/soc/base_fpga_region";
��������������� #address-cells = <1>;
��������������� #size-cells = <1>;
��������������� __overlay__ {
����������������������� #address-cells = <1>;
����������������������� #size-cells = <1>;
����������������������� fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
����������������������� firmware-name = "foo_base.rbf";

����������������������� fpga-bridge@ffc25080 {
������������������������������� compatible = "altr,socfpga-fpga2sdram-bridge";
������������������������������� reg = <0xffc25080 0x4>;
������������������������������� bridge-enable = <1>;
����������������������� };

����������������������� foo@ff200000 {
������������������������������� compatible= "altr,bar";
������������������������������� interrupt-parent = <&intc>;
������������������������������� interrupts = <0 40 4>;
����������������������� };

��������������� };
������� };
};

Thanks

[U-Boot] WG: Linux hang

[Siegmund, Jan]

Hi all,
does anybody have an idea for the following problem?

* FPGA is programmed using an overlay
* FPGA writes to SDRAM via the FPGA2SDRAM-bridge
* Linux hangs and the watchdog resets the board (the FPGA stays programmed)
* After the reset and boot, the FPGA is reprogrammed using the same overlay
* Now, the FPGA can write to the SDRAM without a problem

The environment:

*Board:   DE0-NANO-SoC
*U-Boot: 2017.11
*Kernel:  4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)

The overlay:

/dts-v1/;
/plugin/;

/ {
        fragment at 0 {
                target-path = "/soc/base_fpga_region";
                #address-cells = <1>;
                #size-cells = <1>;
                __overlay__ {
                        #address-cells = <1>;
                        #size-cells = <1>;
                        fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
                        firmware-name = "foo_base.rbf";

                        fpga-bridge at ffc25080 {
                                compatible = "altr,socfpga-fpga2sdram-bridge";
                                reg = <0xffc25080 0x4>;
                                bridge-enable = <1>;
                        };

                        foo at ff200000 {
                                compatible= "altr,bar";
                                interrupt-parent = <&intc>;
                                interrupts = <0 40 4>;
                        };

                };
        };
};

Thanks

AW: Linux hang

[Goldschmidt Simon]

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 2017-12-07 12:01, Siegmund, Jan wrote:
> Hi all,
> does anybody have an idea for the following problem?
>
> * FPGA is programmed using an overlay
> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
> * After the reset and boot, the FPGA is reprogrammed using the same overlay
> * Now, the FPGA can write to the SDRAM without a problem
> [..]

I haven't tried this method of programming the fpga yet (only
programmed from U-Boot for now). But reading the SPL source code, it
seems as the bridges are taken out of reset if the fpga is programmed
when the SPL runs. That's a difference. And it would mean using your
way of programming the fpga, the bridges might still be in reset.

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] Linux hang

[Goldschmidt Simon]

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 2017-12-07 12:01, Siegmund, Jan wrote:
> Hi all,
> does anybody have an idea for the following problem?
>
> * FPGA is programmed using an overlay
> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
> * After the reset and boot, the FPGA is reprogrammed using the same overlay
> * Now, the FPGA can write to the SDRAM without a problem
> [..]

I haven't tried this method of programming the fpga yet (only
programmed from U-Boot for now). But reading the SPL source code, it
seems as the bridges are taken out of reset if the fpga is programmed
when the SPL runs. That's a difference. And it would mean using your
way of programming the fpga, the bridges might still be in reset.

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.

Re: Linux hang

[Alan Tull]

On Thu, Dec 7, 2017 at 5:00 AM, Siegmund, Jan <jan.siegmund0@hm.edu> wrote:

Hi SIegmund,

> Hi all,
> does anybody have an idea for the following problem?
>
> * FPGA is programmed using an overlay
> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
> * After the reset and boot, the FPGA is reprogrammed using the same overlay
> * Now, the FPGA can write to the SDRAM without a problem
>
> The environment:
>
> *Board:   DE0-NANO-SoC
> *U-Boot: 2017.11
> *Kernel:  4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)
>
> The overlay:
>
> /dts-v1/;
> /plugin/;
>
> / {
>         fragment@0 {
>                 target-path = "/soc/base_fpga_region";
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 __overlay__ {
>                         #address-cells = <1>;
>                         #size-cells = <1>;
>                         fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
>                         firmware-name = "foo_base.rbf";
>
>                         fpga-bridge@ffc25080 {
>                                 compatible = "altr,socfpga-fpga2sdram-bridge";
>                                 reg = <0xffc25080 0x4>;
>                                 bridge-enable = <1>;
>                         };

It's been a while since I've touched that bridge, but here's what I
can think of, hope it helps.

This overlay will add the bridge after programming.  It looks like it
should enable it since you have bridge-enable = <1>, so I'm not sure
why that's not working.

Would it make sense to add the f2s bridge before doing the fpga
programming?  You could add the f2s bridge in the base device tree and
add it to your fpga-bridges list so that that bridge is enabled after
the fpga is programmed.

Alan

>
>                         foo@ff200000 {
>                                 compatible= "altr,bar";
>                                 interrupt-parent = <&intc>;
>                                 interrupts = <0 40 4>;
>                         };
>
>                 };
>         };
> };
>
> Thanks--
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[U-Boot] Linux hang

[Alan Tull]

On Thu, Dec 7, 2017 at 5:00 AM, Siegmund, Jan <jan.siegmund0@hm.edu> wrote:

Hi SIegmund,

> Hi all,
> does anybody have an idea for the following problem?
>
> * FPGA is programmed using an overlay
> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
> * After the reset and boot, the FPGA is reprogrammed using the same overlay
> * Now, the FPGA can write to the SDRAM without a problem
>
> The environment:
>
> *Board:   DE0-NANO-SoC
> *U-Boot: 2017.11
> *Kernel:  4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)
>
> The overlay:
>
> /dts-v1/;
> /plugin/;
>
> / {
>         fragment at 0 {
>                 target-path = "/soc/base_fpga_region";
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 __overlay__ {
>                         #address-cells = <1>;
>                         #size-cells = <1>;
>                         fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
>                         firmware-name = "foo_base.rbf";
>
>                         fpga-bridge at ffc25080 {
>                                 compatible = "altr,socfpga-fpga2sdram-bridge";
>                                 reg = <0xffc25080 0x4>;
>                                 bridge-enable = <1>;
>                         };

It's been a while since I've touched that bridge, but here's what I
can think of, hope it helps.

This overlay will add the bridge after programming.  It looks like it
should enable it since you have bridge-enable = <1>, so I'm not sure
why that's not working.

Would it make sense to add the f2s bridge before doing the fpga
programming?  You could add the f2s bridge in the base device tree and
add it to your fpga-bridges list so that that bridge is enabled after
the fpga is programmed.

Alan

>
>                         foo at ff200000 {
>                                 compatible= "altr,bar";
>                                 interrupt-parent = <&intc>;
>                                 interrupts = <0 40 4>;
>                         };
>
>                 };
>         };
> };
>
> Thanks--
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [U-Boot] Linux hang

[Jan Siegmund]

Am 07.12.2017 um 15:01 schrieb Goldschmidt Simon:
> On 2017-12-07 12:01, Siegmund, Jan wrote:
>> Hi all,
>> does anybody have an idea for the following problem?
>>
>> * FPGA is programmed using an overlay
>> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>> * After the reset and boot, the FPGA is reprogrammed using the same overlay
>> * Now, the FPGA can write to the SDRAM without a problem
>> [..]
> 
> I haven't tried this method of programming the fpga yet (only
> programmed from U-Boot for now). But reading the SPL source code, it
> seems as the bridges are taken out of reset if the fpga is programmed
> when the SPL runs. That's a difference. And it would mean using your
> way of programming the fpga, the bridges might still be in reset.

Usually, the bridges specified in the DT Overlay are automatically 
disabled before programming and re-enabled after it. I can also write
to the lwHPS2FPGA bridge and the FPGA accepts the data, so I don't
consider this to be the problem. Besides, I am using the FPGA-to-SDRAM 
interface directly connected to the SDRAM subsystem of the HPS 
(https://www.altera.com/documentation/sfo1410143707420.html#sfo1410067640997) 
and the resets are only targeting lwHPS2FPGA, HPS2FPGA and FPGA2HPS.
But your idea could go in the right direction, because some registers 
are set differently, when the FPGA is already in user mode.

Thanks,
Jan

> Regards,
> Simon

[U-Boot] Linux hang

[Jan Siegmund]

Am 07.12.2017 um 15:01 schrieb Goldschmidt Simon:
> On 2017-12-07 12:01, Siegmund, Jan wrote:
>> Hi all,
>> does anybody have an idea for the following problem?
>>
>> * FPGA is programmed using an overlay
>> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>> * After the reset and boot, the FPGA is reprogrammed using the same overlay
>> * Now, the FPGA can write to the SDRAM without a problem
>> [..]
> 
> I haven't tried this method of programming the fpga yet (only
> programmed from U-Boot for now). But reading the SPL source code, it
> seems as the bridges are taken out of reset if the fpga is programmed
> when the SPL runs. That's a difference. And it would mean using your
> way of programming the fpga, the bridges might still be in reset.

Usually, the bridges specified in the DT Overlay are automatically 
disabled before programming and re-enabled after it. I can also write
to the lwHPS2FPGA bridge and the FPGA accepts the data, so I don't
consider this to be the problem. Besides, I am using the FPGA-to-SDRAM 
interface directly connected to the SDRAM subsystem of the HPS 
(https://www.altera.com/documentation/sfo1410143707420.html#sfo1410067640997) 
and the resets are only targeting lwHPS2FPGA, HPS2FPGA and FPGA2HPS.
But your idea could go in the right direction, because some registers 
are set differently, when the FPGA is already in user mode.

Thanks,
Jan

> Regards,
> Simon

Re: Linux hang

[Jan Siegmund]

Am 07.12.2017 um 20:19 schrieb Alan Tull:
> On Thu, Dec 7, 2017 at 5:00 AM, Siegmund, Jan <jan.siegmund0@hm.edu> wrote:
> 
> Hi SIegmund,
> 
>> Hi all,
>> does anybody have an idea for the following problem?
>>
>> * FPGA is programmed using an overlay
>> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>> * After the reset and boot, the FPGA is reprogrammed using the same overlay
>> * Now, the FPGA can write to the SDRAM without a problem
>>
>> The environment:
>>
>> *Board:   DE0-NANO-SoC
>> *U-Boot: 2017.11
>> *Kernel:  4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)
>>
>> The overlay:
>>
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>>          fragment@0 {
>>                  target-path = "/soc/base_fpga_region";
>>                  #address-cells = <1>;
>>                  #size-cells = <1>;
>>                  __overlay__ {
>>                          #address-cells = <1>;
>>                          #size-cells = <1>;
>>                          fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
>>                          firmware-name = "foo_base.rbf";
>>
>>                          fpga-bridge@ffc25080 {
>>                                  compatible = "altr,socfpga-fpga2sdram-bridge";
>>                                  reg = <0xffc25080 0x4>;
>>                                  bridge-enable = <1>;
>>                          };
> 
> It's been a while since I've touched that bridge, but here's what I
> can think of, hope it helps.
> 
> This overlay will add the bridge after programming.  It looks like it
> should enable it since you have bridge-enable = <1>, so I'm not sure
> why that's not working.
> 
> Would it make sense to add the f2s bridge before doing the fpga
> programming?  You could add the f2s bridge in the base device tree and
> add it to your fpga-bridges list so that that bridge is enabled after
> the fpga is programmed.

Hi Alan,
this might be worth a try.

Thanks,
Jan

> 
> Alan
> 
>>
>>                          foo@ff200000 {
>>                                  compatible= "altr,bar";
>>                                  interrupt-parent = <&intc>;
>>                                  interrupts = <0 40 4>;
>>                          };
>>
>>                  };
>>          };
>> };
>>
>> Thanks
> 

[U-Boot] Linux hang

[Jan Siegmund]

Am 07.12.2017 um 20:19 schrieb Alan Tull:
> On Thu, Dec 7, 2017 at 5:00 AM, Siegmund, Jan <jan.siegmund0@hm.edu> wrote:
> 
> Hi SIegmund,
> 
>> Hi all,
>> does anybody have an idea for the following problem?
>>
>> * FPGA is programmed using an overlay
>> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>> * After the reset and boot, the FPGA is reprogrammed using the same overlay
>> * Now, the FPGA can write to the SDRAM without a problem
>>
>> The environment:
>>
>> *Board:   DE0-NANO-SoC
>> *U-Boot: 2017.11
>> *Kernel:  4.14.0-rc7 (review-v4.14-rc7-non-dt-support-v5.1 branch)
>>
>> The overlay:
>>
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>>          fragment at 0 {
>>                  target-path = "/soc/base_fpga_region";
>>                  #address-cells = <1>;
>>                  #size-cells = <1>;
>>                  __overlay__ {
>>                          #address-cells = <1>;
>>                          #size-cells = <1>;
>>                          fpga-bridges = <&fpga_bridge0 &fpga_bridge1>;
>>                          firmware-name = "foo_base.rbf";
>>
>>                          fpga-bridge at ffc25080 {
>>                                  compatible = "altr,socfpga-fpga2sdram-bridge";
>>                                  reg = <0xffc25080 0x4>;
>>                                  bridge-enable = <1>;
>>                          };
> 
> It's been a while since I've touched that bridge, but here's what I
> can think of, hope it helps.
> 
> This overlay will add the bridge after programming.  It looks like it
> should enable it since you have bridge-enable = <1>, so I'm not sure
> why that's not working.
> 
> Would it make sense to add the f2s bridge before doing the fpga
> programming?  You could add the f2s bridge in the base device tree and
> add it to your fpga-bridges list so that that bridge is enabled after
> the fpga is programmed.

Hi Alan,
this might be worth a try.

Thanks,
Jan

> 
> Alan
> 
>>
>>                          foo at ff200000 {
>>                                  compatible= "altr,bar";
>>                                  interrupt-parent = <&intc>;
>>                                  interrupts = <0 40 4>;
>>                          };
>>
>>                  };
>>          };
>> };
>>
>> Thanks
> 

Re: Linux hang

[Anatolij Gustschin]

Hi,

On Wed, 6 Dec 2017 17:02:07 +0000
Siegmund, Jan jan.siegmund0@hm.edu wrote:

>Hi all,
>does anybody have an idea for the following problem.
>
>* FPGA is programmed using an overlay
>* FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>* Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>* After the reset and boot the FPGA is reprogrammed using the same overlay
>* Now, the FPGA can write to the SDRAM without a problem

Probably because configuration of the FPGA2SDRAM-bridge is different than
other bridges. There is an important step needed, setting APPLYCFG bit in
the STATICCFG register [1]. But this must be done when the DDR interface
is idle (no DRAM transfer from ARM-core or DMA) which is not the case when
Linux is running. Therefore, if you have designs that use fpga2sdram, you
have to program the FPGA under U-Boot. U-Boot fpga command runs APPLYCFG
setting code from OCRAM.

Anatolij

[1] https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge

Re: Linux hang

[Jan Siegmund]

Am 08.12.2017 um 14:52 schrieb Anatolij Gustschin:
> Hi,
> 
> On Wed, 6 Dec 2017 17:02:07 +0000
> Siegmund, Jan jan.siegmund0@hm.edu wrote:
> 
>> Hi all,
>> does anybody have an idea for the following problem.
>>
>> * FPGA is programmed using an overlay
>> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>> * After the reset and boot the FPGA is reprogrammed using the same overlay
>> * Now, the FPGA can write to the SDRAM without a problem
> 
> Probably because configuration of the FPGA2SDRAM-bridge is different than
> other bridges. There is an important step needed, setting APPLYCFG bit in
> the STATICCFG register [1]. But this must be done when the DDR interface
> is idle (no DRAM transfer from ARM-core or DMA) which is not the case when
> Linux is running. Therefore, if you have designs that use fpga2sdram, you
> have to program the FPGA under U-Boot. U-Boot fpga command runs APPLYCFG
> setting code from OCRAM.

Thanks, this has helped me a lot. But there was still something
missing. First, the FPGA needs to be programmed in U-Boot using the 
'fpga' command. Then 'bridge enable' has to be called. This command
does not only get the lwHPS2FPGA, HPS2FPGA and FPGA2HPS bridges out of 
reset, but also applies the SDRAM config, like you described.
Now, my SDRAM-to-FPGA interface works fine.

Regards,
Jan

> 
> Anatolij
> 
> [1] https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge
> 

[U-Boot] Linux hang

[Jan Siegmund]

Am 08.12.2017 um 14:52 schrieb Anatolij Gustschin:
> Hi,
> 
> On Wed, 6 Dec 2017 17:02:07 +0000
> Siegmund, Jan jan.siegmund0 at hm.edu wrote:
> 
>> Hi all,
>> does anybody have an idea for the following problem.
>>
>> * FPGA is programmed using an overlay
>> * FPGA writes to SDRAM via the FPGA2SDRAM-bridge
>> * Linux hangs and the watchdog resets the board (the FPGA stays programmed)
>> * After the reset and boot the FPGA is reprogrammed using the same overlay
>> * Now, the FPGA can write to the SDRAM without a problem
> 
> Probably because configuration of the FPGA2SDRAM-bridge is different than
> other bridges. There is an important step needed, setting APPLYCFG bit in
> the STATICCFG register [1]. But this must be done when the DDR interface
> is idle (no DRAM transfer from ARM-core or DMA) which is not the case when
> Linux is running. Therefore, if you have designs that use fpga2sdram, you
> have to program the FPGA under U-Boot. U-Boot fpga command runs APPLYCFG
> setting code from OCRAM.

Thanks, this has helped me a lot. But there was still something
missing. First, the FPGA needs to be programmed in U-Boot using the 
'fpga' command. Then 'bridge enable' has to be called. This command
does not only get the lwHPS2FPGA, HPS2FPGA and FPGA2HPS bridges out of 
reset, but also applies the SDRAM config, like you described.
Now, my SDRAM-to-FPGA interface works fine.

Regards,
Jan

> 
> Anatolij
> 
> [1] https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge
>