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

[Ian Campbell]

On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote:
> 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.

I've certainly had to mess with $*addr in order to workaround issues
with older versions of Xen booting on the cubietruck.

More generally I think diverging from the norm with a sunxi specific
variable is preferable to changing the semantics of existing variables
to make them r/o, which will make sunxi inconsistent with other u-boot
platforms.

> > 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.

I'm afraid that won't fly, $fooaddr are not r/o variables.

When felbooting there doesn't seem to be any particular reason why you
have to use $fooaddr from the environment, they could just as well be
addresses set by the boot.scr itself, whether derived from the eGON
header or not.

> > > 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/

This has nothing much todo with the config_distro_bootcmd.h stuff,
except the bootcmd stuff requires some of those variables to be set.

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

Regardless, the above BOOTENV_DEV type stuff is how the common
config_distro_bootcmd.h setup for adding a boot device works and should
be used. Or you can try and convince the maintainers it should be done
some other way globally, the important thing is that sunxi shouldn't be
more special than necessary.

> 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.

This means the user cannot adjust things to suit their local needs,
either disabling the fel script support or inserting it into the boot
order wherever they want. Hardcoding that stuff in C is not a solution
here I'm afraid.

So, please integrate properly with the common bootcmd stuff used on
other platforms instead of inventing sunxi specific ways to do things.

If needed for this infrastructure to work well then IMHO it would be
acceptable to either provide a function or set a variable on boot which
indicates whether or not the system was fel booted so e.g you could
write "if $fel_booted; then source $feladdr; fi" as bootcmd_fel. Unless
there is some existing "how was I booted" functionality in u-boot I'm
not aware of, if there was we should use it.

BTW, WRT:
+       /* Erase any potential boot.scr remnants in DRAM */
+       writel(0, CONFIG_SCRIPTADDR);

I was thinking that this isn't really all that sunxi specific, since
bootloops etc can occur on any platform which doesn't erase RAM between
boots. I think a better solution might be to add an option to the source
command to make it one shot i.e. by corrupting the boot.scr header
behind it, so it won't automatically be used next time.

Ian.