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

[Scott Wood]

On Tue, 17 May 2011 17:15:50 -0400
Alex Waterman <awaterman at dawning.com> wrote:

> > 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.

I think the issue is broader than 4xx.

> > 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.

Nothing in nand_base.c is used by SPL.  SPL has its own code for this,
which currently just does a readb() (broken on 16-bit?).

> 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?

It's not really our choice, it's what the manufacturer uses (unless you
want to get into rewriting the markers before first use...).  The one
chip datasheet I looked at claimed the bad block marker was any value other
than 0xffff on 16-bit, so checking just one of the bytes would be wrong.

-Scott