Re: sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
Hi Samuel, On Thu, 6 Aug 2020 at 22:20, Samuel Holland wrote: > > On 8/5/20 1:25 PM, Simon Glass wrote: > >>> The last build steps with your patch are: > >>> > >>> cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin > >>> ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O . > >>> -m --allow-missing -I . -I . -I ./board/sunxi > >>> > >>> The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is > >>> broken. > >>> > >>> Nowhere in the commit message you state that you want to run binman on > >>> sunxi boards. > > > > BTW the commit does not change this. Sunxi boards were already using binman. > > That is only half true. Before this commit, binman was *not* run for sunxi > when > CONFIG_ARM64=y. 32-bit boards used binman with u-boot.img, and 64-bit boards > used mksunxi_fit_atf.sh to generate a FIT. Yes that's right. CONFIG_BINMAN was enabled but binman was not executed. > > Since converting mksunxi_fit_atf.sh to the binman equivalent is nontrivial > (how > do you expect to get environment variables into the device tree?), binman > should > be disabled for sunxi with CONFIG_ARM64=y. It shouldn't be too hard. See commit a32dd071485 for an example. I don't think you need environment variables...but if so, what for? The BL31_ADDR should really move to Kconfig I think, and BL31 can be used to pass another -I parameter to binman. The only new thing I can see is needing to create dtb and config nodes on the fly. How about a new sunxi-fit etype which subclasses Entry_fit and expands _ReadSubnode() to generate the extra nodes and properties? Regards, SImon
Re: sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
Hi, On Thu, 6 Aug 2020 at 22:20, Samuel Holland wrote: > > On 8/5/20 1:25 PM, Simon Glass wrote: > >>> The last build steps with your patch are: > >>> > >>> cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin > >>> ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O . > >>> -m --allow-missing -I . -I . -I ./board/sunxi > >>> > >>> The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is > >>> broken. > >>> > >>> Nowhere in the commit message you state that you want to run binman on > >>> sunxi boards. > > > > BTW the commit does not change this. Sunxi boards were already using binman. > > That is only half true. Before this commit, binman was *not* run for sunxi > when > CONFIG_ARM64=y. 32-bit boards used binman with u-boot.img, and 64-bit boards > used mksunxi_fit_atf.sh to generate a FIT. > > Since converting mksunxi_fit_atf.sh to the binman equivalent is nontrivial > (how > do you expect to get environment variables into the device tree?), binman > should > be disabled for sunxi with CONFIG_ARM64=y. > > A workaround for those affected by this breakage: instead of running `make` > with > no goals, run `make u-boot-sunxi-with-spl.bin` or the recently-added `make > inputs` to skip the binman step. It's a bit confusing, but the problem is that binman does create that file, overwriting what is there, but the binman definition lacks ATF. So I think a little hack can fix it for now. Will send a patch. Regards, SImon
Re: sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
Hi André, On Wed, 5 Aug 2020 at 09:21, André Przywara wrote: > > On 05/08/2020 16:05, Simon Glass wrote: > > Hi André, > > > > On Wed, 5 Aug 2020 at 08:20, André Przywara wrote: > >> > >> On 19/07/2020 20:56, Simon Glass wrote: > >> > >> Hi, > >> > >>> On x86 various files that need to be created by binman. It does not make > >>> sense to enumerate these in the Makefile. They are described in the > >>> configuration (devicetree) for each board and we can simply run binman > >>> (always) to generate them. > >>> > >>> Update the Makefile to have a separate, final step which runs binman, > >>> once all input dependencies are present. > >>> > >>> This avoid sprinkling the Makefile with arch-specific code. > >> > >> it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!). > >> When building current master, the Trusted Firmware binary does not make > >> it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux > >> won't get very far without BL31. To me it looks like we combine > >> u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains > >> bl31.bin. > >> > >> I bisected down into the hunks of this patch here, and by reverting just > >> hunk #3 (the one introducing .binman_stamp) it works again. > >> My knowledge of the U-Boot build system is somewhat limited, so I don't > >> immediately see the problem or a fix. > >> > >> A simple way to verify a build is complete would be: > >> $ strings u-boot-sunxi-with-spl.bin | grep BL31 > >> If it reports some lines, TF-A is included and it would work correctly. > >> If it comes back empty, TF-A is missing and we won't boot. > >> > >> I would be grateful for any insights! > > > > Thanks for the info. Which board is this? > > I happened to see this on bananapi_m64_defconfig, but any arm64 sunxi > board should be affected. OK thanks, will try that. The problem is not obvious to me but I'll take another look before the end of today. Regards, SImon
Re: sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
On 05/08/2020 16:05, Simon Glass wrote: > Hi André, > > On Wed, 5 Aug 2020 at 08:20, André Przywara wrote: >> >> On 19/07/2020 20:56, Simon Glass wrote: >> >> Hi, >> >>> On x86 various files that need to be created by binman. It does not make >>> sense to enumerate these in the Makefile. They are described in the >>> configuration (devicetree) for each board and we can simply run binman >>> (always) to generate them. >>> >>> Update the Makefile to have a separate, final step which runs binman, >>> once all input dependencies are present. >>> >>> This avoid sprinkling the Makefile with arch-specific code. >> >> it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!). >> When building current master, the Trusted Firmware binary does not make >> it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux >> won't get very far without BL31. To me it looks like we combine >> u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains >> bl31.bin. >> >> I bisected down into the hunks of this patch here, and by reverting just >> hunk #3 (the one introducing .binman_stamp) it works again. >> My knowledge of the U-Boot build system is somewhat limited, so I don't >> immediately see the problem or a fix. >> >> A simple way to verify a build is complete would be: >> $ strings u-boot-sunxi-with-spl.bin | grep BL31 >> If it reports some lines, TF-A is included and it would work correctly. >> If it comes back empty, TF-A is missing and we won't boot. >> >> I would be grateful for any insights! > > Thanks for the info. Which board is this? I happened to see this on bananapi_m64_defconfig, but any arm64 sunxi board should be affected. Thanks, Andre
Re: sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
Hi André, On Wed, 5 Aug 2020 at 08:20, André Przywara wrote: > > On 19/07/2020 20:56, Simon Glass wrote: > > Hi, > > > On x86 various files that need to be created by binman. It does not make > > sense to enumerate these in the Makefile. They are described in the > > configuration (devicetree) for each board and we can simply run binman > > (always) to generate them. > > > > Update the Makefile to have a separate, final step which runs binman, > > once all input dependencies are present. > > > > This avoid sprinkling the Makefile with arch-specific code. > > it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!). > When building current master, the Trusted Firmware binary does not make > it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux > won't get very far without BL31. To me it looks like we combine > u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains > bl31.bin. > > I bisected down into the hunks of this patch here, and by reverting just > hunk #3 (the one introducing .binman_stamp) it works again. > My knowledge of the U-Boot build system is somewhat limited, so I don't > immediately see the problem or a fix. > > A simple way to verify a build is complete would be: > $ strings u-boot-sunxi-with-spl.bin | grep BL31 > If it reports some lines, TF-A is included and it would work correctly. > If it comes back empty, TF-A is missing and we won't boot. > > I would be grateful for any insights! Thanks for the info. Which board is this? Regards, SImon
