[U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge

Hi!
I've read about an implementation requirement regarding the usage of FPGA/HPS SDRAM bridge. (Link and Text attached at the end.)
The 3. step involves writing the APPLYCFG bit in the STATICCFG register while the SDRAM interface is completely IDLE. IMHO, it's only possible in SPL stage where everything runs in SRAM. FPGA however can not be configured until U-Boot is ready (step 2). So warm reset should be performed after FPGA configuration.
My idea is to patch sdram.c to dynamically write FPGAPORTRST and APPLYCFG based on information in sysmgr_regs->romcodegrp_bootromswstate.
Is any one working on this?
Thanks!

On Tuesday, September 01, 2015 at 10:41:31 AM, Jian Luo wrote:
Hi!
Hi,
I've read about an implementation requirement regarding the usage of FPGA/HPS SDRAM bridge. (Link and Text attached at the end.)
The 3. step involves writing the APPLYCFG bit in the STATICCFG register while the SDRAM interface is completely IDLE. IMHO, it's only possible in SPL stage where everything runs in SRAM. FPGA however can not be configured until U-Boot is ready (step 2). So warm reset should be performed after FPGA configuration.
My idea is to patch sdram.c to dynamically write FPGAPORTRST and APPLYCFG based on information in sysmgr_regs->romcodegrp_bootromswstate.
Is any one working on this?
We do this sort of stuff by running code from cache, see socfpga_sdram_apply_static_cfg() in arch/arm/mach-socfpga/misc.c .
You want to use the "bridge enable" and "bridge disable" commands to enable/disable the bridges between FPGA and HPS in U-Boot.
Hope that helps ;-)
Best regards, Marek Vasut

** Hi Marek,
On 01.09.2015 11:03, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 10:41:31 AM, Jian Luo wrote:
Hi!
Hi,
I've read about an implementation requirement regarding the usage of FPGA/HPS SDRAM bridge. (Link and Text attached at the end.)
The 3. step involves writing the APPLYCFG bit in the STATICCFG register while the SDRAM interface is completely IDLE. IMHO, it's only possible in SPL stage where everything runs in SRAM. FPGA however can not be configured until U-Boot is ready (step 2). So warm reset should be performed after FPGA configuration.
My idea is to patch sdram.c to dynamically write FPGAPORTRST and APPLYCFG based on information in sysmgr_regs->romcodegrp_bootromswstate.
Is any one working on this?
We do this sort of stuff by running code from cache, see socfpga_sdram_apply_static_cfg() in arch/arm/mach-socfpga/misc.c .
Thanks. It's way better than run bootloader twice!
You want to use the "bridge enable" and "bridge disable" commands to enable/disable the bridges between FPGA and HPS in U-Boot.
What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic? socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used?
Hope that helps ;-)
Best regards, Marek Vasut

On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote:
** Hi Marek,
Hi!
On 01.09.2015 11:03, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 10:41:31 AM, Jian Luo wrote:
Hi!
Hi,
I've read about an implementation requirement regarding the usage of FPGA/HPS SDRAM bridge. (Link and Text attached at the end.)
The 3. step involves writing the APPLYCFG bit in the STATICCFG register while the SDRAM interface is completely IDLE. IMHO, it's only possible in SPL stage where everything runs in SRAM. FPGA however can not be configured until U-Boot is ready (step 2). So warm reset should be performed after FPGA configuration.
My idea is to patch sdram.c to dynamically write FPGAPORTRST and APPLYCFG based on information in sysmgr_regs->romcodegrp_bootromswstate.
Is any one working on this?
We do this sort of stuff by running code from cache, see socfpga_sdram_apply_static_cfg() in arch/arm/mach-socfpga/misc.c .
Thanks. It's way better than run bootloader twice!
Yeah :)
You want to use the "bridge enable" and "bridge disable" commands to enable/disable the bridges between FPGA and HPS in U-Boot.
What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic?
Which code exactly do you refer to ?
socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used?
The idea is to keep the FPGA programming code and the code which controls the bridges separate. The reason for that is that you can have content in the FPGA which is running completely independent of the HPS software. You don't always need to enable the bridges.
The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff like framebuffers implemented in the FPGA, so that the FPGA can fetch data from the SDRAM.
Best regards, Marek Vasut

Hi Marek,
On 01.09.2015 14:03, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote:
----snip----
What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic?
Which code exactly do you refer to ?
I mean something like this.
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 4448250..d0f67f6 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) return status;
/* Ensure the FPGA entering user mode */ - return fpgamgr_program_poll_usermode(); + status = fpgamgr_program_poll_usermode(); + if (status) + return status; + + /* Latch FPGA2SDRAM bridge configuration */ + socfpga_sdram_apply_static_cfg(); + + return 0; }
socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used?
The idea is to keep the FPGA programming code and the code which controls the bridges separate. The reason for that is that you can have content in the FPGA which is running completely independent of the HPS software. You don't always need to enable the bridges.
No, it's the other way around here. socfpga_load() runs eventually when command "fpga load" is called. So when I explicitly use "fpga load" command, the old FPGA program is expected to stop running, right?
And I don't want to enable the bridge here, just to latch the SDRAM configuration.
The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff like framebuffers implemented in the FPGA, so that the FPGA can fetch data from the SDRAM.
Best regards, Marek Vasut
Best regards,
Jian Luo

On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote:
Hi Marek,
Hi!
On 01.09.2015 14:03, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote:
----snip----
What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic?
Which code exactly do you refer to ?
I mean something like this.
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 4448250..d0f67f6 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) return status;
/* Ensure the FPGA entering user mode */
return fpgamgr_program_poll_usermode();
status = fpgamgr_program_poll_usermode();
if (status)
return status;
/* Latch FPGA2SDRAM bridge configuration */
socfpga_sdram_apply_static_cfg();
}return 0;
socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used?
The idea is to keep the FPGA programming code and the code which controls the bridges separate. The reason for that is that you can have content in the FPGA which is running completely independent of the HPS software. You don't always need to enable the bridges.
No, it's the other way around here. socfpga_load() runs eventually when command "fpga load" is called. So when I explicitly use "fpga load" command, the old FPGA program is expected to stop running, right?
Right
And I don't want to enable the bridge here, just to latch the SDRAM configuration.
So what you want to do is "bridge disable ; fpga load ... ; bridge enable", isn't that the correct sequence ? I might be missing something though, sorry.
The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff like framebuffers implemented in the FPGA, so that the FPGA can fetch data from the SDRAM.
Best regards, Marek Vasut
Best regards,
Jian Luo
Best regards, Marek Vasut

Hi Marek,
On 02.09.2015 12:27, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote:
Hi Marek,
Hi!
On 01.09.2015 14:03, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote:
----snip----
What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic?
Which code exactly do you refer to ?
I mean something like this.
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 4448250..d0f67f6 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) return status;
/* Ensure the FPGA entering user mode */
return fpgamgr_program_poll_usermode();
status = fpgamgr_program_poll_usermode();
if (status)
return status;
/* Latch FPGA2SDRAM bridge configuration */
socfpga_sdram_apply_static_cfg();
}return 0;
socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used?
The idea is to keep the FPGA programming code and the code which controls the bridges separate. The reason for that is that you
can have
content in the FPGA which is running completely independent of
the HPS
software. You don't always need to enable the bridges.
No, it's the other way around here. socfpga_load() runs eventually when command "fpga load" is called. So when I explicitly use "fpga load" command, the old FPGA program is expected to stop running, right?
Right
And I don't want to enable the bridge here, just to latch the SDRAM configuration.
So what you want to do is "bridge disable ; fpga load ... ; bridge
enable",
isn't that the correct sequence ? I might be missing something
though, sorry.
No, you are right. Sorry, I didn't think it through.
My original thought was, that "fpga load" should not depend on "bridge e/d" regardless of how fpga2sdram is configured. Now I think the dependency is a bad idea. Sorry for the confusion.
The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for
stuff
like framebuffers implemented in the FPGA, so that the FPGA can fetch data from the SDRAM.
Best regards, Marek Vasut
Best regards,
Jian Luo
Best regards, Marek Vasut
Best regards,
Jian Luo

On Wednesday, September 02, 2015 at 01:29:36 PM, Jian Luo wrote:
Hi Marek,
Hi!
On 02.09.2015 12:27, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote:
Hi Marek,
Hi!
On 01.09.2015 14:03, Marek Vasut wrote:
On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote:
----snip----
What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic?
Which code exactly do you refer to ?
I mean something like this.
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 4448250..d0f67f6 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size)
return status; /* Ensure the FPGA entering user mode */
return fpgamgr_program_poll_usermode();
status = fpgamgr_program_poll_usermode();
if (status)
return status;
/* Latch FPGA2SDRAM bridge configuration */
socfpga_sdram_apply_static_cfg();
return 0;
}
socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used?
The idea is to keep the FPGA programming code and the code which controls the bridges separate. The reason for that is that you
can have
content in the FPGA which is running completely independent of
the HPS
software. You don't always need to enable the bridges.
No, it's the other way around here. socfpga_load() runs eventually when command "fpga load" is called. So when I explicitly use "fpga load" command, the old FPGA program is expected to stop running, right?
Right
And I don't want to enable the bridge here, just to latch the SDRAM configuration.
So what you want to do is "bridge disable ; fpga load ... ; bridge
enable",
isn't that the correct sequence ? I might be missing something
though, sorry.
No, you are right. Sorry, I didn't think it through.
My original thought was, that "fpga load" should not depend on "bridge e/d" regardless of how fpga2sdram is configured. Now I think the dependency is a bad idea.
Yeah, you should be able to control the bridges between the FPGA and the FPGA loading independently for the particular case where the FPGA runs independently of the HPS.
Sorry for the confusion.
Well, I'm glad it got sorted out :)
participants (2)
-
Jian Luo
-
Marek Vasut