[U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[John Rigby]

On Sun, Dec 19, 2010 at 11:49 PM, Dirk Behme <dirk.behme at googlemail.com> wrote:
> On 20.12.2010 07:07, John Rigby wrote:
>> The working assembly looks like this:
>>
>>        if (cmd != NAND_CMD_NONE)
>> 80024d28:       e3710001        cmn     r1, #1
>>                origwriteb(cmd, this->IO_ADDR_W);
>> 80024d2c:       15933004        ldrne   r3, [r3, #4]
>> 80024d30:       120110ff        andne   r1, r1, #255    ; 0xff
>> 80024d34:       15c31000        strbne  r1, [r3]
>> 80024d38:       e8bd8010        pop     {r4, pc}
>>
>> The broken assembly looks like this:
>>
>>        if (cmd != NAND_CMD_NONE)
>> 80024d28:       e3710001        cmn     r1, #1
>> 80024d2c:       08bd8010        popeq   {r4, pc}
>>                writeb(cmd, this->IO_ADDR_W);
>> 80024d30:       e5933004        ldr     r3, [r3, #4]
>> 80024d34:       e20110ff        and     r1, r1, #255    ; 0xff
>> 80024d38:       e5c31000        strb    r1, [r3]
>> 80024d3c:       e5d33000        ldrb    r3, [r3]
>> 80024d40:       e8bd8010        pop     {r4, pc}
>
> Hmm. From functionality point of view, the 'broken' assembly below should to
> the same as the working assembly, above. The main difference is the 'popeq
> {r4, pc}' and the additional 'ldrb      r3, [r3]'. The write to the HW 'strb
>    r1, [r3]' is there, so it should work. Is this understanding correct?
>
> If it's correct, the question is, what breaks the below assembly? The popeq
> or the additional ldrb? The popeq looks correct, but why is the additional
> ldrb there?
>

I can't answer why the ldrb is there but I'm pretty sure it is the
problem.  From the TRM
http://focus.ti.com/lit/ug/spruf98m/spruf98m.pdf:

Only write accesses must be issued to these locations, but the GPMC
does not discard any read access. Accessing a NAND device with nOE and
CLE or ALE asserted (read access) can produce undefined results.

br,
John