Hello Ley Foon, Am 10.08.20 um 10:30 schrieb Tan, Ley Foon: > > >> -----Original Message----- >> From: Marek Vasut <ma...@denx.de> >> Sent: Friday, August 7, 2020 7:53 PM >> To: Wolfgang Grandegger <w...@aries-embedded.de>; U-Boot Mailing List >> <u-boot@lists.denx.de> >> Cc: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com>; Nguyen, Dinh >> <dinh.ngu...@intel.com>; Tan, Ley Foon <ley.foon....@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 >
No, this does not fix the problem with my hardware because handoff[3] is zero: do_bridge_reset: handoff[0..5]: 0x0 0x19 0x0 0x0 0xf 0x0 Wolfgang