Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Wolfgang Grandegger]

Hello,

reading you question again...

Am 07.08.20 um 17:49 schrieb Wolfgang Grandegger:
> 
> 
> Am 07.08.20 um 17:05 schrieb Dinh Nguyen:
>> CC Hean Loong:
>>
>>
>> On 8/6/20 7:36 AM, 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:
>>>
>>> https://github.com/altera-opensource/linux-socfpga/blob/socfpga-5.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.
>>>
>>
>> Can you elaborate what you mean here? You are starting the Frame Buffer
>> driver with U-Boot?

You ask how to start the frame-buffer in U-Boot. Here are the commands:

  => fpga load 0 ${loadaddr} ${filesize}
  => bridge enable
  => mw.l 0xffc25080 0x00003fff
  => mw.l 0xffc2508c 0x00000000
  => mw.l 0xffc25090 0x00000000
  => mw.b 0xbef00000 0xff 0x5dc00
  => mw.b 0xbef5dc00 0x00 0x5dc00
  => mw.b 0xbefbb800 0x80 0x5dc00
  => mw.l 0xff280214 0x006401e0
  => mw.l 0xff280218 0xbef00000
  => mw.l 0xff280200 1

It fills the framebuffer at 0xbef00000 and starts the streaming with
the last command.

> Yes, the FPGA image provides the Intel Video and Image Processing(VIP)
> Frame Buffer II IP core and it is loaded with "> fpga load ..." in
> U-Boot before Linux starts. And yes, this IP core does use the DRAM
> bridge (F2S).



> The systems hangs, if I start the framebuffer in U-Boot or Linux, but
> only after a power-cycle. It works fine after a soft-reset.
> 
>>>>> , 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.
>>>

Wolfgang