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

John Rigby
2010-12-20T07:37:01Z

On Sun, Dec 19, 2010 at 11:49 PM, Dirk Behme <dirk.behme@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