From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bernhard Nortmann <bernhard.nortmann@web.de>
Date: Fri, 11 Sep 2015 11:31:50 +0200
Subject: [U-Boot] [RFC PATCH 2/2] sunxi: add "fel" boot target
In-Reply-To: <55F1CD9E.6080303@redhat.com>
References: <1441289520-22749-1-git-send-email-bernhard.nortmann@web.de>
 <1441289520-22749-3-git-send-email-bernhard.nortmann@web.de>
 <55F1CD9E.6080303@redhat.com>
Message-ID: <55F29F86.5050901@web.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi!

Am 10.09.2015 um 20:36 schrieb Hans de Goede:
> Hi,
>
> I would prefer to have this like this:
>
>     "bootcmd_fel=" \
>         "if test -n ${fel_booted} && test -n ${fel_data_addr}; then " \
>             "echo '(FEL boot)';" \
>             "source ${fel_data_addr}; " \
>         "fi\0"
>

Sure, we could do that. I wanted to make clear that ${fel_booted} is
independent of a script being present (and thus ${fel_data_addr} set).
If the user feels inclined to do so, he might e.g. tweak bootcmd_fel
to override some defaults even with no boot.scr involved.

> Also if we are not using fel_data_size, then why do we even
> have it ?
>

I thought it unnecessary to restrict ourselves to not being able to
pass the size information, and kept it optional deliberately.

Admittedly it's pointless in the "standard" case of boot.scr, as that
is expected to be an image with a well-defined header (including data
size). I could imagine other uses, e.g. a customized fel utility
passing uEnv.txt-style data, and integrating that via bootcmd_fel
"import -t ${fel_data_addr} ${fel_data_size}". Personally I like to
do this when testing; I find it easier to simply edit a text file
(without having to go through a mkimage .scr on each cycle).

Regards, B. Nortmann