Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

Wolfgang Grandegger wg at
Mon Aug 10 14:11:38 CEST 2020

Hello Ley Foon,

Am 10.08.20 um 10:30 schrieb Tan, Ley Foon:
>> -----Original Message-----
>> From: Marek Vasut <marex at>
>> Sent: Friday, August 7, 2020 7:53 PM
>> To: Wolfgang Grandegger <wg at>; U-Boot Mailing List
>> <u-boot at>
>> Cc: Simon Goldschmidt <simon.k.r.goldschmidt at>; Nguyen, Dinh
>> <dinh.nguyen at>; Tan, Ley Foon <ley.foon.tan at>
>> Subject: Re: Revert "ARM: socfpga: Remove
>> socfpga_sdram_apply_static_cfg()
>> On 8/7/20 1:22 PM, Wolfgang Grandegger wrote:
>>> Am 07.08.20 um 13:12 schrieb Marek Vasut:
>>>> On 8/7/20 12:58 PM, Wolfgang Grandegger wrote:
>>>>> Am 06.08.20 um 14:50 schrieb Marek Vasut:
>>>>>> On 8/6/20 2:36 PM, Wolfgang Grandegger wrote:
>>>>>>> Am 06.08.20 um 13:04 schrieb Marek Vasut:
>>>>>>>> On 8/6/20 12:53 PM, Wolfgang Grandegger wrote:
>>>>>>>>> This reverts commit
>> c5f4b805755912a3d2fe20f014b6b6ab0473bd73.
>>>>>>>>> Conflicts:
>>>>>>>>> 	arch/arm/mach-socfpga/misc_gen5.c
>>>>>>>>> Without socfpga_sdram_apply_static_cfg(), the system hangs when
>>>>>>>>> Linux calls altvipfb2_start_hw() of the Intel Video and Image
>>>>>>>>> Processing(VIP) Frame Buffer II driver
>>>>>>>>> (drivers/video/fbdev/altvipfb2.c)
>>>>>>>> There is no such driver in mainline U-Boot or Linux.
>>>>>>> It's a simple frame buffer driver from linux-socfpga for the IP
>>>>>>> core Intel Video and Image Processing(VIP) Frame Buffer II. It
>>>>>>> actually hangs here when the streaming starts:
>>>>>>> 4.44-lts/drivers/video/fbdev/altvipfb2.c#L69
>>>>>>> I can also hang the system if I setup and start the FB with just a
>>>>>>> few U-Boot commands. I think the system hangs when the IP core
>>>>>>> starts reading the FB data from the system memory.
>>>>>> I am CCing Dinh , I recall there was some discussion about hangs on
>>>>>> CycloneV and it was fixed recently.
>>>>>>>>> , but only
>>>>>>>>> after a power cycle (cold boot). The issue does not show up
>>>>>>>>> after a soft reset (warm boot) and with v2018.11.
>>>>>>>> See the commit message of the patch this is reverting, I believe
>>>>>>>> there is a deeper issue with the static config register. Can you
>> investigate?
>>>>>>> I read the commit message, but well, I can't follow all the details :(.
>>>>>>> On the other hand, it seems also not clear why the fix was added.
>>>>>>> Any idea what to investigate.
>>>>>> The system was repeatedly rebooted in a loop, the FPGA was loaded
>>>>>> before Linux booted. After hundreds of reboots, the system got
>>>>>> stuck on setting up the static cfg register. I think there was even
>>>>>> another email
>>>>> I rebooted Linux on my MCVEVP more than 100 times with and without
>>>>> loading the FPGA in U-Boot. The system never hang!
>>>> It could very well be bitstream related, wait for Simon to chime in.
>>>> Do you load the bitstream in U-Boot or in Linux ?
>>> I load it in U-Boot. And I repeated the test more than 1000 times (100
>>> above is a typo)! OK, let's wait for more input.
>> Sorry for pushing back on this, the issue keeps coming back and until we get
>> to the bottom of this, I don't want to see applying and reverting a patch back
>> and forth. And getting to the real bottom of this seems to be particularly
>> difficult task.
>> Does your bitstream use the DRAM bridge (F2S) ? I think it does. The one I
>> used didn't as far as I remember. So maybe the way forward is to only apply
>> static cfg if the bridge is enabled.
> We have another email thread before about restore back socfpga_sdram_apply_static_cfg() function.
> Yes, we talked about only apply static cfg bit if the F2S port is enabled. But, no final decision previously. 
> I can re-submit the patches if you are okay with this approach.
> Wolfgang,
> I have downstream patches for checking F2S port before apply static cfg bit. Can you try these 2 patches on your side if they solve your issue?
> I can't reproduce the issue on my side. 

No, this does not fix the problem with my hardware because handoff[3] is

do_bridge_reset: handoff[0..5]: 0x0 0x19 0x0 0x0 0xf 0x0


More information about the U-Boot mailing list