[U-Boot] RFC: porting u-boot to sequoia based nand booting board

Alex Waterman
2011-05-17T21:15:50Z

Scott,

> If readw() is returning the bytes in the correct endianness, then that
> means the register is little-endian.
>
> It's not clear to me what the default assumption in nand_base.c is,
> though. read_byte16() suggests the default is native endian, but
> read_buf() and read_word() suggest it's little endian. :-(

I am not sure either; the nand_read_byte16() function confuses me quite a bit.
I really have no idea whether what I have done is wrong and an evil hack or
if I found a typo or something.

> Is there any currently working host-big-endian platform with 16-bit NAND
> that doesn't override these functions?

I really can't say. I haven't looked through the source of any of the other
boards. As Stefan said, all previous 4xx based boards use 8 bit NAND so the
possibility that there might be a problem with the 16 bit code on 4xx based
boards doesn't surprise me.

> BTW, as for read_word(), looking at its only user, I think nand_block_bad()
> should be checking a 16-bit bad block marker on 16-bit NAND, rather than the
> low byte. Why is there a separate mechanism for checking bad block markers
> than the one in nand_bbt.c (not the bbt itself, but the code used to read
> the markers to create the bbt)? As long as a BBT is used, I don't think
> read_word() will ever matter.

I think it may have something to do with the NAND SPL loader. Since the
NDFC code is being used by the SPL, it has to be small. Pulling in the all of
the nand_bbt.c code for just the code that checks if the block is actually
bad may (probably) have been to much for the SPL. Thats my guess at least.
If the 16 bit chips used 0xffff as a bad block marker then yeah, I suppose
the endianness wouldn't matter. Is that something that we can do? Just choose
to use 0xffff? Will that not potentially mess up JFFS support or what not
from the Linux kernel that gets booted?