From: Alex Waterman <awaterman@dawning.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC: porting u-boot to sequoia based nand booting board
Date: Tue, 17 May 2011 17:15:50 -0400 [thread overview]
Message-ID: <4DD2E586.5050708@dawning.com> (raw)
In-Reply-To: <20110517142052.7ed835f4@schlenkerla.am.freescale.net>
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?
Regards,
Alex
--
Alex Waterman
Computer Engineer
Phone: 215-896-4920
Email: awaterman at dawning.com
next prev parent reply other threads:[~2011-05-17 21:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 13:00 [U-Boot] RFC: porting u-boot to sequoia based nand booting board Alex Waterman
2011-05-17 13:41 ` Stefan Roese
2011-05-17 14:11 ` Alex Waterman
2011-05-17 15:37 ` Stefan Roese
2011-05-17 17:05 ` Scott Wood
2011-05-17 17:49 ` Alex Waterman
2011-05-17 19:20 ` Scott Wood
2011-05-17 21:15 ` Alex Waterman [this message]
2011-05-17 21:32 ` Scott Wood
2011-05-18 12:49 ` Alex Waterman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DD2E586.5050708@dawning.com \
--to=awaterman@dawning.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox