On Tue, Jun 21, 2016 at 12:48:45PM -0700, Eric Nelson wrote:
On 06/21/2016 11:41 AM, Eric Nelson wrote:
This patch set makes use of the dynamic DDR calibration routines added in commit d339f16 to define an alternative to the Freescale DDR stress tester tool.
Hi all,
While preparing this patch set, I thought again about the tools we have for managing SPL images, and especially "first boot" issues (when a full U-Boot isn't available or isn't programmed into the normal boot device).
Since the "mx6memcal" device is deliberately small, with only the DDR and UART defined, there's no way to load a full U-Boot and doing so would defeat the primary purpose.
We've discussed this at length on a number of occasions, (most recently in [5]) but I don't think we have a good solution.
I just looked at Troy's ancient patches ([1] and [2]) and it seems that these two patches are the bulk of the work needed to build a combined SPL+U-Boot image, and if I understand patch 2 correctly, SPL could tell at run-time that it was executed via a plugin and return control to the Boot ROM instead of trying to load U-Boot or a kernel.
If I recall correctly, Troy dropped these patches because of push-back that came from the sheer size of the 21-patch set, and not because of any particular objection to support for plugins.
It seems that a little work here would remove the need for things like Stefano's patch in [3] or Michael thoughts of adding DFU support in [4].
I'm interested in hearing your thoughts on the subject.
So, if I read the commentary right, "plugin" is how we can eventually get to the point where we can support, in a single binary, somewhat disparate board / SoC types because we can have enough smarts there to see if it's a Q or D or DL and so forth, right? That would be worthwhile to support, yes.