[U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

[Siarhei Siamashka]

On Fri, 27 Feb 2015 16:39:45 +0000
Ian Campbell <ijc+uboot at hellion.org.uk> wrote:

> On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote:
> > In order to fully support booting the whole system over USB OTG
> > without relying on anything else (MMC, SATA, USB sticks, ...), it
> > is possible to upload the 'boot.scr' file to DRAM using the 'fel'
> > tool. But U-Boot still needs to be able to pick it up there before
> > checking any other boot media.
> > 
> > Signed-off-by: Siarhei Siamashka <siarhei.siamashka at gmail.com>
> > ---
> > 
> > The patch might be not the best way to implement this. But it would
> > be great if U-Boot had out of the box support for:
> >     http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29
> > 
> > One of the bad things about this patch is that the "scriptaddr"
> > variable needs to be hardcoded and protected agaist modifications
> > (if this address is to be used from the SPL).
> 
> Perhaps use a separate dedicated/hardcoded address for the FEL boot
> script to avoid adding unusual semantics to $scriptaddr (which might
> surprise users not using fel)?

Making something that is FEL-boot specific and diverges from the normal
configuration is not great. Is there a real practical need for anyone
to override $scriptaddr and the other similar variables in the
environment? If not, marking them as read-only (similar to how the MAC
address is handled) may be a reasonable solution.

> If the FEL address has to be 0x43100000 for compatibility with existing
> instructions/tools that might mean moving the current scriptaddr
> elsewhere. I think we can live with that.

There was an idea to make mksunxiboot tool store all these magic
addresses into the bootable image, so that the fel tool could find
them there. Some of such ideas are listed here:

    http://linux-sunxi.org/FEL/USBBoot#Potential_future_improvements_for_u-boot_v2015.07

This can only work if these addresses become compile time constants
and can't be overridden by the environment. If the user really has
a good reason to change them, making them configurable via menuconfig
may be a solution.

> > Also I'm not sure how this all could fit into the
> > "config_distro_bootcmd.h" model, so I even have not tried
> > that yet.
> 
> Just at a quick glance, based on the PXE entry something like:
> 
> #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \
> 	"bootcmd_fel=source ...\0"
> 
> i.e. all the magic params are irrelevant in this case. Perhaps
> "bootcmd_"#devtypel"=...\0" but I don't think that's needed in this
> instance. BOOTENV_DEV_PXE doesn't bother at least.
> 
> Then in BOOT_TARGET_DEVICES include "func(FEL, fel, na)"

Well, in fact I'm not a big fan of the C preprocessor based
approach used there. And if I understand it correctly, this
is already causing some troubles for the A80 (sun9i) support:

    https://patchwork.ozlabs.org/patch/429463/

The C preprocessor surely can be used, but such code is barely
maintainable.

IMHO all the necessary adjustments to the environment variables can
be done at runtime in the misc_init_r() function. For example,
pre-pending "fel" to the "boot_targets" variable can be done based
on a runtime check and activated only for the FEL mode. The C
preprocessor constants are much less flexible.

-- 
Best regards,
Siarhei Siamashka