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" >&2BL31=/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