[U-Boot] [RFC PATCH 0/3] ARM: imx: mx6: Add plugin support for SPL

[Eric Nelson]

Hi Tim,

On 01/17/2017 06:27 PM, Tim Harvey wrote:
> On Tue, Nov 1, 2016 at 7:06 PM, Eric Nelson <eric at nelint.com> wrote:
>> 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_plugin.S
>>
>> 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
>>
>> --
>> 2.7.4
>>
> 
> Hi Eric,
> 
> I'm interested loading U-Boot from the OTG serial downloader and this
> looks like a good approach. Thanks for continuing to plug away at
> this!
> 

NP. It seems like the easy route if we can figure out the details of
the ROM API calls.

I was hoping to get some feedback from Peng or Troy, but it seems
that they're also overloaded.

> If I understand correctly the approach here is to use the plugin
> support such that the boot ROM will execute the SPL as a plugin which
> then returns and jumps to U-boot?
> 

That's the idea. Both SB_LOADER and imx_usb support this, so the
key is figuring out how to return to the Boot ROM.

> I've applied your mx6memcal series to master and support for one of
> the Gateworks boards I'm working with and can boot that SPL (23KB)
> fine (so I've got the UART and configured correctly at least). When I
> adapt that to use spl-plus-u-boot.cfg on top of this patch series the
> resulting SPL (85KB) image doens't appear to boot (nothing over the
> serial console) but I'm thinking I'm doing something wrong as
> imx_usb_loader seems like its not loading it fully or loading it too
> quickly. Do I need patches to imx_usb_loader or am I doing something
> obvious wrong here?
> 

I need to re-visit this. My recollection is that the SPL portion should
load and run, but the return-to-ROM portion will fail.

My next thought is to use JTAG to trace things through the return to
BOOT ROM and use an image from the Freescale fork as a working
example.

> Incidentally, did anyone ever proof out the other discussed method
> where an SPL is built with zmodem and allows loading u-boot.img over
> that?
> 
Yeah.

Stefano had that working, though I had some issues getting
microcom working. I had to stop and restart microcom and initiate
the upload.

Regards,


Eric