* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
@ 2020-08-06 10:53 Wolfgang Grandegger
2020-08-06 11:04 ` Marek Vasut
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-06 10:53 UTC (permalink / raw)
To: u-boot
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);
}
--
1.9.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-06 10:53 Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg() Wolfgang Grandegger
@ 2020-08-06 11:04 ` Marek Vasut
2020-08-06 12:36 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2020-08-06 11:04 UTC (permalink / raw)
To: u-boot
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-06 11:04 ` Marek Vasut
@ 2020-08-06 12:36 ` Wolfgang Grandegger
2020-08-06 12:50 ` Marek Vasut
2020-08-07 15:05 ` Dinh Nguyen
0 siblings, 2 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-06 12:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-06 12:36 ` Wolfgang Grandegger
@ 2020-08-06 12:50 ` Marek Vasut
2020-08-07 10:58 ` Wolfgang Grandegger
2020-08-07 15:05 ` Dinh Nguyen
1 sibling, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2020-08-06 12:50 UTC (permalink / raw)
To: u-boot
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 ?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-06 12:50 ` Marek Vasut
@ 2020-08-07 10:58 ` Wolfgang Grandegger
2020-08-07 11:12 ` Marek Vasut
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-07 10:58 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 10:58 ` Wolfgang Grandegger
@ 2020-08-07 11:12 ` Marek Vasut
2020-08-07 11:22 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2020-08-07 11:12 UTC (permalink / raw)
To: u-boot
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.
[...]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 11:12 ` Marek Vasut
@ 2020-08-07 11:22 ` Wolfgang Grandegger
2020-08-07 11:53 ` Marek Vasut
0 siblings, 1 reply; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-07 11:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 11:22 ` Wolfgang Grandegger
@ 2020-08-07 11:53 ` Marek Vasut
2020-08-10 8:30 ` Tan, Ley Foon
0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2020-08-07 11:53 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-06 12:36 ` Wolfgang Grandegger
2020-08-06 12:50 ` Marek Vasut
@ 2020-08-07 15:05 ` Dinh Nguyen
2020-08-07 15:49 ` Wolfgang Grandegger
1 sibling, 1 reply; 17+ messages in thread
From: Dinh Nguyen @ 2020-08-07 15:05 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 15:05 ` Dinh Nguyen
@ 2020-08-07 15:49 ` Wolfgang Grandegger
2020-08-07 15:57 ` Wolfgang Grandegger
2020-08-19 18:35 ` Ralph Siemsen
0 siblings, 2 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-07 15:49 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 15:49 ` Wolfgang Grandegger
@ 2020-08-07 15:57 ` Wolfgang Grandegger
2020-08-19 18:35 ` Ralph Siemsen
1 sibling, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-07 15:57 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 11:53 ` Marek Vasut
@ 2020-08-10 8:30 ` Tan, Ley Foon
2020-08-10 12:11 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Tan, Ley Foon @ 2020-08-10 8:30 UTC (permalink / raw)
To: u-boot
> -----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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-10 8:30 ` Tan, Ley Foon
@ 2020-08-10 12:11 ` Wolfgang Grandegger
0 siblings, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-10 12:11 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-07 15:49 ` Wolfgang Grandegger
2020-08-07 15:57 ` Wolfgang Grandegger
@ 2020-08-19 18:35 ` Ralph Siemsen
2020-08-19 19:28 ` Marek Vasut
1 sibling, 1 reply; 17+ messages in thread
From: Ralph Siemsen @ 2020-08-19 18:35 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-19 18:35 ` Ralph Siemsen
@ 2020-08-19 19:28 ` Marek Vasut
2020-08-19 19:54 ` Ralph Siemsen
0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2020-08-19 19:28 UTC (permalink / raw)
To: u-boot
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 ?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-19 19:28 ` Marek Vasut
@ 2020-08-19 19:54 ` Ralph Siemsen
2020-08-20 8:35 ` Wolfgang Grandegger
0 siblings, 1 reply; 17+ messages in thread
From: Ralph Siemsen @ 2020-08-19 19:54 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
2020-08-19 19:54 ` Ralph Siemsen
@ 2020-08-20 8:35 ` Wolfgang Grandegger
0 siblings, 0 replies; 17+ messages in thread
From: Wolfgang Grandegger @ 2020-08-20 8:35 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-08-20 8:35 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-06 10:53 Revert "ARM: socfpga: Remove socfpga_sdram_apply_static_cfg() Wolfgang Grandegger
2020-08-06 11:04 ` Marek Vasut
2020-08-06 12:36 ` Wolfgang Grandegger
2020-08-06 12:50 ` Marek Vasut
2020-08-07 10:58 ` Wolfgang Grandegger
2020-08-07 11:12 ` Marek Vasut
2020-08-07 11:22 ` Wolfgang Grandegger
2020-08-07 11:53 ` Marek Vasut
2020-08-10 8:30 ` Tan, Ley Foon
2020-08-10 12:11 ` Wolfgang Grandegger
2020-08-07 15:05 ` Dinh Nguyen
2020-08-07 15:49 ` Wolfgang Grandegger
2020-08-07 15:57 ` Wolfgang Grandegger
2020-08-19 18:35 ` Ralph Siemsen
2020-08-19 19:28 ` Marek Vasut
2020-08-19 19:54 ` Ralph Siemsen
2020-08-20 8:35 ` Wolfgang Grandegger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.