[U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support

[Thierry Reding]

* Stephen Warren wrote:
> On 04/26/2012 12:32 PM, Thierry Reding wrote:
> > The problem is that neither the format of the BCT nor that of the PT is
> > documented anywhere. It seems like the BCT contains a reference to where in
> > the flash the PT starts but I wasn't able to find out where.
> 
> I have filed an internal bug to request this information be added to the
> TRM. We will see what happens.

I have filed a similar bug (#976261 in the NVIDIA bug tracker) and Vincent
has been informed, so that may help.

> > Actually I'd need more than those three partitions. I need at least five,
> > optimally six. In addition to BCT, PT and EBT I need one for the uImage and
> > the root filesystem.
> 
> Oh I see; you're mingling the boot flash and filesystem into a single
> memory device. It simpler (but I imagine more costly) not too:-)

Yes, it's all about the money. =) On a more serious note it makes a lot of
sense. Firstly we want to use the MMC/SD slot for user storage on Plutux and
therefore need to have the OS on internal storage (i.e. NAND). And secondly
we build a very minimalistic distribution in-house it fits without a problem.

> > As I said before, the biggest problem with updating the whole content is that
> > there's no documentation about either the BCT or the PT. There's cbootimage
> > on gitorious that has some information about the BCT, but it's incomplete.
> 
> Out of curiosity, what's missing from cbootimage?

It's missing support for PT. That may not be necessary in a setup where we
initialize the NAND from Linux user space, though, so maybe it would be
enough.

One thing I just remembered which may be a little problem is that currently
our boards need to use the L4T binaries for OpenGL ES support, which means
they need to run a Chromium kernel and that sadly doesn't properly boot from
a mainline U-Boot but requires a setup where we use quickboot as first stage
and U-Boot as a second stage bootloader. I haven't had time to investigate
this further, though. But having this kind of setup complicates the NAND
setup from user space further.

The long term plan was to incrementally move to a mainline system by first
replacing the QuickBoot/U-Boot combo that we use now with a mainline U-Boot.
Most of the pieces for that are now in place. I'm not sure if the SMSC95xx is
already supported by U-Boot (we need it to program the MAC address) during
bootstrap. Subsequently we were planning to move to a mainline kernel, which
is obviously even longer term because it requires the DRM driver to be merged
along with an updated user space to take advantage of it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120427/aae59824/attachment.pgp>