arm alignment faults...
Bernd Walter
ticso at cicely7.cicely.de
Mon Jun 30 13:11:59 UTC 2014
On Sun, Jun 29, 2014 at 10:33:59AM -0600, Warner Losh wrote:
>
> On Jun 28, 2014, at 11:40 PM, John-Mark Gurney <jmg at funkthat.com> wrote:
>
> > Warner Losh wrote this message on Sat, Jun 28, 2014 at 22:53 -0600:
> >>
> >> On Jun 28, 2014, at 10:52 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> >>
> >>> On 28 June 2014 21:01, John-Mark Gurney <jmg at funkthat.com> wrote:
> >>>> Adrian Chadd wrote this message on Sat, Jun 28, 2014 at 20:44 -0700:
> >>>>> On 28 June 2014 20:38, John-Mark Gurney <jmg at funkthat.com> wrote:
> >>>>>> So, one of the little projects I'd like to see is the removal of
> >>>>>> ETHER_ALIGN from the tree.. This bogosity can (and does) cause the use
> >>>>>> of bouncing durning DMA ops on all ethernet frames...
> >>>>
> >>>> Now that I think about it, total removal may not be necessary, just
> >>>> the requirement to use it... If the ethernet dma engine can do half
> >>>> word aligned dma, then there would be benifit on those to keep
> >>>> ETHER_ALIGN...
> >>>>
> >>>>> Well, as long as you're not doing it by forcing the various CPUs to
> >>>>> handle unaligned accesses.
> >>>>
> >>>> Hard to do on armv4 which I don't believe supports unaligned access...
> >>>>
> >>>>> The cost of those unaligned accesses on some CPUs that support them is
> >>>>> not trivial. We benchmarked some of the ARM cores at Qualcomm back
> >>>>> when looking to migrate stuff to ARM and it wasn't very quick.
> >>>>
> >>>> I plan on fixing the TCP/IP stack to copy data to an aligned buffer
> >>>> (maybe only if the original buffer isn't aligned) on the stack when
> >>>> __NO_STRICT_ALIGNMENT is not defined... I can't see how copying the
> >>>> entire packet is cheaper than copying 20 bytes or so...
> >>>
> >>> There's lots of other stupid corner cases that screw you.
> >>>
> >>> VLAN headers add extra bytes.
> >>>
> >>> 802.11 headers can offset things depending upon the 802.11 frame type
> >>> (3-addr, 4-addr, vlan, no vlan, etc.)
> >>>
> >>> There's no guarantee all ethernet DMA engines can do the alignment as
> >>> required. :(
> >>
> >> The ate driver for Atmel?s AT91RM9200 is one such beast.
> >
> > Are you sure? The tag for data says alignment 1:
> > if (bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0,
> > BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES,
> > 1, MCLBYTES, 0, busdma_lock_mutex, &sc->sc_mtx, &sc->mtag))
> >
> > Or is that a limitation on the parent?
>
> It is a limitation in hardware. You have to DMA to a 4 byte boundary. That might be a bug in the above line though?
It is a limitation of the AT91RM9200.
More recent ate hardware (e.g. AT91SAM9260) don't have this limitation.
> > I did an audit of the arm drivers (not mips), but I didn't see any that
> > have the restriction... The one that I'm thinking of was the Cirrus
> > EP9302 in the TS-7200 port that I did years ago..
>
--
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
More information about the freebsd-arm
mailing list