| Message ID | 03387b53-b517-0d54-a620-71ce39c4e903@aries-embedded.de |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg() | expand |
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. > , 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?
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. >> , 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
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 exchange where the suggestion was to make this apply_static_cfg optional and only use it when the DRAM port is enabled in the quartus design. Maybe that is the way out of this ?
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! > exchange where the suggestion was to make this apply_static_cfg optional > and only use it when the DRAM port is enabled in the quartus design. > Maybe that is the way out of this ? Yep. Wolfgang
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 ? >> exchange where the suggestion was to make this apply_static_cfg optional >> and only use it when the DRAM port is enabled in the quartus design. >> Maybe that is the way out of this ? > > Yep. [...]
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. >>> exchange where the suggestion was to make this apply_static_cfg optional >>> and only use it when the DRAM port is enabled in the quartus design. >>> Maybe that is the way out of this ? >> >> Yep. > > [...] Wolfgang
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.
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? >>> , 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. > Dinh
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? 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
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
> -----Original Message----- > From: Marek Vasut <marex@denx.de> > Sent: Friday, August 7, 2020 7:53 PM > To: Wolfgang Grandegger <wg@aries-embedded.de>; U-Boot Mailing List > <u-boot@lists.denx.de> > Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>; Nguyen, Dinh > <dinh.nguyen@intel.com>; Tan, Ley Foon <ley.foon.tan@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
Hello Ley Foon, Am 10.08.20 um 10:30 schrieb Tan, Ley Foon: > > >> -----Original Message----- >> From: Marek Vasut <marex@denx.de> >> Sent: Friday, August 7, 2020 7:53 PM >> To: Wolfgang Grandegger <wg@aries-embedded.de>; U-Boot Mailing List >> <u-boot@lists.denx.de> >> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>; Nguyen, Dinh >> <dinh.nguyen@intel.com>; Tan, Ley Foon <ley.foon.tan@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
Hi Wolfgang et al., On Fri, Aug 07, 2020 at 05:49:13PM +0200, Wolfgang Grandegger wrote: > > >Am 07.08.20 um 17:05 schrieb Dinh Nguyen: >> >> 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. Just a note that I am seeing the same problem, also on Cyclone V, but with a different IP block in the FPGA. I'm using the Altera/Intel triple speed Ethernet, which is supported by drivers/net/altera_tse.c driver. With earlier u-boot (tested 2018.03) it worked fine. But with 2020.04 and 2020.07 the system hangs as soon as I do "ifconfig eth0 up". This only happens on cold boot; on warm reboot the eth0 port works fine. Reverting c5f4b805755912a3d2fe20 fixes the problem. Regards, Ralph
On 8/19/20 8:35 PM, Ralph Siemsen wrote: > Hi Wolfgang et al., > > On Fri, Aug 07, 2020 at 05:49:13PM +0200, Wolfgang Grandegger wrote: >> >> >> Am 07.08.20 um 17:05 schrieb Dinh Nguyen: >>> >>> 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. > > Just a note that I am seeing the same problem, also on Cyclone V, but > with a different IP block in the FPGA. I'm using the Altera/Intel triple > speed Ethernet, which is supported by drivers/net/altera_tse.c driver. > > With earlier u-boot (tested 2018.03) it worked fine. But with 2020.04 > and 2020.07 the system hangs as soon as I do "ifconfig eth0 up". This > only happens on cold boot; on warm reboot the eth0 port works fine. > Reverting c5f4b805755912a3d2fe20 fixes the problem. Is the F2SDRAM port enabled in your case ?
On Wed, Aug 19, 2020 at 09:28:39PM +0200, Marek Vasut wrote: > >Is the F2SDRAM port enabled in your case ? Is there a way I can check this via software? Unfortunately I do not have access to Quartus/Qsys files, nor the person who did the design. Ralph
Hello, Am 19.08.20 um 21:54 schrieb Ralph Siemsen: > On Wed, Aug 19, 2020 at 09:28:39PM +0200, Marek Vasut wrote: >> >> Is the F2SDRAM port enabled in your case ? > > Is there a way I can check this via software? Unfortunately I do not > have access to Quartus/Qsys files, nor the person who did the design. Looking to the U-Boot driver "drivers/net/altera_tse.c" tells me, that it maps system memory for the SGDMA controller in its probe function. I found the Altera SoC Triple Speed Ethernet Design Example at [1]. And yes, it seems to use F2SDRAM as well. [1] https://rocketboards.org/foswiki/Projects/AlteraSoCTripleSpeedEthernetDesignExample Wolfgang
diff --git a/arch/arm/mach-socfpga/misc_gen5.c b/arch/arm/mach-socfpga/misc_gen5.c index 7209e8d..c1ecd92 100644 --- a/arch/arm/mach-socfpga/misc_gen5.c +++ b/arch/arm/mach-socfpga/misc_gen5.c @@ -216,6 +216,35 @@ int arch_early_init_r(void) static struct socfpga_sdr_ctrl *sdr_ctrl = (struct socfpga_sdr_ctrl *)SDR_CTRLGRP_ADDRESS; +static void socfpga_sdram_apply_static_cfg(void) +{ + const u32 applymask = 0x8; + u32 val = readl(&sdr_ctrl->static_cfg) | applymask; + + /* + * SDRAM staticcfg register specific: + * When applying the register setting, the CPU must not access + * SDRAM. Luckily for us, we can abuse i-cache here to help us + * circumvent the SDRAM access issue. The idea is to make sure + * that the code is in one full i-cache line by branching past + * it and back. Once it is in the i-cache, we execute the core + * of the code and apply the register settings. + * + * The code below uses 7 instructions, while the Cortex-A9 has + * 32-byte cachelines, thus the limit is 8 instructions total. + */ + asm volatile( + ".align 5 \n" + " b 2f \n" + "1: str %0, [%1] \n" + " dsb \n" + " isb \n" + " b 3f \n" + "2: b 1b \n" + "3: nop \n" + : : "r"(val), "r"(&sdr_ctrl->static_cfg) : "memory", "cc"); +} + void do_bridge_reset(int enable, unsigned int mask) { int i; @@ -233,6 +262,7 @@ void do_bridge_reset(int enable, unsigned int mask) writel(iswgrp_handoff[2], socfpga_get_sysmgr_addr() + SYSMGR_GEN5_FPGAINFGRP_MODULE); + socfpga_sdram_apply_static_cfg(); writel(iswgrp_handoff[3], &sdr_ctrl->fpgaport_rst); writel(iswgrp_handoff[0], socfpga_get_rstmgr_addr() + RSTMGR_GEN5_BRGMODRST); @@ -245,6 +275,7 @@ void do_bridge_reset(int enable, unsigned int mask) writel(0, socfpga_get_sysmgr_addr() + SYSMGR_GEN5_FPGAINFGRP_MODULE); writel(0, &sdr_ctrl->fpgaport_rst); + socfpga_sdram_apply_static_cfg(); writel(0x7, socfpga_get_rstmgr_addr() + RSTMGR_GEN5_BRGMODRST); writel(1, &nic301_regs->remap); }
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), but only after a power cycle (cold boot). The issue does not show up after a soft reset (warm boot) and with v2018.11. Signed-off-by: Wolfgang Grandegger <wg@aries-embedded.de> CC: Marek Vasut <marex@denx.de> CC: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> --- arch/arm/mach-socfpga/misc_gen5.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)