Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
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(+)
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); }
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/d...
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/d...
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/d...
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/d...
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/d...
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/d...
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.
-----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/ca64e19e40224091b... https://github.com/altera-opensource/u-boot-socfpga/commit/11ff7b9ce3abc5e61...
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/ca64e19e40224091b... https://github.com/altera-opensource/u-boot-socfpga/commit/11ff7b9ce3abc5e61...
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
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/d...
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/d...
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/d...
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
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 ?
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/AlteraSoCTripleSpeedEthernetDesign...
Wolfgang
participants (5)
-
Dinh Nguyen -
Marek Vasut -
Ralph Siemsen -
Tan, Ley Foon -
Wolfgang Grandegger