[U-Boot] [patch] dm355evm NAND support
David Brownell
david-b at pacbell.net
Mon Oct 5 22:38:19 CEST 2009
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
More information about the U-Boot
mailing list