Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

Tan, Ley Foon ley.foon.tan at intel.com
Mon Aug 10 10:30:59 CEST 2020



> -----Original Message-----
> From: Marek Vasut <marex at denx.de>
> Sent: Friday, August 7, 2020 7:53 PM
> To: Wolfgang Grandegger <wg at aries-embedded.de>; U-Boot Mailing List
> <u-boot at lists.denx.de>
> Cc: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>; Nguyen, Dinh
> <dinh.nguyen at intel.com>; Tan, Ley Foon <ley.foon.tan at intel.com>
> 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:
> >>>>>
> >>>>> 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.
> >>>>
> >>>> 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. 
https://github.com/altera-opensource/u-boot-socfpga/commit/ca64e19e40224091b7f57b63ddd7ea9cdc6e8d44
https://github.com/altera-opensource/u-boot-socfpga/commit/11ff7b9ce3abc5e61f44997a017b175c371eeee9 

Regards
Ley Foon




More information about the U-Boot mailing list