U-Boot build report @ Sat Mar 31 05:30:15 CEST 2012

U-Boot Marek Vasut 4 participants 12 messages Mar 31, 2012 – Apr 2, 2012

lore

Share & tools

lore

Marek Vasut

author

2012-03-31 12:59 UTC #0 lore raw

Hello guys,

we now have exactly these boards not building for -RC1, can you please look into it?:

arm/flea3                               FAILED FOR: eldk4.2 eldk5.1
arm/hawkboard                           FAILED FOR: eldk4.2
arm/hawkboard_uart                      FAILED FOR: eldk4.2
arm/highbank                            FAILED FOR: eldk4.2
arm/mx35pdk                             FAILED FOR: eldk4.2 eldk5.1
arm/seaboard                            FAILED FOR: eldk4.2 eldk5.1
arm/ventana                             FAILED FOR: eldk4.2 eldk5.1
powerpc/P2020DS_36BIT                   FAILED FOR: eldk4.2
powerpc/PMC440                          FAILED FOR: eldk4.2 eldk5.1
powerpc/TQM8541                         FAILED FOR: eldk4.2
powerpc/TQM8555                         FAILED FOR: eldk4.2

If you need logs, please contact me, I'll provide them.

Best regards,
Marek Vasut

Anatolij Gustschin

2012-03-31 13:43 UTC #1 lore raw

Hi Marek,

Ccing Simon.

On Sat, 31 Mar 2012 14:59:06 +0200
Marek Vasut <[email protected]> wrote:
...

Quoted 4 lines

we now have exactly these boards not building for -RC1, can you please look into it?:
arm/flea3 FAILED FOR: eldk4.2 eldk5.1

This is fixed by patch http://patchwork.ozlabs.org/patch/149658/

...

Quoted 1 line

arm/mx35pdk FAILED FOR: eldk4.2 eldk5.1

Same as for flea3 board.

Quoted 2 lines

arm/seaboard FAILED FOR: eldk4.2 eldk5.1
arm/ventana FAILED FOR: eldk4.2 eldk5.1

These boards actually build without errors and warnings, but errors/warnings status is reported by MAKEALL because of the output:

DTC: dts->dtb on file "dt.dtb.tmp"

This could be fixed by

dts/Makefile +1 -1

index 5792afd..d19a622 100644
@@ -47,7 +47,7 @@ DT_BIN	:= $(obj)dt.dtb
 
 $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 	cat $< | $(CPP) -P $(DTS_CPPFLAGS) - >[email protected]
-	$(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected]
+	$(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected] 2> /dev/null
 	rm [email protected]
 
 process_lds = \

...

Quoted 1 line

powerpc/PMC440 FAILED FOR: eldk4.2 eldk5.1

This could be fixed by http://patchwork.ozlabs.org/patch/147745
but maybe we should better move timer_get_boot_us() to common/bootstage.c to fix it.

Thanks for build testing and reporting!

Anatolij

Marek Vasut

author

2012-03-31 14:12 UTC #3 lore raw

Dear Anatolij Gustschin,

Quoted 36 lines

On Sat, 31 Mar 2012 15:43:03 +0200
Anatolij Gustschin <[email protected]> wrote:
...
Quoted 25 lines
Quoted 2 lines
arm/seaboard FAILED FOR: eldk4.2 eldk5.1
arm/ventana FAILED FOR: eldk4.2 eldk5.1
These boards actually build without errors and warnings, but errors/warnings status is reported by MAKEALL because of the output:
DTC: dts->dtb on file "dt.dtb.tmp"
This could be fixed by
dts/Makefile +1 -1
index 5792afd..d19a622 100644
@@ -47,7 +47,7 @@ DT_BIN	:= $(obj)dt.dtb
 
 $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 
 	cat $< | $(CPP) -P $(DTS_CPPFLAGS) - >[email protected]
 
-	$(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected]
+	$(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected] 2> /dev/null
 
rm [email protected]
Quoted 1 line
process_lds = \
Thinking more about this I see that it is wrong. dtc could die for other reasons and it should be handled as error. We should fix dtc instead not to output this info to stderr. Currently it does:

Quoted 2 lines

fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
                inform, outform, arg);

Agreed! Doing stderr output of info text is plain wrong :( Will you send a patch mainline please?

Quoted 3 lines

Thanks,
Anatolij

Best regards,
Marek Vasut

Simon Glass

2012-03-31 15:51 UTC #4 lore raw

Hi,

Quoted 39 lines · Marek Vasut

Dear Anatolij Gustschin,
Quoted 36 lines
On Sat, 31 Mar 2012 15:43:03 +0200
Anatolij Gustschin <[email protected]> wrote:
...
Quoted 25 lines
Quoted 2 lines
arm/seaboard FAILED FOR: eldk4.2 eldk5.1
arm/ventana FAILED FOR: eldk4.2 eldk5.1
These boards actually build without errors and warnings, but errors/warnings status is reported by MAKEALL because of the output:
DTC: dts->dtb on file "dt.dtb.tmp"
This could be fixed by
dts/Makefile +1 -1
index 5792afd..d19a622 100644
@@ -47,7 +47,7 @@ DT_BIN    := $(obj)dt.dtb
 
 $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 
    cat $< | $(CPP) -P $(DTS_CPPFLAGS) - >[email protected]
 
-   $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected]
+   $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected] 2> /dev/null
 
    rm [email protected]
Quoted 1 line
process_lds = \
Thinking more about this I see that it is wrong. dtc could die for other reasons and it should be handled as error. We should fix dtc instead not to output this info to stderr. Currently it does:

Quoted 4 lines

Quoted 2 lines
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
                inform, outform, arg);
Agreed! Doing stderr output of info text is plain wrong :( Will you send

a patch

Quoted 1 line

mainline please?

I will do that if you like, it has bugged me for a while.

Regards,
Simon

Quoted 7 lines

Quoted 4 lines
Thanks,
Anatolij
Best regards,
Marek Vasut

Marek Vasut

author

2012-03-31 15:53 UTC #5 lore raw

Dear Simon Glass,

Quoted 45 lines

Hi,
Quoted 42 lines · Marek Vasut
Dear Anatolij Gustschin,
Quoted 39 lines
On Sat, 31 Mar 2012 15:43:03 +0200
Anatolij Gustschin <[email protected]> wrote:
...
Quoted 25 lines
Quoted 2 lines
arm/seaboard FAILED FOR: eldk4.2 eldk5.1
arm/ventana FAILED FOR: eldk4.2 eldk5.1
These boards actually build without errors and warnings, but errors/warnings status is reported by MAKEALL because of the output:
DTC: dts->dtb on file "dt.dtb.tmp"
This could be fixed by
dts/Makefile +1 -1
index 5792afd..d19a622 100644
@@ -47,7 +47,7 @@ DT_BIN    := $(obj)dt.dtb
 
 $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 
    cat $< | $(CPP) -P $(DTS_CPPFLAGS) - >[email protected]
 
-   $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected]
+   $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} [email protected] 2> /dev/null
 
    rm [email protected]
Quoted 1 line
process_lds = \
Thinking more about this I see that it is wrong. dtc could die for other reasons and it should be handled as error. We should fix dtc instead not to output this info to stderr. Currently it does:
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
                inform, outform, arg);

Quoted 7 lines

Quoted 1 line
Agreed! Doing stderr output of info text is plain wrong :( Will you send
a patch
Quoted 1 line
mainline please?
I will do that if you like, it has bugged me for a while.

Thank you very much, I owe you :)

Quoted 9 lines

Regards,
Simon
Quoted 6 lines
Quoted 3 lines
Thanks,
Anatolij
Best regards,
Marek Vasut

Best regards,
Marek Vasut

Simon Glass

2012-03-31 16:22 UTC #6 lore raw

In reply to Marek Vasut

Hi Marek,

Quoted 4 lines · Marek Vasut

Hello guys,
we now have exactly these boards not building for -RC1, can you please

look into

Quoted 1 line

it?:

Do you build all archs including m68k, nds32, etc.?

Regards,
Simon

Quoted 21 lines

arm/flea3                               FAILED FOR: eldk4.2 eldk5.1
arm/hawkboard                           FAILED FOR: eldk4.2
arm/hawkboard_uart                      FAILED FOR: eldk4.2
arm/highbank                            FAILED FOR: eldk4.2
arm/mx35pdk                             FAILED FOR: eldk4.2 eldk5.1
arm/seaboard                            FAILED FOR: eldk4.2 eldk5.1
arm/ventana                             FAILED FOR: eldk4.2 eldk5.1
powerpc/P2020DS_36BIT                   FAILED FOR: eldk4.2
powerpc/PMC440                          FAILED FOR: eldk4.2 eldk5.1
powerpc/TQM8541                         FAILED FOR: eldk4.2
powerpc/TQM8555                         FAILED FOR: eldk4.2

If you need logs, please contact me, I'll provide them.

Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Marek Vasut

author

2012-03-31 17:14 UTC #7 lore raw

Dear Simon Glass,

Quoted 11 lines

Hi Marek,
Quoted 3 lines · Marek Vasut
Hello guys,
we now have exactly these boards not building for -RC1, can you please
look into
Quoted 1 line
it?:
Do you build all archs including m68k, nds32, etc.?

Only ARM and PPC @ denx.

I build ARMEL, ARMHF, PPC, MIPS, MIPSEL, X86 and planning to build sandbox @ dorms. I also do DUTS testing on qemu/x86, planning to extend it further though.

Quoted 24 lines

Regards,
Simon

Quoted 20 lines

arm/flea3                               FAILED FOR: eldk4.2 eldk5.1
arm/hawkboard                           FAILED FOR: eldk4.2
arm/hawkboard_uart                      FAILED FOR: eldk4.2
arm/highbank                            FAILED FOR: eldk4.2
arm/mx35pdk                             FAILED FOR: eldk4.2 eldk5.1
arm/seaboard                            FAILED FOR: eldk4.2 eldk5.1
arm/ventana                             FAILED FOR: eldk4.2 eldk5.1
powerpc/P2020DS_36BIT                   FAILED FOR: eldk4.2
powerpc/PMC440                          FAILED FOR: eldk4.2 eldk5.1
powerpc/TQM8541                         FAILED FOR: eldk4.2
powerpc/TQM8555                         FAILED FOR: eldk4.2

If you need logs, please contact me, I'll provide them.

Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Best regards,
Marek Vasut

Tom Rini

2012-04-02 15:54 UTC #8 lore raw

In reply to Marek Vasut

Quoted 4 lines · Marek Vasut

Hello guys,
we now have exactly these boards not building for -RC1, can you please look into it?:

[snip]

Quoted 2 lines

arm/hawkboard FAILED FOR: eldk4.2
arm/hawkboard_uart FAILED FOR: eldk4.2

SPL link failure. Newer toolchains give us a built-in udelay, and we provide __udelay but not udelay on these boards since we don't use CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size bloat. Not sure what we want to do about this, and the last thread or two about this was unresolved.

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120402/523b19bf/attachment.pgp>

Marek Vasut

author

2012-04-02 16:10 UTC #9 lore raw

Dear Tom Rini,

Quoted 9 lines · Marek Vasut

Quoted 6 lines
Hello guys,
we now have exactly these boards not building for -RC1, can you please look into
it?:
[snip]

Quoted 8 lines

Quoted 2 lines
arm/hawkboard FAILED FOR: eldk4.2
arm/hawkboard_uart FAILED FOR: eldk4.2
SPL link failure. Newer toolchains give us a built-in udelay, and we provide __udelay but not udelay on these boards since we don't use CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size bloat. Not sure what we want to do about this, and the last thread or two about this was unresolved.

But we have --gc-sections and stuff like that so unneeded bloat should be removed.

And it's not only this, I see also problem with lldiv.

Configuring for hawkboard board... arch/arm/cpu/arm926ejs/davinci/libdavinci.o: In function `lldiv':
/workspace/compiler/eldk4.2/device/arm___hawkboard/include/div64.h:45: undefined reference to `__div64_32'
drivers/mtd/nand/libnand.o: In function `nand_command':
/workspace/compiler/eldk4.2/device/arm___hawkboard/drivers/mtd/nand/nand_base.c:591:
undefined reference to `udelay' /workspace/compiler/eldk4.2/device/arm___hawkboard/drivers/mtd/nand/nand_base.c:607:
undefined reference to `udelay' /workspace/compiler/eldk4.2/device/arm___hawkboard/drivers/mtd/nand/nand_base.c:613:
undefined reference to `udelay'
make[1]: *** [/workspace/compiler/eldk4.2/device/arm___hawkboard/spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl.bin] Error 2
text data bss dec hex filename
191820 6388 54764 252972 3dc2c ./u-boot

--------------------- SUMMARY ---------------------------- Boards compiled: 1
Boards with warnings or errors: 1 ( hawkboard )
----------------------------------------------------------

Best regards,
Marek Vasut

Tom Rini

2012-04-02 16:21 UTC #10 lore raw

Quoted 14 lines · Marek Vasut

Dear Tom Rini,
Quoted 12 lines · Marek Vasut
Quoted 6 lines
Hello guys,
we now have exactly these boards not building for -RC1, can you please look into
it?:
[snip]
Quoted 2 lines
arm/hawkboard FAILED FOR: eldk4.2
arm/hawkboard_uart FAILED FOR: eldk4.2

Quoted 8 lines

Quoted 5 lines
SPL link failure. Newer toolchains give us a built-in udelay, and we provide __udelay but not udelay on these boards since we don't use CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size bloat. Not sure what we want to do about this, and the last thread or two about this was unresolved.
But we have --gc-sections and stuff like that so unneeded bloat should be removed.

OK, in this case --gc-sections and how our code is structured work together and a quick for each symbol in spl/libgeneric.o check of spl/u-boot-spl shows nothing unneeded added with ELDK4.2 and with newer toolchains nothing at all added.

Quoted 1 line

And it's not only this, I see also problem with lldiv.

Same thing, built-in vs not.

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120402/3eb42349/attachment.pgp>

Marek Vasut

author

2012-04-02 16:30 UTC #11 lore raw

Dear Tom Rini,

Quoted 24 lines · Marek Vasut

Quoted 14 lines
Dear Tom Rini,
Quoted 12 lines · Marek Vasut
Quoted 6 lines
Hello guys,
we now have exactly these boards not building for -RC1, can you please look into
it?:
[snip]
Quoted 2 lines
arm/hawkboard FAILED FOR: eldk4.2
arm/hawkboard_uart FAILED FOR: eldk4.2
Quoted 8 lines
Quoted 5 lines
SPL link failure. Newer toolchains give us a built-in udelay, and we provide __udelay but not udelay on these boards since we don't use CONFIG_SPL_LIBGENERIC_SUPPORT and adding that in might be a fatal size bloat. Not sure what we want to do about this, and the last thread or two about this was unresolved.
But we have --gc-sections and stuff like that so unneeded bloat should be removed.

Quoted 8 lines

OK, in this case --gc-sections and how our code is structured work together and a quick for each symbol in spl/libgeneric.o check of spl/u-boot-spl shows nothing unneeded added with ELDK4.2 and with newer toolchains nothing at all added.
Quoted 1 line
And it's not only this, I see also problem with lldiv.
Same thing, built-in vs not.

So I can expect a patch?

Best regards,
Marek Vasut