[U-Boot] [patch] dm355evm NAND support

[David Brownell <david-b@pacbell.net>]

On Monday 05 October 2009, Paulraj, Sandeep wrote:

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

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, and work
better with the small-page NANDs I've got handy.


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

- Dave