All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Siegmund <jan.siegmund0@hm.edu>
To: Anatolij Gustschin <agust@denx.de>
Cc: "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
	"u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Re: Linux hang
Date: Mon, 11 Dec 2017 17:23:08 +0100	[thread overview]
Message-ID: <759ae2df-e12f-859a-2a5d-dff32489ace8@hm.edu> (raw)
In-Reply-To: <20171208145230.36cce190@crub>

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
> 

WARNING: multiple messages have this Message-ID (diff)
From: Jan Siegmund <jan.siegmund0@hm.edu>
To: u-boot@lists.denx.de
Subject: [U-Boot] Linux hang
Date: Mon, 11 Dec 2017 17:23:08 +0100	[thread overview]
Message-ID: <759ae2df-e12f-859a-2a5d-dff32489ace8@hm.edu> (raw)
In-Reply-To: <20171208145230.36cce190@crub>

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
> 

  reply	other threads:[~2017-12-11 16:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 17:02 Linux hang Siegmund, Jan
2017-12-07 11:00 ` WG: " Siegmund, Jan
2017-12-07 11:00   ` [U-Boot] " Siegmund, Jan
2017-12-07 14:01   ` AW: " Goldschmidt Simon
2017-12-07 14:01     ` [U-Boot] " Goldschmidt Simon
2017-12-07 19:58     ` Jan Siegmund
2017-12-07 19:58       ` Jan Siegmund
2017-12-07 19:19   ` Alan Tull
2017-12-07 19:19     ` [U-Boot] " Alan Tull
2017-12-07 20:14     ` Jan Siegmund
2017-12-07 20:14       ` [U-Boot] " Jan Siegmund
2017-12-08 13:52 ` Anatolij Gustschin
2017-12-11 16:23   ` Jan Siegmund [this message]
2017-12-11 16:23     ` [U-Boot] " Jan Siegmund

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=759ae2df-e12f-859a-2a5d-dff32489ace8@hm.edu \
    --to=jan.siegmund0@hm.edu \
    --cc=agust@denx.de \
    --cc=linux-fpga@vger.kernel.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.