[Avila] IXP425/Avila 2348 issue, processor reading memory incorrectly

[Beng Tan]

------_=_NextPart_001_01C72E22.26F1660E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,=20

> Converting random char *s to pointers to structures with variables =
larger
> than a char is a bad thing! =20

I agree. I only did so to duplicate how the dhcp-isc dhcpd application =
does things (which is where I originally uncovered this problem).=20

Anyway, I've resolved the issue. Turns out that the IXP4xx will fault on =
misaligned data accesses - which is reasonable enough.=20

What wasn't previously clear is that uClinux for arm has an inbuilt =
memory alignment exception handler which defaults to trapping alignment =
exceptions and then ignoring them.=20

Hence, in my test app, the handler catches the exception and does =
nothing, and my app continues running, but with incorrect data.=20

Once I configure the exception handler to fix up misaligned accesses =
(via echo 2 > /proc/cpu/alignment), the test app runs correctly.=20

Thanks,
Beng

-----Original Message-----
From: David Acker [mailto:dacker at roinet.com]
Sent: Sat 12/30/2006 12:26 PM
To: 'Avila'
Subject: RE: [Avila] IXP425/Avila 2348 issue, processor reading memory =
incorrectly=20
=20
Converting random char *s to pointers to structures with variables =
larger
than a char is a bad thing!  On most platforms you get either a major
performance penalty, a crash, or some data that is different from what =
you
expect.  Make sure that the pointer to your structure is aligned =
properly
for your processor.  I believe that you need to start on 4 byte boundary =
on
the avilas.  This isn't a compiler bug as much as a processor =
limitation.
-Ack

  _____ =20

From: Beng Tan [mailto:beng.tan at calyptech.com]=20
Sent: Wednesday, December 27, 2006 12:28 AM
To: avila at lists.unixstudios.net
Subject: [Avila] IXP425/Avila 2348 issue, processor reading memory
incorrectly=20

Hi,

Just wondering, has anyone encountered the problem I have described =
below?

Anyone wanna do a quick test for me?

Thanks,
Beng Tan

-----Original Message-----
From: Beng Tan
Sent: Wed 12/27/2006 4:24 PM
To: support at gateworks.com
Subject: [Avila] IXP425/Avila 2348 issue, processor reading memory incorrectly
Subject: [Avila] Hi,

I am encountering an issue whereby an indexed memory access into a =
structure
variable is giving me incorrect results. Instead of reading the desired
member field, the processor seems to read the memory location 4 bytes
before.

This seems to be more of a processor problem than a compiler problem.

I have created a test case which produces this error condition for me =
all
the time. The C file and an assembled output are attached. Build command
line and sample program output are below.

My platform is:

IXP425 on Gateworks Avila 2348
Snapgear-Avila Distribution 0.6
Toolchain: arm-linux-tools-20051123.tar.gz (gcc 3.4.4) from =
snapgear-3.3.0
Library: I am using uClibc, which I doubt has any relation to the issue

The command line invoked by make to build is:

ucfront-gcc arm-linux-gcc -mbig-endian -msoft-float -O2 -fno-common
-fno-builtin -Wall  -Dlinux -D__linux__ -Dunix  -DEMBED -S aslasr.c -o
aslasr.s
ucfront-gcc arm-linux-gcc -mbig-endian -msoft-float -O2 -fno-common
-fno-builtin -Wall  -Dlinux -D__linux__ -Dunix  -DEMBED -c aslasr.s -o
aslasr.o
ucfront-gcc arm-linux-gcc -mbig-endian -msoft-float -g -fno-common
-fno-builtin aslasr.o -o aslasr

Please note when I compile with no optimisations (ie. -O0), I don't get =
the
problem. This is NOT an acceptable workaround, because some other =
software
in the future may be compiled to a similar assembly sequence which =
triggers
the problem.

The output I get executing on the 2348 board is

# ./aslasr
dump at dummy: 0x34 56
s->offset2 is 0x5a5a
cast_assigned is 0x3456

dump at dummy: 0x34 56
s->offset2 is 0x3456
cast_assigned is 0x3456

As you can see, in the first paragraph, s->offset2 is read as 0x5a5a =
when it
should be 0x3456. It seems to be related to how the processor is =
accessing
memory. The use of "asl #16, asl #16" assembly sequences may be a clue, =
or
simply a coincidence.

While my development environment may not be exactly the same as yours, =
the
symptoms indicate a generic IXP425 issue which should be somewhat
independent of library, toolchain etc. At the least, I would like to =
know
whether you are able to reproduce the issue on your system.

Thank you,
Beng Tan

------_=_NextPart_001_01C72E22.26F1660E--