Zynq BSP progress

[Claus, Ric]

If anyone is still trying to help solve this issue, thanks, but you can stop.  When I RTFM enough times, I finally start to understand bits and pieces of what is being said.  In this case, there is a Network Configuration register with which one can tell the DMA engine to offset where it deposits the data by 0 to 3 bytes from the beginning of the buffer.  Probably not something that should be done on a per frame basis, though.  I now have a truly working Network Driver.

Ric


On Apr 15, 2013, at 9:31 AM, Claus, Ric wrote:

> No, no padding that I can find.  Yes, I agree, that is the main problem.  Once I changed the 4 to a 2, the driver works.  This is true for both 4.11 and 4.10.2.  Since ip.h is not RTEMS code, I wonder whether that code is considered patchable.
> 
> Ric
> 
> ________________________________________
> From: Sebastian Huber [sebastian.huber at embedded-brains.de]
> Sent: Monday, April 15, 2013 12:14 AM
> To: Claus, Ric
> Cc: rtems-devel at rtems.org
> Subject: Re: Zynq BSP progress
> 
> On 04/12/2013 06:18 PM, Claus, Ric wrote:
>> Thanks, Sebastian.  I did do exactly that initially, but as I tried to explain, the DMA engine uses the lower two address bits for other things.  I therefore can't put m->m_data on a 16 bit word boundary.  So then what?
> 
> Oh, this is bad.  Supports the DMA engine some padding?  I think the main
> problem is in ip.h the struct ip { ... } aligned(4).  I would remove the
> aligned(4) and try if that works.
> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel