WLAN from SDIO to SPI: battle plan

[Werner Almesberger]

dennis.yxun wrote:
>   I try to disassemble the code, find the second "strb" instruction
> should be blame to. see line 0x33f82b24 change 0x5900000c to 0x00.

Wow, nice find ! So there are two problems: first, the SPI registers
don't like being accessed byte-wise, and second, this

> 33f82b20:   e5c2300c    strb    r3, [r2, #12]    // 0x5900000c = 0x4f
> 33f82b24:   e5c2100f    strb    r1, [r2, #15]    //0x5900000c= 0x00!,god
> 33f82b28:   e5c2100d    strb    r1, [r2, #13]
> 33f82b2c:   e5c2100e    strb    r1, [r2, #14]

is probably the last thing the u-boot authors had in mind when they
wrote those packed structs with "volatile u32" inside. This construct
is used all over the place, so it makes me wonder how many other
accesses have similar issues.

By the way, it's really the "packed" that throws gcc into wild
confusion. It can get even funnier:

struct {
    volatile int foo;
} __attribute__((__packed__)) *p;

void bar(void)
{
    p->foo = 0x42;
}

# arm-angstrom-linux-gnueabi-gcc -Wall -O -c -o foo.o foo.c
# arm-angstrom-linux-gnueabi-objdump -d foo.o

[...]
   c:   e3a01000        mov     r1, #0  ; 0x0
  10:   e3812042        orr     r2, r1, #66     ; 0x42
  14:   e5c32000        strb    r2, [r3]
  18:   e5d32001        ldrb    r2, [r3, #1]
  1c:   e5c31001        strb    r1, [r3, #1]
  20:   e5d32002        ldrb    r2, [r3, #2]
  24:   e5c31002        strb    r1, [r3, #2]
  28:   e5d32003        ldrb    r2, [r3, #3]
  2c:   e5c31003        strb    r1, [r3, #3]
[...]

Doesn't quite have the peculiar "byte order" of your example,
though.

>    And i find it's nothing to do with "TAGD" bit or SPI interrupt mask bit.

I found that nothing got sent if I set TAGD. Disabling the SPI
interrupt was indeed just paranoia, in case this ran under a
kernel that actually used the SPI driver.

- Werner