Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Chris Johns]

On 22/04/2017 01:44, Patrick Gauvin wrote:

I'll plan on storing a few bitfiles for common platforms, like the
MicroZed (7Z010) and the ZedBoard (7Z020), with the test. I do have a
simple bitfile, but it currently targets the ZedBoard. If you'd like, I
can send a version for the MicroZed when I send the updated patches next
week (should I attach it to the mailing list? I'm not sure what the
etiquette is for large attachments).


Send me the files directly and I can upload them to the ftp server. We 
can figure out how to integrate them into the build after that.



I worry about the processing system initialization (such as FCLK
frequency) being mismatched with the bitstream.


I have code to control some of the clocks and set them. Further to this 
for a project I have been adding pre and post load metadata to a bitfile 
wrapper to manage this issue. The pre-load metadata can hold 
configurations that update the Zynq before a load, for example FCLK. 
This moves the role of the FSBL initialise to being a default and for 
example specific bitfiles can be built at different AXI clock speeds. In 
the case of the Zedboard you could have a bitfile that has a completely 
difference set up to the Zedboard's default.



I think the SDK
generates a GPLed FSBL source now, so maybe including that will do.


I do not think the SDK FSBL is GPL. It use to be restrictive but I think 
recent versions have a better license. I have not checked lately.



If
there is an alternative I'd love to hear it, I dislike being tied to the
SDK for initialization.


I prefer to have no dependency on the SDK because of the complexity it 
creates, for example the FPGA team want a later release because it is a 
faster or better build, while the matching SDK break software, or the 
compiler is broken, or some other reason.


The only solutions I know of are the SDK, uboot or some code I have. My 
solution needs some work to make public.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Pavel Pisa]

Hello Chris, Patrick and others,

I am sending pointers to some of our Zynq work which can be used
for test designs.

On Friday 21 of April 2017 00:37:16 Chris Johns wrote:
> On 21/04/2017 07:55, Patrick Gauvin wrote:
> > Gedare,
> >
> >
> > if the test programs are specific to the Zynq BSP, then we don't
> > currently have a very good mechanism for maintaining them. Probably
> > submitting them as "example programs" in the
> > git.rtems.org/examples-v2.git 
> > is the best place to look at integrating
> > application/bsp-level tests. This is an area in need of longer-term
> > solutions.
> >
> >
> > OK, I will plan on putting them there.
>
> What happens with bitfiles? For example I have a MicroZed with a 7Z010
> and I am not sure what a Zedboard has?
>
> Do you have a simple bitfile we can load?
>
> A bitfile that is not secured can compress well. Once this driver is in
> RTEMS it would be nice to add another layer to load compressed files.

There is some set of peripherals available and tested on Xilinx MicroZed
which is used from our group at Czech Technical University projects

  http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git

The master branch add two SJA1000 CAN controllers and routes integrated
ones to the interfaces on CAN benchmaring setup with MicroZed.

The "microzed_apo" branch adds some LEDs, knobs etc connected over
SPI, more PWM modulators for RC servos, simple audio etc

  
http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo

The project is interesting that it uses PetaLinux base and we have
carefully selected set of files which have to be distributed
and versioned in GIT and which can be regenerated by build.
Project is not perfect but much better than when everything
is stored in the GIT.

Some IPs for peripherals which we use

  
http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo:/system/ip

educational ones have been writted in a hurry to finish before start
of the semester so they are not perfect. But woking.
I have examples to add additional UARTs etc as well.

There are constrain files for MicroZed with CAN bench board
and educational kit

  
http://rtime.felk.cvut.cz/gitweb/fpga/zynq/canbench-sw.git/tree/refs/heads/microzed_apo:/system/src/constrs

The schematic diagrams and photos of our design can be found
in the directory

  http://cmp.felk.cvut.cz/~pisa/apo/mz_apo/

I have archived/published some U-boot patches and
my local build configuration for U-Boot, Linux
and RTEMS can be found there

  https://github.com/ppisa/zynq-rt-utils-and-builds

But RTEMS config is dated, I have tested RTEMS on Zynq
during last summer.

The presentation of real-time PMSM/BLDC for both Raspberry Pi and MicroZed
targets can be found there

  http://cmp.felk.cvut.cz/~pisa/installfest/linux_and_fpga_in_rt_control.pdf

I have interrest to prepare RTEMS one one day as well. I have some
RTEMS RPi DC motor one with video in English already but the sound
and language quality is bad so I am not decided if I should publish
it or wait for some rare moment when I find time to dub it better
myself or find somebody who is better English language gifted.

Best wishes,

Pavel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Patrick Gauvin]

I'll plan on storing a few bitfiles for common platforms, like the MicroZed
(7Z010) and the ZedBoard (7Z020), with the test. I do have a simple
bitfile, but it currently targets the ZedBoard. If you'd like, I can send a
version for the MicroZed when I send the updated patches next week (should
I attach it to the mailing list? I'm not sure what the etiquette is for
large attachments).

I worry about the processing system initialization (such as FCLK frequency)
being mismatched with the bitstream. I think the SDK generates a GPLed FSBL
source now, so maybe including that will do. If there is an alternative I'd
love to hear it, I dislike being tied to the SDK for initialization.

-Patrick

On Thu, Apr 20, 2017 at 6:37 PM, Chris Johns  wrote:

> On 21/04/2017 07:55, Patrick Gauvin wrote:
>
>> Gedare,
>>
>>
>> if the test programs are specific to the Zynq BSP, then we don't
>> currently have a very good mechanism for maintaining them. Probably
>> submitting them as "example programs" in the
>> git.rtems.org/examples-v2.git 
>> is the best place to look at integrating
>> application/bsp-level tests. This is an area in need of longer-term
>> solutions.
>>
>>
>> OK, I will plan on putting them there.
>>
>>
> What happens with bitfiles? For example I have a MicroZed with a 7Z010 and
> I am not sure what a Zedboard has?
>
> Do you have a simple bitfile we can load?
>
> A bitfile that is not secured can compress well. Once this driver is in
> RTEMS it would be nice to add another layer to load compressed files.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Chris Johns]

On 21/04/2017 07:55, Patrick Gauvin wrote:

Gedare,


if the test programs are specific to the Zynq BSP, then we don't
currently have a very good mechanism for maintaining them. Probably
submitting them as "example programs" in the
git.rtems.org/examples-v2.git 
is the best place to look at integrating
application/bsp-level tests. This is an area in need of longer-term
solutions.


OK, I will plan on putting them there.



What happens with bitfiles? For example I have a MicroZed with a 7Z010 
and I am not sure what a Zedboard has?


Do you have a simple bitfile we can load?

A bitfile that is not secured can compress well. Once this driver is in 
RTEMS it would be nice to add another layer to load compressed files.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Patrick Gauvin]

Gedare,


> if the test programs are specific to the Zynq BSP, then we don't
> currently have a very good mechanism for maintaining them. Probably
> submitting them as "example programs" in the
> git.rtems.org/examples-v2.git is the best place to look at integrating
> application/bsp-level tests. This is an area in need of longer-term
> solutions.
>

OK, I will plan on putting them there.

Thanks,

Patrick
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Gedare Bloom]

On Wed, Apr 19, 2017 at 11:06 PM, Patrick Gauvin  wrote:
> Hello,
>
> I'm submitting this device configuration driver to be reviewed and
> hopefully to be accepted into the RTEMS source tree. In its current state, it
> is able to send PCAP command sequences, successfully program the FPGA, and
> also use the PCAP to read internal registers.
>
> The SLCR patch is only for the pieces used during FPGA configuration (level
> shifter control and clock resets).
>
> I've tried to mimic the Doxygen usage found in the Zynq BSP, please let me
> know if I missed anything or should elaborate more.
>
> I intend to merge the test programs into the tree as well, but have not had
> the time yet. The platform I have been using to test is the ZedBoard.
>
if the test programs are specific to the Zynq BSP, then we don't
currently have a very good mechanism for maintaining them. Probably
submitting them as "example programs" in the
git.rtems.org/examples-v2.git is the best place to look at integrating
application/bsp-level tests. This is an area in need of longer-term
solutions.

> Thank you,
>
> Patrick
>
> Patrick Gauvin (2):
>   bsp/xilinx-zynq: Add SLCR driver
>   bsp/xilinx-zynq: Add device configuration driver
>
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |  10 +
>  .../libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c| 770 
> +
>  .../arm/xilinx-zynq/include/zynq-devcfg-regs.h | 194 ++
>  .../libbsp/arm/xilinx-zynq/include/zynq-devcfg.h   | 160 +
>  .../arm/xilinx-zynq/include/zynq-slcr-regs.h   |  84 +++
>  .../lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h |  70 ++
>  c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |  16 +
>  c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c  |  90 +++
>  8 files changed, 1394 insertions(+)
>  create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
>  create mode 100644 
> c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg-regs.h
>  create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg.h
>  create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
>  create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h
>  create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c
>
> --
> 2.7.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/2] Zynq7000 series device configuration driver

[Patrick Gauvin]

Hello,

I'm submitting this device configuration driver to be reviewed and
hopefully to be accepted into the RTEMS source tree. In its current state, it
is able to send PCAP command sequences, successfully program the FPGA, and
also use the PCAP to read internal registers.

The SLCR patch is only for the pieces used during FPGA configuration (level
shifter control and clock resets).

I've tried to mimic the Doxygen usage found in the Zynq BSP, please let me
know if I missed anything or should elaborate more.

I intend to merge the test programs into the tree as well, but have not had
the time yet. The platform I have been using to test is the ZedBoard.

Thank you,

Patrick

Patrick Gauvin (2):
  bsp/xilinx-zynq: Add SLCR driver
  bsp/xilinx-zynq: Add device configuration driver

 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |  10 +
 .../libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c| 770 +
 .../arm/xilinx-zynq/include/zynq-devcfg-regs.h | 194 ++
 .../libbsp/arm/xilinx-zynq/include/zynq-devcfg.h   | 160 +
 .../arm/xilinx-zynq/include/zynq-slcr-regs.h   |  84 +++
 .../lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h |  70 ++
 c/src/lib/libbsp/arm/xilinx-zynq/preinstall.am |  16 +
 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c  |  90 +++
 8 files changed, 1394 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/devcfg/zynq-devcfg.c
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-devcfg.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr-regs.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/include/zynq-slcr.h
 create mode 100644 c/src/lib/libbsp/arm/xilinx-zynq/slcr/zynq-slcr.c

-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel