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 :
- NAND
- Environment
- 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