Hello Pali, On 11.01.23 19:13, Pali Rohár wrote: > On Wednesday 11 January 2023 19:02:38 Pali Rohár wrote: >> On Wednesday 11 January 2023 18:55:40 Pali Rohár wrote: >>> On Wednesday 11 January 2023 09:01:37 Tom Rini wrote: >>>> On Wed, Jan 11, 2023 at 01:52:24PM +0100, Heiko Schocher wrote: >>>>> Hello Pali, Tom, >>>>> >>>>> I just tried azure build with my socrates board updates based on >>>>> v2023.01 and the 2 patches from Pali: >>>>> >>>>> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-1-p...@kernel.org/ >>>>> http://patchwork.ozlabs.org/project/uboot/patch/20221228200437.30971-2-p...@kernel.org/ >>> >>> At the time when I sent those two patches to ML, I checked that P1/P2 >>> powerpc boards and also socrates board compiles successfully. >>> >>> Now I imported those two patches on top of the current master branch and >>> they still compiles without any problems for socrates board. >>> >>>>> and get errors for powerpc build: >>>>> >>>>> https://dev.azure.com/hs0298/110c3e42-44d5-4db4-9bd5-8a8bbead15f3/_apis/build/builds/93/logs/601 >>>>> >>>>> socrates board builds fine ... my patches are socrates board specfic, >>>>> so hopefully no impact for other boards ... >>> >>> From that build log it looks like that u-boot fails for socrates and >>> kmcent2 board. Which is strange as you said that too that socrates is >>> building fine...
misreaded azure output, so socrates is failing because missing u-boot.dtb, sorry. Interesting is, that my yocto build works ... >> >> kmcent2 is expected to fail with my above two patches on top of the >> v2023.01 without this kmcent2 commit which is now already in master: >> https://source.denx.de/u-boot/u-boot/-/commit/499fe577c8011dd8a9184548c419db42aef079a7 > > And now I think I see the reason why it is failing also for socrates > board. Error in the build log is: > > 2023-01-11T12:16:04.4937207Z +binman: [Errno 2] No such file or directory: > 'u-boot.dtb' > 2023-01-11T12:16:04.4937685Z +make[1]: *** [Makefile:1613: u-boot-dtb.bin] > Error 1 Yup. > u-boot.dtb builds make by Makefile rule: > > u-boot.dtb: dts/dt.dtb > $(call cmd,copy) > > But socrates-u-boot.dtsi has specified that use dts/dt.dtb and this > dependency is also specified in Makefile. > > And it looks like that binman needs also u-boot.dtb file. So it is > possible to hit a race condition, that make builds u-boot.dtb later than > rule for binman. Exactly over this I stumbled yesterday in the evening and I made a local fix: diff --git a/Makefile b/Makefile index fb1454552a..60f5cffccd 100644 --- a/Makefile +++ b/Makefile @@ -1609,7 +1609,7 @@ OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec u-boot-br.bin: u-boot FORCE $(call if_changed,objcopy) else ifeq ($(CONFIG_TARGET_SOCRATES),y) -u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE +u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb u-boot.dtb FORCE $(call if_changed,binman) endif > I would suggest to try to apply this patch, which should instruct make > to do not call binman until u-boot.dtb is correctly built: > > diff --git a/Makefile b/Makefile > index 3c76486a620e..5d2ef8cc81c5 100644 > --- a/Makefile > +++ b/Makefile > @@ -1603,7 +1603,7 @@ OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j > .resetvec > u-boot-br.bin: u-boot FORCE > $(call if_changed,objcopy) > else ifeq ($(CONFIG_TARGET_SOCRATES),y) > -u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE > +u-boot-dtb.bin: u-boot-nodtb.bin u-boot.dtb FORCE > $(call if_changed,binman) > endif > > diff --git a/arch/powerpc/dts/socrates-u-boot.dtsi > b/arch/powerpc/dts/socrates-u-boot.dtsi > index ba2e56d35675..f6af611b513c 100644 > --- a/arch/powerpc/dts/socrates-u-boot.dtsi > +++ b/arch/powerpc/dts/socrates-u-boot.dtsi > @@ -9,7 +9,7 @@ > pad-byte = <0xff>; > // Place dtb one sector before u-boot-nodtb.bin > blob { > - filename = "dts/dt.dtb"; > + filename = "u-boot.dtb"; > }; > u-boot-nodtb { > filename = "u-boot-nodtb.bin"; > > > Heiko, could you try to put commit 499fe577c8011dd8a9184548c419db42aef079a7 > and above patch to your branch and retest it again? Of course! Just have to wait until other azure build finished... In the meantime I rebased my patchset to current HEAD, so above commit is already in, and I had to adapt some patches for socrates. I write the results hopefully soon. bye, Heikp >>>> socrates is one of the two failing boards, in that link: >>>> 2023-01-11T12:16:04.4930367Z powerpc: w+ MPC837XERDB kmcoge5ne >>>> kmeter1 kmopti2 kmsupx5 kmtepr2 tuge1 tuxx1 MPC8548CDS MPC8548CDS_36BIT >>>> MPC8548CDS_legacy P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_NOR >>>> P1010RDB-PA_36BIT_SDCARD P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_NAND >>>> P1010RDB-PA_NOR P1010RDB-PA_SDCARD P1010RDB-PA_SPIFLASH >>>> P1010RDB-PB_36BIT_NAND P1010RDB-PB_36BIT_NOR P1010RDB-PB_36BIT_SDCARD >>>> P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_NOR >>>> P1010RDB-PB_SDCARD P1010RDB-PB_SPIFLASH P1020RDB-PC P1020RDB-PC_36BIT >>>> P1020RDB-PC_36BIT_NAND P1020RDB-PC_36BIT_SDCARD >>>> P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PC_NAND P1020RDB-PC_SDCARD >>>> P1020RDB-PC_SPIFLASH P1020RDB-PD P1020RDB-PD_NAND P1020RDB-PD_SDCARD >>>> P1020RDB-PD_SPIFLASH P2020RDB-PC P2020RDB-PC_36BIT >>>> P2020RDB-PC_36BIT_NAND P2020RDB-PC_36BIT_SDCARD >>>> P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_SDCARD >>>> P2020RDB-PC_SPIFLASH P2041RDB P2041RDB_NAND P2041RDB_SDCARD >>>> P2041RDB_SPIFLASH T1024RDB T1024RDB_NAND T1024RDB_SDCARD >>>> T1024RDB_SPIFLASH T1042D4RDB T1042D4RDB_NAND T1042D4RDB_SDCARD >>>> T1042D4RDB_SPIFLASH T2080QDS T2080QDS_NAND T2080QDS_SDCARD >>>> T2080QDS_SECURE_BOOT T2080QDS_SPIFLASH T2080QDS_SRIO_PCIE_BOOT T2080RDB >>>> T2080RDB_NAND T2080RDB_revD T2080RDB_revD_NAND T2080RDB_revD_SDCARD >>>> T2080RDB_revD_SPIFLASH T2080RDB_SDCARD T2080RDB_SPIFLASH T4240RDB >>>> T4240RDB_SDCARD + socrates kmcent2 >>>> >>>>> @Tom: Do you know if v2023.01 builds fine for powerpc >>>> >>>> Yes, CI is passing. >>>> >>>> -- >>>> Tom >>> >>> -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de