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