[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fpga
Subject:    Re: [U-Boot] Linux hang
From:       Jan Siegmund <jan.siegmund0 () hm ! edu>
Date:       2017-12-07 19:58:19
Message-ID: d4b1fd6b-4c10-231c-1246-a1469dabd554 () hm ! edu
[Download RAW message or body]

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


--
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
[prev in list] [next in list] [prev in thread] [next in thread]