[U-Boot] [PATCH] mksunxi_fit_atf.sh: Allow for this to complete when bl31.bin is missing

In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com --- board/sunxi/mksunxi_fit_atf.sh | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index ecea1b839bdf..0deed6eeb14d 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -7,6 +7,11 @@
[ -z "$BL31" ] && BL31="bl31.bin"
+if [ ! -f $BL31 ]; then + echo "WARNING: BL31 file $BL31 NOT found, resulting binary is non-functional" >&2 + BL31=/dev/null +fi + cat << __HEADER_EOF /dts-v1/;

Hi Tom.,
On 22 May 2017 at 13:40, Tom Rini trini@konsulko.com wrote:
In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com
board/sunxi/mksunxi_fit_atf.sh | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index ecea1b839bdf..0deed6eeb14d 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -7,6 +7,11 @@
[ -z "$BL31" ] && BL31="bl31.bin"
+if [ ! -f $BL31 ]; then
echo "WARNING: BL31 file $BL31 NOT found, resulting binary is non-functional" >&2
BL31=/dev/null
+fi
On x86 we use BUILD_ROM to enable building of something that requires binary blobs. Maybe we should have a standard build flag which tells the build to use binary blobs (or perhaps to not use them?).
cat << __HEADER_EOF /dts-v1/;
-- 1.9.1
Regards, Simon

On Mon, May 22, 2017 at 02:24:44PM -0600, Simon Glass wrote:
Hi Tom.,
On 22 May 2017 at 13:40, Tom Rini trini@konsulko.com wrote:
In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com
board/sunxi/mksunxi_fit_atf.sh | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index ecea1b839bdf..0deed6eeb14d 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -7,6 +7,11 @@
[ -z "$BL31" ] && BL31="bl31.bin"
+if [ ! -f $BL31 ]; then
echo "WARNING: BL31 file $BL31 NOT found, resulting binary is non-functional" >&2
BL31=/dev/null
+fi
On x86 we use BUILD_ROM to enable building of something that requires binary blobs. Maybe we should have a standard build flag which tells the build to use binary blobs (or perhaps to not use them?).
That's not 100% true on how it's used on x86 today, we have to set BUILD_ROM to get a binary we can use with qemu (which is why it's set in .travis.yml) but I imagine could be controlled differently, easily enough. We also have a similar problem on TI HS devices in that if the HS kit is not installed we still generate binaries but they are non-functional on the hardware. In that case we key off of the generation script existing at all.
So yes, we should generalize this a bit, but I also really don't want to push the sunxi PR without something that means that autobuilders/etc will continue to funciton.

Hi Tom,
On 22 May 2017 at 14:33, Tom Rini trini@konsulko.com wrote:
On Mon, May 22, 2017 at 02:24:44PM -0600, Simon Glass wrote:
Hi Tom.,
On 22 May 2017 at 13:40, Tom Rini trini@konsulko.com wrote:
In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com
board/sunxi/mksunxi_fit_atf.sh | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index ecea1b839bdf..0deed6eeb14d 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -7,6 +7,11 @@
[ -z "$BL31" ] && BL31="bl31.bin"
+if [ ! -f $BL31 ]; then
echo "WARNING: BL31 file $BL31 NOT found, resulting binary is non-functional" >&2
BL31=/dev/null
+fi
On x86 we use BUILD_ROM to enable building of something that requires binary blobs. Maybe we should have a standard build flag which tells the build to use binary blobs (or perhaps to not use them?).
That's not 100% true on how it's used on x86 today, we have to set BUILD_ROM to get a binary we can use with qemu (which is why it's set in .travis.yml) but I imagine could be controlled differently, easily enough. We also have a similar problem on TI HS devices in that if the HS kit is not installed we still generate binaries but they are non-functional on the hardware. In that case we key off of the generation script existing at all.
So yes, we should generalize this a bit, but I also really don't want to push the sunxi PR without something that means that autobuilders/etc will continue to funciton.
Well let me know what you prefer and I can send a patch to update x86.
Reviewed-by: Simon Glass sjg@chromium.org
Regards, Simon

On 22/05/17 20:40, Tom Rini wrote:
In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Yeah, that sounds like a good idea. Thanks!
To make this even more useful, we should both mention either ATF or "ARM Trusted firmware" and board/sunxi/README.sunxi64, so that the users have a clue how to fix it.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com
With those hints above added: Reviewed-by: Andre Przywara andre.przywara@arm.com
Cheers, Andre.
board/sunxi/mksunxi_fit_atf.sh | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index ecea1b839bdf..0deed6eeb14d 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -7,6 +7,11 @@
[ -z "$BL31" ] && BL31="bl31.bin"
+if [ ! -f $BL31 ]; then
- echo "WARNING: BL31 file $BL31 NOT found, resulting binary is non-functional" >&2
- BL31=/dev/null
+fi
cat << __HEADER_EOF /dts-v1/;

On Tue, May 23, 2017 at 12:51:50AM +0100, André Przywara wrote:
On 22/05/17 20:40, Tom Rini wrote:
In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Yeah, that sounds like a good idea. Thanks!
To make this even more useful, we should both mention either ATF or "ARM Trusted firmware" and board/sunxi/README.sunxi64, so that the users have a clue how to fix it.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com
With those hints above added: Reviewed-by: Andre Przywara andre.przywara@arm.com
I added: Please read the section on ARM Trusted Firmware (ATF) in board/sunxi/README.sunxi64
and applied to u-boot/master, thanks!

On 23/05/17 01:18, Tom Rini wrote:
On Tue, May 23, 2017 at 12:51:50AM +0100, André Przywara wrote:
On 22/05/17 20:40, Tom Rini wrote:
In situations like an autobuilder we are likely to not have bl31.bin present and thus would fail to build and propagate the error upwards. Instead, print a big warning to stderr so that human will see that something is wrong but complete the build.
Yeah, that sounds like a good idea. Thanks!
To make this even more useful, we should both mention either ATF or "ARM Trusted firmware" and board/sunxi/README.sunxi64, so that the users have a clue how to fix it.
Cc: Andre Przywara andre.przywara@arm.com Cc: Simon Glass sjg@chromium.org Cc: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Tom Rini trini@konsulko.com
With those hints above added: Reviewed-by: Andre Przywara andre.przywara@arm.com
I added: Please read the section on ARM Trusted Firmware (ATF) in board/sunxi/README.sunxi64
and applied to u-boot/master, thanks!
Perfect, thanks!
Cheers, Andre.
participants (3)
-
André Przywara
-
Simon Glass
-
Tom Rini