Patch for ticket #2990

[Linda Huxley]

Here is the patch requested by Chris.  (Hopefully you can use this 
patch.  I really don't know what I'm doing.)


Regards,

Linda

diff -u /a/rtems/config/tools/rtems-arm-gcc-4.9.3-newlib-2.2.0-20150423-1.cfg 
/b/rtems/config/tools/rtems-arm-gcc-4.9.3-newlib-2.2.0-20150423-1.cfg
--- /a/rtems/config/tools/rtems-arm-gcc-4.9.3-newlib-2.2.0-20150423-1.cfg   
2017-04-12 16:42:00.0 -0600
+++ /b/rtems/config/tools/rtems-arm-gcc-4.9.3-newlib-2.2.0-20150423-1.cfg   
2017-04-21 02:46:40.198427200 -0600
@@ -12,6 +12,12 @@
 %hash sha512 newlib-ARM-Optimize-IEEE-754-sqrt-implementation.diff 
1bfdbd4a052eb42d559f430644de44943d524c22ed83c6ebf522659bfb3046535fd5bb28bd2866a47146210cad0afff1aa5cccba1bf503b2609eb05409b61734
 
 #
+# Fix for MSYS2 on Windows. See ticket #2990 for details.
+#
+%patch add gcc -p1 
https://devel.rtems.org/raw-attachment/ticket/2990/gcc-4.9.3-20170404-1.patch
+%hash  sha512 gcc-4.9.3-20170404-1.patch 
c6402e578793e39869d0f3ba021922794e8ea30595286f63cbc9d32c5cb9ef1d9bb3be28f2a9127077d62a44f425f9c0685e3c22596aed67837fe2fcf8a09e71
+
+#
 # The gcc/newlib build instructions.
 #
 %include tools/rtems-gcc-4.9-newlib-2.2.0-1.cfg
___
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 2/2] bsp/xilinx-zynq: Add device configuration driver

[Patrick Gauvin]

On Thu, Apr 20, 2017 at 7:41 PM, Chris Johns  wrote:

> On 21/04/2017 07:52, Patrick Gauvin wrote:
>
>> Chris,
>>
>>
>> +
>> +static drvdata data;
>> +/* TODO: Abstract DMA buffer retrieval better */
>>
>>
>> Agreed.
>>
>>
>> +static uint8_t *dma_buf = NULL;
>> +
>> +/* Check if bit is set in reg (and not masked by mask), and if
>> it is, write
>> + * that bit to reg, returning true. Otherwise return false.
>> + */
>> +static inline bool check_and_set(
>> +  volatile uint32_t *reg,
>> +  uint32_t   mask,
>> +  uint32_t   bit
>> +)
>> +{
>> +  if ( *reg & bit & ~mask )
>> +  {
>> +*reg = bit;
>> +return true;
>> +  }
>> +  return false;
>> +}
>> +
>> +/* Only one semaphore is used since only one interrupt is
>> unmasked at a time.
>> + * The interrupt is cleared and masked after it is caught here.
>> + */
>> +static void zynq_devcfg_isr(
>> +  void *args
>> +)
>>
>>
>> Why are you wanting to use interrupts rather than a simple sleep and
>> poll? I am ok with a sychronous read/write driver interface here.
>>
>> Do we need interrupts and the complexity they have here when loading
>> the fabric is so critical to any other part of a system and must be
>> done early?
>>
>>
>> I moved to interrupts since I wanted a way to implement timeouts that
>> allowed the driver to continue as soon as an operation completes. This
>> is mostly to benefit applications that will read from and write to the
>> PCAP during operation, after the bitstream is initially loaded, like an
>> FPGA scrubber.
>>
>
> Thanks, this makes sense if time is important. I assume you want to scrub
> the fabric without resorting to a reset?
>
> Would it make sense to provide an ioctl to scrub the fabric and to verify
> it? It would seem like a useful function other users may need.
>
> In terms of the RTEMS implementation, I find event send and receive is
> simpler with a low overhead not needing to allocate a semaphore. The
> interrupt checks a task id variable and if not 0 sends an event and the
> receive blocks on the receive.
>
>
A scrub ioctl does make sense, however, there are various methods for
performing scrubbing, and I don't think my lab will let me release the one
we use publicly.

Ah, thank you. Events sound much better suited for this, I'll replace the
semaphore with that.


> +  int_sts = regs->int_sts;
>> +  if (
>> +ZYNQ_DEVCFG_INT_AXI_WERR_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_AXI_RTO_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_AXI_RERR_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_RX_FIFO_OV_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_DMA_CMD_ERR_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_DMA_Q_OV_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_P2D_LEN_ERR_INT_GET( int_sts )
>> +|| ZYNQ_DEVCFG_INT_PCFG_HMAC_ERR_INT_GET( int_sts )
>> +  )
>> +return -2;
>> +
>> +  return 0;
>> +}
>> +
>> +/**
>> + * @brief Configure the PCAP controller.
>> + */
>> +static void pl_init(
>> +  volatile zynq_devcfg_regs *regs
>> +)
>> +{
>> +  regs->ctrl = ZYNQ_DEVCFG_CTRL_PCAP_MODE( 1 ) |
>> +  ZYNQ_DEVCFG_CTRL_PCAP_PR( ZYNQ_DEVCFG_CTRL_PCAP_PR_PCAP ) |
>> +  ZYNQ_DEVCFG_CTRL_RESERVED_BITS | regs->ctrl;
>> +  /* Disable loopback */
>> +  regs->mctrl = ZYNQ_DEVCFG_MCTRL_SET(
>> +regs->mctrl,
>> +~ZYNQ_DEVCFG_MCTRL_INT_PCAP_LPBK( 1 ) & regs->mctrl
>> +  );
>> +  /* Clear all interrupts */
>> +  regs->int_sts = ZYNQ_DEVCFG_INT_ALL;
>> +
>> +  if ( !data.secure )
>> +  {
>> +if ( ZYNQ_DEVCFG_CTRL_QUARTER_PCAP_RATE_EN( regs->ctrl ) )
>> +  regs->ctrl = ( ~ZYNQ_DEVCFG_CTRL_QUARTER_PCAP_RATE_EN( 1
>> ) & regs->ctrl )
>> +  | ZYNQ_DEVCFG_CTRL_RESERVED_BITS;
>> +  }
>> +  else
>> +  {
>> +if ( !ZYNQ_DEVCFG_CTRL_QUARTER_PCAP_RATE_EN( regs->ctrl ) )
>> +  regs->ctrl = ZYNQ_DEVCFG_CTRL_QUARTER_PCAP_RATE_EN( 1 ) |
>> regs->ctrl
>> +  | ZYNQ_DEVCFG_CTRL_RESERVED_BITS;
>>
>>
>> Have you tested secure loading?
>>
>>
>> No, I have not yet.
>>
>>
> I am fine with this waiting until after the code has been merged. I can
> then help sort out secure loading. It is tricky to handle as you need a
> suitable key embedded in the device and that means a battery for the BBRAM
> to avoid needing to blow fuses. I have custom boards I can test this on.


Thanks, this does sound like it will take some time. I do have a board with
the eFUSE blown, so I shou