I forgot to mention in the cover letter for the previous patch set that because the mx6memcal board has no implementation of storage (it only supports a serial console and DDR), I haven't tested the resulting U-Boot, which has very little besides "mtest" included.
I'm hoping to use this code base (mx6memcal) as a straw man for loading both SPL (as a plugin) and U-Boot through the serial download path as we've previously discussed in at least [1], [2] and [3].
Now that Peng's patch to imximage has been applied, we can start to look at the implementation details, and I hope this patch set can help move us toward an implementation.
The gist of what's needed to allow SPL to be loaded as a plugin and avoid the need for removable storage or a full (non-SPL) U-Boot is shown in patch 2.
That is, we need something akin to setjmp/longjmp to: 1. to save the early state of the machine before SPL configures the DDR controller, and 2. a routine that we can call to return to the boot ROM
To address #1, there's a clear precedent in the support for a save_boot_params() routine and patch 2 adds one that simply saves the working register set. Examining the registers used by the ROM code shows that r0-r9 plus sp and lr are sufficient.
Experimentally, I've found that the boot ROM stack is initialized to 0x91ffb4 and that the stack pointer is at 0x91febc (248 bytes) on all of the machines I've tested against (MX6Q, MX6DL, MX6S and MX6SL), so we can save the stack just by moving the SPL stack (patch #1).
We'll also need to determine where the decision to return to the boot ROM occurs (i.e. when we call routine #2).
The obvious place for use during development is right after DDR initialization if loaded through the serial downloader, but it might also be useful to invoke the serial loader as a last resort instead of the current call to hang().
Patch 3 adds a config file which will allow a build of u-boot.imx with SPL as a plugin followed by u-boot.bin as the primary payload. It highlights the issue of only having a single IMX_CONFIG variable so it breaks the build of a stand-alone SPL. Rather, it doesn't break the build, but produces SPL that is effectively the same as u-boot.imx.
This leaves only the question of what the return_to_rom code should look like, and I'm a bit stumped. The ROM API isn't documented in any document I have.
In Troy's original patch ([4]), he calls a routine that he names HAB_RVT_LOAD_DATA. On i.MX Community ([5]), I found a reference to a plugin_download() routine and I'm not sure where that came from. The Community post suggests that it's used in EBOOT.
I tried a simplistic copy of the tail end of plugin start from [6] that calls pu_irom_hwcnfg_setup() and then returns to ROM without success. I'm not certain that this was the right approach and am hoping for some guidance.
References: [1] - http://lists.denx.de/pipermail/u-boot/2015-June/thread.html#215606 [2] - http://lists.denx.de/pipermail/u-boot/2016-September/thread.html#266303 [3] - http://lists.denx.de/pipermail/u-boot/2015-May/thread.html#215573 [4] - http://patchwork.ozlabs.org/patch/186054/ [5] - http://community.nxp.com/thread/303794 [6] - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx6/mx6_...
Eric Nelson (3): ARM: mx6: preserve Boot ROM stack in SPL ARM: mx6: ddr: add plugin-utils placeholder ARM: imx: mx6memcal: allow build of combined SPL+U-Boot
arch/arm/cpu/armv7/mx6/Makefile | 2 +- arch/arm/cpu/armv7/mx6/ddr.c | 4 ++++ arch/arm/cpu/armv7/mx6/plugin-utils.S | 24 ++++++++++++++++++++++++ arch/arm/imx-common/spl-plus-u-boot.cfg | 4 ++++ arch/arm/include/asm/arch-mx6/mx6-ddr.h | 19 +++++++++++++++++++ configs/mx6memcal_defconfig | 2 +- include/configs/imx6_spl.h | 2 +- 7 files changed, 54 insertions(+), 3 deletions(-) create mode 100644 arch/arm/cpu/armv7/mx6/plugin-utils.S create mode 100644 arch/arm/imx-common/spl-plus-u-boot.cfg