On Sun, Dec 19, 2010 at 11:49 PM, Dirk Behme <dirk.be...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
