On Mon, Aug 03, 2009 at 05:45:14AM +0400, Ilya Yanok wrote:
> + if (this->options & NAND_BUSWIDTH_16) {
> + void __iomem *main_buf = host->regs->main_area0;
> + /* compress the ID info */
> + writeb(readb(main_buf + 2), main_buf + 1);
> + writeb(readb(main_buf + 4), main_buf + 2);
> + writeb(readb(main_buf + 6), main_buf + 3);
> + writeb(readb(main_buf + 8), main_buf + 4);
> + writeb(readb(main_buf + 10), main_buf + 5);
> + }
This indicates that read_byte isn't doing what the generic NAND code is
expecting. It should advance by a word in the buffer for each byte read
-- the implementation of nand_read_byte16 confirms this.
In that case, though, why have separate read_byte and read_word? Just
to provide an endian-broken alternative, that is only used where
endianness doesn't matter (checking bad block markers)? :-(
> + if (col & 1) {
> + union {
> + uint16_t word;
> + uint8_t bytes[2];
> + } nfc_word;
> +
> + nfc_word.word = readw(p);
> + ret = nfc_word.bytes[1];
> + nfc_word.word = readw(&p[1]);
> + ret |= nfc_word.bytes[0] << 16;
This still has an endian assumption (and shouldn't << 16 be << 8, and
require a cast to avoid shifting beyond the type width?) -- it's moot
given the nature of read_byte and read_word, but if this were necessary
it should be something like:
union {
...
} nfc_word[3];
nfc_word[0] = readw(p);
nfc_word[1] = readw(p + 1);
nfc_word[2].bytes[0] = nfc_word[0].bytes[1];
nfc_word[2].bytes[1] = nfc_word[1].bytes[0];
ret = nfc_word[2].word;
Alternatively, you could apply le16_to_cpu to the result of something
like your version.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
