MIPS questions

[gregory.menke at gsfc.nasa.gov]

Jay Monkman writes:
 > On Fri, Oct 24, 2003 at 05:57:16PM -0400, gregory.menke at gsfc.nasa.gov wrote:
 > 
 > > The 2 byte offset seems a common optimization to put the ip header on
 > > a paragraph boundary- Linux people do it in drivers sometimes.  gcc is
 > > <supposed> to be handling alignment, but whatever the mbuff stuff is
 > > doing might be sneaking around it.  Could you give an example line #
 > > so I can look at it directly?
 > 
 > REASS_MBUF is defined on line 236 in tcp_var.h
 >    #define REASS_MBUF(ti) (*(struct mbuf **)&((ti)->ti_t))
 > 
 > In tcp_input.c, around line 207, is 
 >    REASS_MBUF(ti) = m; 
 > and around line 232, is
 >    m = REASS_MBUF((struct tcpiphdr *)q->ti_prev);
 > 
 > Since there's a lot of pointer manipulation going on, gcc has no way
 > to ensure alignment, unless you want to make it check every pointer
 > access, which would cause awful performance. I believe that if you can
 > guarantee 4 byte alignment on the IP packet, this won't be a
 > problem. However if the IP packet is not 4 byte aligned, this is a
 > problem, unless there's some MIPS magic to handle misaligned accesses.

This may be specific to your variant of mips.  We've been in the
middle of a bunch of grunt work on some updated Mongoose5 boards
(R3000), there byte and word aligned memory I/O works fine.  

Someone more experienced with the stack may have to help out with mbuf
related alignment issues- I've not been into that corner of things.

Do you know if theres a gcc option to force dword aligned memory I/O,
which implicitely invokes the horrible read/modify/write shifting
magic necessary to support it?


 > I can make this go away by using the same fix that was used on ARM,
 > but if the other MIPS BSPs don't have this problem, I'd like to use
 > their method. Are the other MIPS network drivers able to ensure the IP
 > packet is aligned?

I've not tested any network drivers on MIPS bsp's, mostly because I
don't have any RTEMS-supported mips hardware that also has an ethernet
chip on it.  The Sonic chip is often present on MIPS boards (or at
least the demo boards around here), but we've not brought up RTEMS on
any of them yet.  Our Mongoose boards were spec'ed for Sonic chips
which were were cut from the design to save money way back when...

 
 > > This is R4000 code, which is in a lightly tested state right now.  You
 > > should pay particular attention to anything interrupt-enabled, all the
 > > interrupt level set/get functions for example.
 > 
 > Without the extra parentheses, I fail the SP14 regression test, since
 > it messes up CP0's status register. (It works fine on the jmr3904
 > simulator, but that uses different code). When I add the parens, SP14
 > passes. 

As long as the effect matches what the last posting achieved- the
intent is to set up a default SR if the user does not select an
interrupt level, but impose whatever the user supplies otherwise.  The
interrupt level byte is imposed on the SR register interrupt enables,
so it acts as a bit-wise mask, thats what the <<9 is for.  If 0, all
interrupts are enabled.

Gregm