On Fri, 14 Jun 2002, Robert Schwebel wrote:
> I have a strange effect on an embedded system (AMD Elan SC410,
> Linux-2.4.18) while accessing a static RAM. The RAM is mapped to the bus
> at 0x0200'0000. If I map it to user space this way:
>
> pSRAM = (unsigned short *)mmap(0, 0x00040000, PROT_READ + PROT_WRITE, MAP_SHARED, FD, 0x2000000);
>
> and fill it like this:
>
> pByte=(char*)pSRAM;
> for (i=0; i<10; i++) {
> *pByte++=(char)i;
> }
>
> pByte=(char*)pSRAM;
> for (i=0; i<10; i++) {
> printf("i: %02i -> %03i\n", i, *pByte++);
> }
>
> I see a mirroring effect:
>
> i: 00 -> 001
> i: 01 -> 001
> i: 02 -> 003
> i: 03 -> 003
> i: 04 -> 005
> i: 05 -> 005
> i: 06 -> 007
> i: 07 -> 007
> i: 08 -> 009
> i: 09 -> 009
>
> Now I'm wondering how the kernel/processor handles odd byte access
> exceptions. Can anybody give me a pointer where I could search or what my
> problem could be?
>
> Robert
There are no odd-byte access exceptions in the SC410 or in any Intel
ix86 emulation. Word accesses at odd-byte boundaries may (not always)
simply take longer. You can access any size element at any alignment.
The only time you will get an exception is if you attempt to access
0xffffffff as a Word (and similar boundary errors).
> printf("i: %02i -> %03i\n", i, *pByte++);
Now, I'm not smart enough to understand what this code is supposed
to show so I can't offer any suggestions. But, with all Intel machines,
the lowest byte is in the lowest memory address and the lowest word
is in the lowest memory address, etc.
Given: 0xdeadface
Memory:
<-- Low High -->
0xce, 0xfa, 0xad, 0xde
Also, in 32-bit code, if you are going to pass a byte to a function,
the rest of the 32-bit value passed may be junk since you can't
push bytes onto the stack.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:31 EST