[U-Boot] [patch] dm355evm NAND support

[Paulraj, Sandeep]

> 
> > > I have already ack-ed Sandeep's patch that contains this
> > > fix for the warning.  Please check with him.
> >
> > That is correct, I did not add it to my tree because you ACK'ed
> > this patch only after I sent a pull request. So obviously I cannot
> > add a patch that has been ACK'ed to an already existing pull request.
> 
> A "pull <this ID>" request wouldn't have been changed by
> adding another commit to that tree.  You could however
> have sent an updated pull request, with both.

In hindsight yes. But since Tom had already acknowledged the request I chose not to send an update request 

> 
> That would result in a tree that *builds* properly...
> 
> 
> > This will be part of my next pull request which will have a similar
> > fix for DM365 and hopefully the EMAC support for DM365 which should
> > result in a fully functional DM365 EVM support.
> 
> That would be nice.  I'll still want the updated CPLD bits,
> which pass SRST through from the JTAG adapter though; that
> is obviously not a U-Boot issue.  ;)
> 
> 
> > > In general it is better to break patches that do multiple things into
> > > multiple patches.  When you resubmit, please break this patch into its
> > > logical parts :
> > > 1. NAND
> > > 2. Environment
> > > 3. Bootdelay
> > >
> > > Tom
> >
> > If the u-boot-ti tree or the u-boot-arm tree is checked, all the above
> > features which are being added are already in both trees.
> 
> I guess that happened after I prepared the patch but before I sent
> it in.  I'll look; there were some differences still.  Notably to
> store the environment in the otherwise-unused block zero,
That is because most users who have used existing TI binaries have the env stored at 0x3c0000. So if the update the U-Boot binary, they will still get all their env back.
IIRC this was a customer requirement of ours.

> and work
> better with the small-page NANDs I've got handy.
That is saw and I agree with you
> 
> 
> > When Tom sends a pull request to Wolfgang it should become part of
> > Wolfgang's tree as well.
> >
> > Afcourse it does not have the 64 bit VSPRINTf for which I was
> > going to submit a patch anyway.
> 
> That's important ... it doesn't work right without that patch.
> When you erase or protect blocks, the diagnostics are broken
> since they give bogus addresses.
I have noticed that. Also while trying to erase, if we come across a bad block, we will get something like "Bad Block erasing at 0x00000000".
All symptoms of the absence of the option
I was going to send a patch.
> 
> - Dave

Thanks,
Sandeep