All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
@ 2015-09-01  8:41 Jian Luo
  2015-09-01  9:03 ` Marek Vasut
  0 siblings, 1 reply; 8+ messages in thread
From: Jian Luo @ 2015-09-01  8:41 UTC (permalink / raw)
  To: u-boot

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!

-- 

Best regards,

Jian Luo


----
Link and Text of the note:

https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge

Important Note about FPGA/HPS SDRAM Bridge (2013-12-13)

Altera has recently disclosed an implementation requirement related to 
the use of the FPGA to HPS SDRAM bridges. Until more formal technical 
notes are published at Altera, this page will be maintained to outline 
the understood issue for the benefits of MitySOM-5CSX customers.

Configuration of the FPGA to HPS SDRAM (fpga2sdram) AXI bridges involves 
the following major steps:

1.   First, the FPGA ports on the fpga2sdram peripheral must be placed 
in reset. This is accomplished by writing a zero to the FPGAPORTRST 
register in the SDRAM Controller control group.

2.   Second, the FPGA must be configured with an image that includes the 
configuration of the fpga2sdram ports. The FPGA fabric asserts 
configuration input ports at the input to the fpga2sdram bridges. The 
configuration ports affect such things as the width of the port as well 
as the direction, etc. When the FPGA is not configured, these 
configuration inputs are not defined.

3.   Third, once the configuration inputs are set, the configuration 
must be then latched / applied to the fpga2sdram bridge peripheral. This 
is accomplished by writing a one to the APPLYCFG bit in the STATICCFG 
register in the SDRAM Controller control group. This bit can only be 
written to while the SDRAM DDR interface is guaranteed to be completely 
IDLE (including transfers from the ARM cores, DMAs, etc.).

4.   Finally, the FPGA ports on the fpga2sdram peripheral can be taken 
out of reset based on your configuration. This is accomplished by 
writing ones to the appropriate bits in the FPGAPORTRST register in the 
SDRAM Controller control group.

If these steps are not followed, attempting to use an FPGA port on the 
HPS SDRAM bridge controller may result in critical failure -- the HPS 
subsystem may freeze and effectively lock up the processor.

As a consequence to the note bolded in step 3, the fpga2sdram controller 
cannot be practically configured while most high level operating systems 
are running (linux, windows, android, etc.). Altera has provided the 
capability to set the configuration bit in step three with a macro 
command in their (and Critical Link's) u-Boot port. This is accomplished 
by copying a small routine to on-chip RAM that disables caches and 
asserts the APPLYCFG bit and then returns operation to the typical DDR 
space.

Therefor, if you have an FPGA design that utilizes the fpga2sdram 
controller, you must program the FPGA in u-Boot following an FPGA / 
power on reset situation.

Once the SDRAM controller is properly configured, the FPGA ports may be 
reset and enabled (steps 1 and 4) as often as necessary in order to 
facilitate reloading of the FPGA -- as long as the new fpga2sdram port 
configuration matches the original configuration. This will allow for 
reconfiguration of an FPGA while running linux, if necessary.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-01  8:41 [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge Jian Luo
@ 2015-09-01  9:03 ` Marek Vasut
  2015-09-01 11:49   ` Jian Luo
  0 siblings, 1 reply; 8+ messages in thread
From: Marek Vasut @ 2015-09-01  9:03 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-01  9:03 ` Marek Vasut
@ 2015-09-01 11:49   ` Jian Luo
  2015-09-01 12:03     ` Marek Vasut
  0 siblings, 1 reply; 8+ messages in thread
From: Jian Luo @ 2015-09-01 11:49 UTC (permalink / raw)
  To: u-boot

**
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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-01 11:49   ` Jian Luo
@ 2015-09-01 12:03     ` Marek Vasut
  2015-09-01 12:32       ` Jian Luo
  0 siblings, 1 reply; 8+ messages in thread
From: Marek Vasut @ 2015-09-01 12:03 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-01 12:03     ` Marek Vasut
@ 2015-09-01 12:32       ` Jian Luo
  2015-09-02 10:27         ` Marek Vasut
  0 siblings, 1 reply; 8+ messages in thread
From: Jian Luo @ 2015-09-01 12:32 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-01 12:32       ` Jian Luo
@ 2015-09-02 10:27         ` Marek Vasut
  2015-09-02 11:29           ` Jian Luo
  0 siblings, 1 reply; 8+ messages in thread
From: Marek Vasut @ 2015-09-02 10:27 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-02 10:27         ` Marek Vasut
@ 2015-09-02 11:29           ` Jian Luo
  2015-09-02 12:49             ` Marek Vasut
  0 siblings, 1 reply; 8+ messages in thread
From: Jian Luo @ 2015-09-02 11:29 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
  2015-09-02 11:29           ` Jian Luo
@ 2015-09-02 12:49             ` Marek Vasut
  0 siblings, 0 replies; 8+ messages in thread
From: Marek Vasut @ 2015-09-02 12:49 UTC (permalink / raw)
  To: u-boot

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 :)

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-09-02 12:49 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-01  8:41 [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge Jian Luo
2015-09-01  9:03 ` Marek Vasut
2015-09-01 11:49   ` Jian Luo
2015-09-01 12:03     ` Marek Vasut
2015-09-01 12:32       ` Jian Luo
2015-09-02 10:27         ` Marek Vasut
2015-09-02 11:29           ` Jian Luo
2015-09-02 12:49             ` Marek Vasut

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.