[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini]

Hey all,

It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
size of the changes here and I did remember to sync the defconfigs prior
to tagging.

If anyone has critical fixes I've missed or some Kconfig migrations
(that I can prove out as correct), please speak up.

Things look on track for -rc3 on July 3rd and release on July 10th.
Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170619/69d95c44/attachment.sig>

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

On Tue, Jun 20, 2017 at 1:47 AM, Tom Rini <trini@konsulko.com> wrote:
> Hey all,
>
> It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
> size of the changes here and I did remember to sync the defconfigs prior
> to tagging.
>
> If anyone has critical fixes I've missed or some Kconfig migrations
> (that I can prove out as correct), please speak up.
>
> Things look on track for -rc3 on July 3rd and release on July 10th.
> Thanks all!

I'm seeing failures/regression in this cycle (both RC1 and RC2)
building a lot of the boards, I suspect this is a difference between
using upstream (with python support patches) dtc vs the in-tree one.
We use the upstream one to ensure we get consistency across all dtc
consumers so it would be nice to have the same functionality as prior
releases.

Peter

  gcc -Wp,-MD,spl/drivers/mmc/.sunxi_mmc.o.d  -nostdinc -isystem
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/7/include -Iinclude
-I/builddir/build/BUILD/u-boot-2017.07-rc2/include
-I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/include -include
/builddir/build/BUILD/u-boot-2017.07-rc2/include/linux/kconfig.h
-I/builddir/build/BUILD/u-boot-2017.07-rc2/spl/drivers/mmc
-Ispl/drivers/mmc -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD -Wall
-Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding
-Os -fno-stack-protector -fno-delete-null-pointer-checks -g
-fstack-usage -Wno-format-nonliteral -Werror=date-time
-ffunction-sections -fdata-sections -D__ARM__ -Wa,-mimplicit-it=always
-mthumb -mthumb-interwork -mabi=aapcs-linux -mno-unaligned-access
-ffunction-sections -fdata-sections -fno-common -ffixed-r9
-msoft-float -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7
-I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/mach-sunxi/include
   -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sunxi_mmc)"
-D"KBUILD_MODNAME=KBUILD_STR(sunxi_mmc)" -c -o
spl/drivers/mmc/sunxi_mmc.o
/builddir/build/BUILD/u-boot-2017.07-rc2/drivers/mmc/sunxi_mmc.c
   ld.bfd     -r -o spl/drivers/serial/built-in.o
spl/drivers/serial/serial.o spl/drivers/serial/serial_ns16550.o
spl/drivers/serial/ns16550.o
   ld.bfd     -r -o spl/drivers/mmc/built-in.o spl/drivers/mmc/mmc.o
spl/drivers/mmc/mmc_legacy.o spl/drivers/mmc/sunxi_mmc.o
   ld.bfd     -r -o spl/drivers/built-in.o spl/drivers/i2c/built-in.o
spl/drivers/gpio/built-in.o spl/drivers/mmc/built-in.o
spl/drivers/serial/built-in.o spl/drivers/power/built-in.o
spl/drivers/power/pmic/built-in.o
spl/drivers/power/regulator/built-in.o spl/drivers/block/built-in.o
  (cd spl && ld.bfd   -T u-boot-spl.lds  --gc-sections -Bstatic
--gc-sections  --no-dynamic-linker -Ttext 0x60
arch/arm/cpu/armv7/start.o --start-group
arch/arm/mach-sunxi/built-in.o arch/arm/cpu/armv7/built-in.o
arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/sunxi/built-in.o
common/spl/built-in.o common/init/built-in.o common/built-in.o
cmd/built-in.o lib/built-in.o disk/built-in.o drivers/built-in.o
dts/built-in.o fs/built-in.o  --end-group arch/arm/lib/eabi_compat.o
arch/arm/lib/lib.a -Map u-boot-spl.map -o u-boot-spl)
  objcopy  -j .text -j .secure_text -j .secure_data -j .rodata -j
.hash -j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn -j
.dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel  -O binary
spl/u-boot-spl spl/u-boot-spl-nodtb.bin
  cp spl/u-boot-spl-nodtb.bin spl/u-boot-spl.bin
  ./tools/mksunxiboot --default-dt "sun4i-a10-olinuxino-lime"
spl/u-boot-spl.bin spl/sunxi-spl.bin
  /builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman -d
u-boot.dtb -O . -I . -I
/builddir/build/BUILD/u-boot-2017.07-rc2/board/sunxi spl/sunxi-spl.bin
Traceback (most recent call last):
  File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman",
line 32, in <module>
    import control
  File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/control.py",
line 15, in <module>
    import fdt
  File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/../dtoc/fdt.py",
line 13, in <module>
    import libfdt
  File "tools/libfdt.py", line 612, in <module>
    FDT_ERR_TOODEEP = _libfdt.FDT_ERR_TOODEEP
AttributeError: 'module' object has no attribute 'FDT_ERR_TOODEEP'
make[1]: *** [/builddir/build/BUILD/u-boot-2017.07-rc2/Makefile:1130:
u-boot-sunxi-with-spl.bin] Error 1

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini]

On Tue, Jun 20, 2017 at 11:15:19AM +0100, Peter Robinson wrote:
> On Tue, Jun 20, 2017 at 1:47 AM, Tom Rini <trini@konsulko.com> wrote:
> > Hey all,
> >
> > It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
> > size of the changes here and I did remember to sync the defconfigs prior
> > to tagging.
> >
> > If anyone has critical fixes I've missed or some Kconfig migrations
> > (that I can prove out as correct), please speak up.
> >
> > Things look on track for -rc3 on July 3rd and release on July 10th.
> > Thanks all!
> 
> I'm seeing failures/regression in this cycle (both RC1 and RC2)
> building a lot of the boards, I suspect this is a difference between
> using upstream (with python support patches) dtc vs the in-tree one.
> We use the upstream one to ensure we get consistency across all dtc
> consumers so it would be nice to have the same functionality as prior
> releases.
> 
> Peter
> 
>   gcc -Wp,-MD,spl/drivers/mmc/.sunxi_mmc.o.d  -nostdinc -isystem
> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/7/include -Iinclude
> -I/builddir/build/BUILD/u-boot-2017.07-rc2/include
> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/include -include
> /builddir/build/BUILD/u-boot-2017.07-rc2/include/linux/kconfig.h
> -I/builddir/build/BUILD/u-boot-2017.07-rc2/spl/drivers/mmc
> -Ispl/drivers/mmc -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD -Wall
> -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding
> -Os -fno-stack-protector -fno-delete-null-pointer-checks -g
> -fstack-usage -Wno-format-nonliteral -Werror=date-time
> -ffunction-sections -fdata-sections -D__ARM__ -Wa,-mimplicit-it=always
> -mthumb -mthumb-interwork -mabi=aapcs-linux -mno-unaligned-access
> -ffunction-sections -fdata-sections -fno-common -ffixed-r9
> -msoft-float -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7
> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/mach-sunxi/include
>    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sunxi_mmc)"
> -D"KBUILD_MODNAME=KBUILD_STR(sunxi_mmc)" -c -o
> spl/drivers/mmc/sunxi_mmc.o
> /builddir/build/BUILD/u-boot-2017.07-rc2/drivers/mmc/sunxi_mmc.c
>    ld.bfd     -r -o spl/drivers/serial/built-in.o
> spl/drivers/serial/serial.o spl/drivers/serial/serial_ns16550.o
> spl/drivers/serial/ns16550.o
>    ld.bfd     -r -o spl/drivers/mmc/built-in.o spl/drivers/mmc/mmc.o
> spl/drivers/mmc/mmc_legacy.o spl/drivers/mmc/sunxi_mmc.o
>    ld.bfd     -r -o spl/drivers/built-in.o spl/drivers/i2c/built-in.o
> spl/drivers/gpio/built-in.o spl/drivers/mmc/built-in.o
> spl/drivers/serial/built-in.o spl/drivers/power/built-in.o
> spl/drivers/power/pmic/built-in.o
> spl/drivers/power/regulator/built-in.o spl/drivers/block/built-in.o
>   (cd spl && ld.bfd   -T u-boot-spl.lds  --gc-sections -Bstatic
> --gc-sections  --no-dynamic-linker -Ttext 0x60
> arch/arm/cpu/armv7/start.o --start-group
> arch/arm/mach-sunxi/built-in.o arch/arm/cpu/armv7/built-in.o
> arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/sunxi/built-in.o
> common/spl/built-in.o common/init/built-in.o common/built-in.o
> cmd/built-in.o lib/built-in.o disk/built-in.o drivers/built-in.o
> dts/built-in.o fs/built-in.o  --end-group arch/arm/lib/eabi_compat.o
> arch/arm/lib/lib.a -Map u-boot-spl.map -o u-boot-spl)
>   objcopy  -j .text -j .secure_text -j .secure_data -j .rodata -j
> .hash -j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn -j
> .dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel  -O binary
> spl/u-boot-spl spl/u-boot-spl-nodtb.bin
>   cp spl/u-boot-spl-nodtb.bin spl/u-boot-spl.bin
>   ./tools/mksunxiboot --default-dt "sun4i-a10-olinuxino-lime"
> spl/u-boot-spl.bin spl/sunxi-spl.bin
>   /builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman -d
> u-boot.dtb -O . -I . -I
> /builddir/build/BUILD/u-boot-2017.07-rc2/board/sunxi spl/sunxi-spl.bin
> Traceback (most recent call last):
>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman",
> line 32, in <module>
>     import control
>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/control.py",
> line 15, in <module>
>     import fdt
>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/../dtoc/fdt.py",
> line 13, in <module>
>     import libfdt
>   File "tools/libfdt.py", line 612, in <module>
>     FDT_ERR_TOODEEP = _libfdt.FDT_ERR_TOODEEP
> AttributeError: 'module' object has no attribute 'FDT_ERR_TOODEEP'
> make[1]: *** [/builddir/build/BUILD/u-boot-2017.07-rc2/Makefile:1130:
> u-boot-sunxi-with-spl.bin] Error 1

Simon, do you have some suggestions on what to do here?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170620/c805b3ff/attachment-0001.sig>

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

Hi,

On 20 June 2017 at 05:19, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Jun 20, 2017 at 11:15:19AM +0100, Peter Robinson wrote:
>> On Tue, Jun 20, 2017 at 1:47 AM, Tom Rini <trini@konsulko.com> wrote:
>> > Hey all,
>> >
>> > It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
>> > size of the changes here and I did remember to sync the defconfigs prior
>> > to tagging.
>> >
>> > If anyone has critical fixes I've missed or some Kconfig migrations
>> > (that I can prove out as correct), please speak up.
>> >
>> > Things look on track for -rc3 on July 3rd and release on July 10th.
>> > Thanks all!
>>
>> I'm seeing failures/regression in this cycle (both RC1 and RC2)
>> building a lot of the boards, I suspect this is a difference between
>> using upstream (with python support patches) dtc vs the in-tree one.
>> We use the upstream one to ensure we get consistency across all dtc
>> consumers so it would be nice to have the same functionality as prior
>> releases.
>>
>> Peter
>>
>>   gcc -Wp,-MD,spl/drivers/mmc/.sunxi_mmc.o.d  -nostdinc -isystem
>> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/7/include -Iinclude
>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/include
>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/include -include
>> /builddir/build/BUILD/u-boot-2017.07-rc2/include/linux/kconfig.h
>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/spl/drivers/mmc
>> -Ispl/drivers/mmc -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD -Wall
>> -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding
>> -Os -fno-stack-protector -fno-delete-null-pointer-checks -g
>> -fstack-usage -Wno-format-nonliteral -Werror=date-time
>> -ffunction-sections -fdata-sections -D__ARM__ -Wa,-mimplicit-it=always
>> -mthumb -mthumb-interwork -mabi=aapcs-linux -mno-unaligned-access
>> -ffunction-sections -fdata-sections -fno-common -ffixed-r9
>> -msoft-float -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7
>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/mach-sunxi/include
>>    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sunxi_mmc)"
>> -D"KBUILD_MODNAME=KBUILD_STR(sunxi_mmc)" -c -o
>> spl/drivers/mmc/sunxi_mmc.o
>> /builddir/build/BUILD/u-boot-2017.07-rc2/drivers/mmc/sunxi_mmc.c
>>    ld.bfd     -r -o spl/drivers/serial/built-in.o
>> spl/drivers/serial/serial.o spl/drivers/serial/serial_ns16550.o
>> spl/drivers/serial/ns16550.o
>>    ld.bfd     -r -o spl/drivers/mmc/built-in.o spl/drivers/mmc/mmc.o
>> spl/drivers/mmc/mmc_legacy.o spl/drivers/mmc/sunxi_mmc.o
>>    ld.bfd     -r -o spl/drivers/built-in.o spl/drivers/i2c/built-in.o
>> spl/drivers/gpio/built-in.o spl/drivers/mmc/built-in.o
>> spl/drivers/serial/built-in.o spl/drivers/power/built-in.o
>> spl/drivers/power/pmic/built-in.o
>> spl/drivers/power/regulator/built-in.o spl/drivers/block/built-in.o
>>   (cd spl && ld.bfd   -T u-boot-spl.lds  --gc-sections -Bstatic
>> --gc-sections  --no-dynamic-linker -Ttext 0x60
>> arch/arm/cpu/armv7/start.o --start-group
>> arch/arm/mach-sunxi/built-in.o arch/arm/cpu/armv7/built-in.o
>> arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/sunxi/built-in.o
>> common/spl/built-in.o common/init/built-in.o common/built-in.o
>> cmd/built-in.o lib/built-in.o disk/built-in.o drivers/built-in.o
>> dts/built-in.o fs/built-in.o  --end-group arch/arm/lib/eabi_compat.o
>> arch/arm/lib/lib.a -Map u-boot-spl.map -o u-boot-spl)
>>   objcopy  -j .text -j .secure_text -j .secure_data -j .rodata -j
>> .hash -j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn -j
>> .dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel  -O binary
>> spl/u-boot-spl spl/u-boot-spl-nodtb.bin
>>   cp spl/u-boot-spl-nodtb.bin spl/u-boot-spl.bin
>>   ./tools/mksunxiboot --default-dt "sun4i-a10-olinuxino-lime"
>> spl/u-boot-spl.bin spl/sunxi-spl.bin
>>   /builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman -d
>> u-boot.dtb -O . -I . -I
>> /builddir/build/BUILD/u-boot-2017.07-rc2/board/sunxi spl/sunxi-spl.bin
>> Traceback (most recent call last):
>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman",
>> line 32, in <module>
>>     import control
>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/control.py",
>> line 15, in <module>
>>     import fdt
>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/../dtoc/fdt.py",
>> line 13, in <module>
>>     import libfdt
>>   File "tools/libfdt.py", line 612, in <module>
>>     FDT_ERR_TOODEEP = _libfdt.FDT_ERR_TOODEEP
>> AttributeError: 'module' object has no attribute 'FDT_ERR_TOODEEP'
>> make[1]: *** [/builddir/build/BUILD/u-boot-2017.07-rc2/Makefile:1130:
>> u-boot-sunxi-with-spl.bin] Error 1
>
> Simon, do you have some suggestions on what to do here?  Thanks!
>
> --
> Tom

My guess is that there is already a libfdt.py in the system. Someone
else reported this too.

We could perhaps change the ordering in PYTHONPATH so that our one is first.

Regards,
Simon

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

> On 20 June 2017 at 05:19, Tom Rini <trini@konsulko.com> wrote:
>> On Tue, Jun 20, 2017 at 11:15:19AM +0100, Peter Robinson wrote:
>>> On Tue, Jun 20, 2017 at 1:47 AM, Tom Rini <trini@konsulko.com> wrote:
>>> > Hey all,
>>> >
>>> > It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
>>> > size of the changes here and I did remember to sync the defconfigs prior
>>> > to tagging.
>>> >
>>> > If anyone has critical fixes I've missed or some Kconfig migrations
>>> > (that I can prove out as correct), please speak up.
>>> >
>>> > Things look on track for -rc3 on July 3rd and release on July 10th.
>>> > Thanks all!
>>>
>>> I'm seeing failures/regression in this cycle (both RC1 and RC2)
>>> building a lot of the boards, I suspect this is a difference between
>>> using upstream (with python support patches) dtc vs the in-tree one.
>>> We use the upstream one to ensure we get consistency across all dtc
>>> consumers so it would be nice to have the same functionality as prior
>>> releases.
>>>
>>> Peter
>>>
>>>   gcc -Wp,-MD,spl/drivers/mmc/.sunxi_mmc.o.d  -nostdinc -isystem
>>> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/7/include -Iinclude
>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/include
>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/include -include
>>> /builddir/build/BUILD/u-boot-2017.07-rc2/include/linux/kconfig.h
>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/spl/drivers/mmc
>>> -Ispl/drivers/mmc -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD -Wall
>>> -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding
>>> -Os -fno-stack-protector -fno-delete-null-pointer-checks -g
>>> -fstack-usage -Wno-format-nonliteral -Werror=date-time
>>> -ffunction-sections -fdata-sections -D__ARM__ -Wa,-mimplicit-it=always
>>> -mthumb -mthumb-interwork -mabi=aapcs-linux -mno-unaligned-access
>>> -ffunction-sections -fdata-sections -fno-common -ffixed-r9
>>> -msoft-float -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7
>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/mach-sunxi/include
>>>    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sunxi_mmc)"
>>> -D"KBUILD_MODNAME=KBUILD_STR(sunxi_mmc)" -c -o
>>> spl/drivers/mmc/sunxi_mmc.o
>>> /builddir/build/BUILD/u-boot-2017.07-rc2/drivers/mmc/sunxi_mmc.c
>>>    ld.bfd     -r -o spl/drivers/serial/built-in.o
>>> spl/drivers/serial/serial.o spl/drivers/serial/serial_ns16550.o
>>> spl/drivers/serial/ns16550.o
>>>    ld.bfd     -r -o spl/drivers/mmc/built-in.o spl/drivers/mmc/mmc.o
>>> spl/drivers/mmc/mmc_legacy.o spl/drivers/mmc/sunxi_mmc.o
>>>    ld.bfd     -r -o spl/drivers/built-in.o spl/drivers/i2c/built-in.o
>>> spl/drivers/gpio/built-in.o spl/drivers/mmc/built-in.o
>>> spl/drivers/serial/built-in.o spl/drivers/power/built-in.o
>>> spl/drivers/power/pmic/built-in.o
>>> spl/drivers/power/regulator/built-in.o spl/drivers/block/built-in.o
>>>   (cd spl && ld.bfd   -T u-boot-spl.lds  --gc-sections -Bstatic
>>> --gc-sections  --no-dynamic-linker -Ttext 0x60
>>> arch/arm/cpu/armv7/start.o --start-group
>>> arch/arm/mach-sunxi/built-in.o arch/arm/cpu/armv7/built-in.o
>>> arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/sunxi/built-in.o
>>> common/spl/built-in.o common/init/built-in.o common/built-in.o
>>> cmd/built-in.o lib/built-in.o disk/built-in.o drivers/built-in.o
>>> dts/built-in.o fs/built-in.o  --end-group arch/arm/lib/eabi_compat.o
>>> arch/arm/lib/lib.a -Map u-boot-spl.map -o u-boot-spl)
>>>   objcopy  -j .text -j .secure_text -j .secure_data -j .rodata -j
>>> .hash -j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn -j
>>> .dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel  -O binary
>>> spl/u-boot-spl spl/u-boot-spl-nodtb.bin
>>>   cp spl/u-boot-spl-nodtb.bin spl/u-boot-spl.bin
>>>   ./tools/mksunxiboot --default-dt "sun4i-a10-olinuxino-lime"
>>> spl/u-boot-spl.bin spl/sunxi-spl.bin
>>>   /builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman -d
>>> u-boot.dtb -O . -I . -I
>>> /builddir/build/BUILD/u-boot-2017.07-rc2/board/sunxi spl/sunxi-spl.bin
>>> Traceback (most recent call last):
>>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman",
>>> line 32, in <module>
>>>     import control
>>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/control.py",
>>> line 15, in <module>
>>>     import fdt
>>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/../dtoc/fdt.py",
>>> line 13, in <module>
>>>     import libfdt
>>>   File "tools/libfdt.py", line 612, in <module>
>>>     FDT_ERR_TOODEEP = _libfdt.FDT_ERR_TOODEEP
>>> AttributeError: 'module' object has no attribute 'FDT_ERR_TOODEEP'
>>> make[1]: *** [/builddir/build/BUILD/u-boot-2017.07-rc2/Makefile:1130:
>>> u-boot-sunxi-with-spl.bin] Error 1
>>
>> Simon, do you have some suggestions on what to do here?  Thanks!
>>
>> --
>> Tom
>
> My guess is that there is already a libfdt.py in the system. Someone
> else reported this too.
>
> We could perhaps change the ordering in PYTHONPATH so that our one is first.

No, I'm not sure that's completely the case because I first saw a
related issue before my dtc had the python patch set added to it, I
would actually prefer to build with the distro dtc rather than a fork
of upstream like we use to.

Peter

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

Hi Peter,

On 20 June 2017 at 17:02, Peter Robinson <pbrobinson@gmail.com> wrote:
>> On 20 June 2017 at 05:19, Tom Rini <trini@konsulko.com> wrote:
>>> On Tue, Jun 20, 2017 at 11:15:19AM +0100, Peter Robinson wrote:
>>>> On Tue, Jun 20, 2017 at 1:47 AM, Tom Rini <trini@konsulko.com> wrote:
>>>> > Hey all,
>>>> >
>>>> > It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
>>>> > size of the changes here and I did remember to sync the defconfigs prior
>>>> > to tagging.
>>>> >
>>>> > If anyone has critical fixes I've missed or some Kconfig migrations
>>>> > (that I can prove out as correct), please speak up.
>>>> >
>>>> > Things look on track for -rc3 on July 3rd and release on July 10th.
>>>> > Thanks all!
>>>>
>>>> I'm seeing failures/regression in this cycle (both RC1 and RC2)
>>>> building a lot of the boards, I suspect this is a difference between
>>>> using upstream (with python support patches) dtc vs the in-tree one.
>>>> We use the upstream one to ensure we get consistency across all dtc
>>>> consumers so it would be nice to have the same functionality as prior
>>>> releases.
>>>>
>>>> Peter
>>>>
>>>>   gcc -Wp,-MD,spl/drivers/mmc/.sunxi_mmc.o.d  -nostdinc -isystem
>>>> /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/7/include -Iinclude
>>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/include
>>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/include -include
>>>> /builddir/build/BUILD/u-boot-2017.07-rc2/include/linux/kconfig.h
>>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/spl/drivers/mmc
>>>> -Ispl/drivers/mmc -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD -Wall
>>>> -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding
>>>> -Os -fno-stack-protector -fno-delete-null-pointer-checks -g
>>>> -fstack-usage -Wno-format-nonliteral -Werror=date-time
>>>> -ffunction-sections -fdata-sections -D__ARM__ -Wa,-mimplicit-it=always
>>>> -mthumb -mthumb-interwork -mabi=aapcs-linux -mno-unaligned-access
>>>> -ffunction-sections -fdata-sections -fno-common -ffixed-r9
>>>> -msoft-float -pipe -march=armv7-a -D__LINUX_ARM_ARCH__=7
>>>> -I/builddir/build/BUILD/u-boot-2017.07-rc2/arch/arm/mach-sunxi/include
>>>>    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sunxi_mmc)"
>>>> -D"KBUILD_MODNAME=KBUILD_STR(sunxi_mmc)" -c -o
>>>> spl/drivers/mmc/sunxi_mmc.o
>>>> /builddir/build/BUILD/u-boot-2017.07-rc2/drivers/mmc/sunxi_mmc.c
>>>>    ld.bfd     -r -o spl/drivers/serial/built-in.o
>>>> spl/drivers/serial/serial.o spl/drivers/serial/serial_ns16550.o
>>>> spl/drivers/serial/ns16550.o
>>>>    ld.bfd     -r -o spl/drivers/mmc/built-in.o spl/drivers/mmc/mmc.o
>>>> spl/drivers/mmc/mmc_legacy.o spl/drivers/mmc/sunxi_mmc.o
>>>>    ld.bfd     -r -o spl/drivers/built-in.o spl/drivers/i2c/built-in.o
>>>> spl/drivers/gpio/built-in.o spl/drivers/mmc/built-in.o
>>>> spl/drivers/serial/built-in.o spl/drivers/power/built-in.o
>>>> spl/drivers/power/pmic/built-in.o
>>>> spl/drivers/power/regulator/built-in.o spl/drivers/block/built-in.o
>>>>   (cd spl && ld.bfd   -T u-boot-spl.lds  --gc-sections -Bstatic
>>>> --gc-sections  --no-dynamic-linker -Ttext 0x60
>>>> arch/arm/cpu/armv7/start.o --start-group
>>>> arch/arm/mach-sunxi/built-in.o arch/arm/cpu/armv7/built-in.o
>>>> arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/sunxi/built-in.o
>>>> common/spl/built-in.o common/init/built-in.o common/built-in.o
>>>> cmd/built-in.o lib/built-in.o disk/built-in.o drivers/built-in.o
>>>> dts/built-in.o fs/built-in.o  --end-group arch/arm/lib/eabi_compat.o
>>>> arch/arm/lib/lib.a -Map u-boot-spl.map -o u-boot-spl)
>>>>   objcopy  -j .text -j .secure_text -j .secure_data -j .rodata -j
>>>> .hash -j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn -j
>>>> .dtb.init.rodata -j .efi_runtime -j .efi_runtime_rel  -O binary
>>>> spl/u-boot-spl spl/u-boot-spl-nodtb.bin
>>>>   cp spl/u-boot-spl-nodtb.bin spl/u-boot-spl.bin
>>>>   ./tools/mksunxiboot --default-dt "sun4i-a10-olinuxino-lime"
>>>> spl/u-boot-spl.bin spl/sunxi-spl.bin
>>>>   /builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman -d
>>>> u-boot.dtb -O . -I . -I
>>>> /builddir/build/BUILD/u-boot-2017.07-rc2/board/sunxi spl/sunxi-spl.bin
>>>> Traceback (most recent call last):
>>>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/binman",
>>>> line 32, in <module>
>>>>     import control
>>>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/control.py",
>>>> line 15, in <module>
>>>>     import fdt
>>>>   File "/builddir/build/BUILD/u-boot-2017.07-rc2/tools/binman/../dtoc/fdt.py",
>>>> line 13, in <module>
>>>>     import libfdt
>>>>   File "tools/libfdt.py", line 612, in <module>
>>>>     FDT_ERR_TOODEEP = _libfdt.FDT_ERR_TOODEEP
>>>> AttributeError: 'module' object has no attribute 'FDT_ERR_TOODEEP'
>>>> make[1]: *** [/builddir/build/BUILD/u-boot-2017.07-rc2/Makefile:1130:
>>>> u-boot-sunxi-with-spl.bin] Error 1
>>>
>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>>
>>> --
>>> Tom
>>
>> My guess is that there is already a libfdt.py in the system. Someone
>> else reported this too.
>>
>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>
> No, I'm not sure that's completely the case because I first saw a
> related issue before my dtc had the python patch set added to it, I
> would actually prefer to build with the distro dtc rather than a fork
> of upstream like we use to.

OK I think I see what is happening then. It seems to be picking up
_libfdt.so from your system and libfdy.py from U-Boot. If so that
seems like a bad idea at the best of times.

Despite upstreaming efforts we still have local libfdt changes in
U-Boot. The main one is fdtgrep. I did try to upstream it a while back
but failed. I've been thinking of trying again but have not mustered
the energy.

This particular error could probably be worked around in the short
term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
sort of thing? I think we should either use one libfdt module or the
other, not a mixture of the two

Regards,
Simon

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>>>
>>>> --
>>>> Tom
>>>
>>> My guess is that there is already a libfdt.py in the system. Someone
>>> else reported this too.
>>>
>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>>
>> No, I'm not sure that's completely the case because I first saw a
>> related issue before my dtc had the python patch set added to it, I
>> would actually prefer to build with the distro dtc rather than a fork
>> of upstream like we use to.
>
> OK I think I see what is happening then. It seems to be picking up
> _libfdt.so from your system and libfdy.py from U-Boot. If so that
> seems like a bad idea at the best of times.
>
> Despite upstreaming efforts we still have local libfdt changes in
> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
> but failed. I've been thinking of trying again but have not mustered
> the energy.
>
> This particular error could probably be worked around in the short
> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
> sort of thing? I think we should either use one libfdt module or the
> other, not a mixture of the two

I suspect your right but I don't want to get into a situation where
something might work in the kernel and and not in u-boot or
vice-versa, and as things like overlays come into play where they
could be applied to either the possible differences get greater and
from a distro PoV that increased the requirements of support and debug
and believe me people will do weird shit that they expect you to
magically fix with little information hence my reluctance to diverge.

Peter

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

Hi Peter,

On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>>>>
>>>>> --
>>>>> Tom
>>>>
>>>> My guess is that there is already a libfdt.py in the system. Someone
>>>> else reported this too.
>>>>
>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>>>
>>> No, I'm not sure that's completely the case because I first saw a
>>> related issue before my dtc had the python patch set added to it, I
>>> would actually prefer to build with the distro dtc rather than a fork
>>> of upstream like we use to.
>>
>> OK I think I see what is happening then. It seems to be picking up
>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>> seems like a bad idea at the best of times.
>>
>> Despite upstreaming efforts we still have local libfdt changes in
>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>> but failed. I've been thinking of trying again but have not mustered
>> the energy.
>>
>> This particular error could probably be worked around in the short
>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>> sort of thing? I think we should either use one libfdt module or the
>> other, not a mixture of the two
>
> I suspect your right but I don't want to get into a situation where
> something might work in the kernel and and not in u-boot or
> vice-versa, and as things like overlays come into play where they
> could be applied to either the possible differences get greater and
> from a distro PoV that increased the requirements of support and debug
> and believe me people will do weird shit that they expect you to
> magically fix with little information hence my reluctance to diverge.

I'm not sure what to do about this other than what I suggested. I
wonder it if is possible to detect the case where there is a mismatch
with the installation?

Regards,
Simon

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>>>>>
>>>>>> --
>>>>>> Tom
>>>>>
>>>>> My guess is that there is already a libfdt.py in the system. Someone
>>>>> else reported this too.
>>>>>
>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>>>>
>>>> No, I'm not sure that's completely the case because I first saw a
>>>> related issue before my dtc had the python patch set added to it, I
>>>> would actually prefer to build with the distro dtc rather than a fork
>>>> of upstream like we use to.
>>>
>>> OK I think I see what is happening then. It seems to be picking up
>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>>> seems like a bad idea at the best of times.
>>>
>>> Despite upstreaming efforts we still have local libfdt changes in
>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>>> but failed. I've been thinking of trying again but have not mustered
>>> the energy.
>>>
>>> This particular error could probably be worked around in the short
>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>>> sort of thing? I think we should either use one libfdt module or the
>>> other, not a mixture of the two
>>
>> I suspect your right but I don't want to get into a situation where
>> something might work in the kernel and and not in u-boot or
>> vice-versa, and as things like overlays come into play where they
>> could be applied to either the possible differences get greater and
>> from a distro PoV that increased the requirements of support and debug
>> and believe me people will do weird shit that they expect you to
>> magically fix with little information hence my reluctance to diverge.
>
> I'm not sure what to do about this other than what I suggested. I
> wonder it if is possible to detect the case where there is a mismatch
> with the installation?

Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
this, what does it do? Maybe provide an option to specify whether to
use external dtc or bundled?

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> Tom
>>>>>>
>>>>>> My guess is that there is already a libfdt.py in the system. Someone
>>>>>> else reported this too.
>>>>>>
>>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>>>>>
>>>>> No, I'm not sure that's completely the case because I first saw a
>>>>> related issue before my dtc had the python patch set added to it, I
>>>>> would actually prefer to build with the distro dtc rather than a fork
>>>>> of upstream like we use to.
>>>>
>>>> OK I think I see what is happening then. It seems to be picking up
>>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>>>> seems like a bad idea at the best of times.
>>>>
>>>> Despite upstreaming efforts we still have local libfdt changes in
>>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>>>> but failed. I've been thinking of trying again but have not mustered
>>>> the energy.
>>>>
>>>> This particular error could probably be worked around in the short
>>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>>>> sort of thing? I think we should either use one libfdt module or the
>>>> other, not a mixture of the two
>>>
>>> I suspect your right but I don't want to get into a situation where
>>> something might work in the kernel and and not in u-boot or
>>> vice-versa, and as things like overlays come into play where they
>>> could be applied to either the possible differences get greater and
>>> from a distro PoV that increased the requirements of support and debug
>>> and believe me people will do weird shit that they expect you to
>>> magically fix with little information hence my reluctance to diverge.
>>
>> I'm not sure what to do about this other than what I suggested. I
>> wonder it if is possible to detect the case where there is a mismatch
>> with the installation?
>
> Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
> this, what does it do? Maybe provide an option to specify whether to
> use external dtc or bundled?

So dropping dtc from our deps to try and get anything on 2017.07 built
I get for a bunch of devices I get this:

/builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
18: dtc: command not found
rm -f .tmp_quiet_recordmcount
*** Your dtc is too old, please upgrade to dtc 1.4 or newer

Can we please have some level of resolution for 2017.07 GA?

Peter

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini]

On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
> >>>>>>>
> >>>>>>> --
> >>>>>>> Tom
> >>>>>>
> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
> >>>>>> else reported this too.
> >>>>>>
> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
> >>>>>
> >>>>> No, I'm not sure that's completely the case because I first saw a
> >>>>> related issue before my dtc had the python patch set added to it, I
> >>>>> would actually prefer to build with the distro dtc rather than a fork
> >>>>> of upstream like we use to.
> >>>>
> >>>> OK I think I see what is happening then. It seems to be picking up
> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
> >>>> seems like a bad idea at the best of times.
> >>>>
> >>>> Despite upstreaming efforts we still have local libfdt changes in
> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
> >>>> but failed. I've been thinking of trying again but have not mustered
> >>>> the energy.
> >>>>
> >>>> This particular error could probably be worked around in the short
> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
> >>>> sort of thing? I think we should either use one libfdt module or the
> >>>> other, not a mixture of the two
> >>>
> >>> I suspect your right but I don't want to get into a situation where
> >>> something might work in the kernel and and not in u-boot or
> >>> vice-versa, and as things like overlays come into play where they
> >>> could be applied to either the possible differences get greater and
> >>> from a distro PoV that increased the requirements of support and debug
> >>> and believe me people will do weird shit that they expect you to
> >>> magically fix with little information hence my reluctance to diverge.
> >>
> >> I'm not sure what to do about this other than what I suggested. I
> >> wonder it if is possible to detect the case where there is a mismatch
> >> with the installation?
> >
> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
> > this, what does it do? Maybe provide an option to specify whether to
> > use external dtc or bundled?
> 
> So dropping dtc from our deps to try and get anything on 2017.07 built
> I get for a bunch of devices I get this:
> 
> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
> 18: dtc: command not found
> rm -f .tmp_quiet_recordmcount
> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
> 
> Can we please have some level of resolution for 2017.07 GA?

Can we short term do the thing where I guess it was PYTHONPATH gets
modified so that you only pick up U-Boot provided parts here?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170708/0203bfc5/attachment.sig>

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
> On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
>> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Tom
>> >>>>>>
>> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
>> >>>>>> else reported this too.
>> >>>>>>
>> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>> >>>>>
>> >>>>> No, I'm not sure that's completely the case because I first saw a
>> >>>>> related issue before my dtc had the python patch set added to it, I
>> >>>>> would actually prefer to build with the distro dtc rather than a fork
>> >>>>> of upstream like we use to.
>> >>>>
>> >>>> OK I think I see what is happening then. It seems to be picking up
>> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>> >>>> seems like a bad idea at the best of times.
>> >>>>
>> >>>> Despite upstreaming efforts we still have local libfdt changes in
>> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>> >>>> but failed. I've been thinking of trying again but have not mustered
>> >>>> the energy.
>> >>>>
>> >>>> This particular error could probably be worked around in the short
>> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>> >>>> sort of thing? I think we should either use one libfdt module or the
>> >>>> other, not a mixture of the two
>> >>>
>> >>> I suspect your right but I don't want to get into a situation where
>> >>> something might work in the kernel and and not in u-boot or
>> >>> vice-versa, and as things like overlays come into play where they
>> >>> could be applied to either the possible differences get greater and
>> >>> from a distro PoV that increased the requirements of support and debug
>> >>> and believe me people will do weird shit that they expect you to
>> >>> magically fix with little information hence my reluctance to diverge.
>> >>
>> >> I'm not sure what to do about this other than what I suggested. I
>> >> wonder it if is possible to detect the case where there is a mismatch
>> >> with the installation?
>> >
>> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
>> > this, what does it do? Maybe provide an option to specify whether to
>> > use external dtc or bundled?
>>
>> So dropping dtc from our deps to try and get anything on 2017.07 built
>> I get for a bunch of devices I get this:
>>
>> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
>> 18: dtc: command not found
>> rm -f .tmp_quiet_recordmcount
>> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
>>
>> Can we please have some level of resolution for 2017.07 GA?
>
> Can we short term do the thing where I guess it was PYTHONPATH gets
> modified so that you only pick up U-Boot provided parts here?

Sure, as long as we have a commitment to a read fix for 2017.09

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini]

On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote:
> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
> >> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> Tom
> >> >>>>>>
> >> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
> >> >>>>>> else reported this too.
> >> >>>>>>
> >> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
> >> >>>>>
> >> >>>>> No, I'm not sure that's completely the case because I first saw a
> >> >>>>> related issue before my dtc had the python patch set added to it, I
> >> >>>>> would actually prefer to build with the distro dtc rather than a fork
> >> >>>>> of upstream like we use to.
> >> >>>>
> >> >>>> OK I think I see what is happening then. It seems to be picking up
> >> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
> >> >>>> seems like a bad idea at the best of times.
> >> >>>>
> >> >>>> Despite upstreaming efforts we still have local libfdt changes in
> >> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
> >> >>>> but failed. I've been thinking of trying again but have not mustered
> >> >>>> the energy.
> >> >>>>
> >> >>>> This particular error could probably be worked around in the short
> >> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
> >> >>>> sort of thing? I think we should either use one libfdt module or the
> >> >>>> other, not a mixture of the two
> >> >>>
> >> >>> I suspect your right but I don't want to get into a situation where
> >> >>> something might work in the kernel and and not in u-boot or
> >> >>> vice-versa, and as things like overlays come into play where they
> >> >>> could be applied to either the possible differences get greater and
> >> >>> from a distro PoV that increased the requirements of support and debug
> >> >>> and believe me people will do weird shit that they expect you to
> >> >>> magically fix with little information hence my reluctance to diverge.
> >> >>
> >> >> I'm not sure what to do about this other than what I suggested. I
> >> >> wonder it if is possible to detect the case where there is a mismatch
> >> >> with the installation?
> >> >
> >> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
> >> > this, what does it do? Maybe provide an option to specify whether to
> >> > use external dtc or bundled?
> >>
> >> So dropping dtc from our deps to try and get anything on 2017.07 built
> >> I get for a bunch of devices I get this:
> >>
> >> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
> >> 18: dtc: command not found
> >> rm -f .tmp_quiet_recordmcount
> >> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
> >>
> >> Can we please have some level of resolution for 2017.07 GA?
> >
> > Can we short term do the thing where I guess it was PYTHONPATH gets
> > modified so that you only pick up U-Boot provided parts here?
> 
> Sure, as long as we have a commitment to a read fix for 2017.09

The "real" fix is to get upstream libfdt stuff in sync with us again,
yes?  If so, yes, I think we can agree that we need to sync up with them
and get on the same page.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170709/4b3c320a/attachment.sig>

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

Hi,

On 9 July 2017 at 06:49, Tom Rini <trini@konsulko.com> wrote:
> On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote:
>> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
>> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
>> >> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>> >> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>> >> >>>>>>>
>> >> >>>>>>> --
>> >> >>>>>>> Tom
>> >> >>>>>>
>> >> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
>> >> >>>>>> else reported this too.
>> >> >>>>>>
>> >> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>> >> >>>>>
>> >> >>>>> No, I'm not sure that's completely the case because I first saw a
>> >> >>>>> related issue before my dtc had the python patch set added to it, I
>> >> >>>>> would actually prefer to build with the distro dtc rather than a fork
>> >> >>>>> of upstream like we use to.
>> >> >>>>
>> >> >>>> OK I think I see what is happening then. It seems to be picking up
>> >> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>> >> >>>> seems like a bad idea at the best of times.
>> >> >>>>
>> >> >>>> Despite upstreaming efforts we still have local libfdt changes in
>> >> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>> >> >>>> but failed. I've been thinking of trying again but have not mustered
>> >> >>>> the energy.
>> >> >>>>
>> >> >>>> This particular error could probably be worked around in the short
>> >> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>> >> >>>> sort of thing? I think we should either use one libfdt module or the
>> >> >>>> other, not a mixture of the two
>> >> >>>
>> >> >>> I suspect your right but I don't want to get into a situation where
>> >> >>> something might work in the kernel and and not in u-boot or
>> >> >>> vice-versa, and as things like overlays come into play where they
>> >> >>> could be applied to either the possible differences get greater and
>> >> >>> from a distro PoV that increased the requirements of support and debug
>> >> >>> and believe me people will do weird shit that they expect you to
>> >> >>> magically fix with little information hence my reluctance to diverge.
>> >> >>
>> >> >> I'm not sure what to do about this other than what I suggested. I
>> >> >> wonder it if is possible to detect the case where there is a mismatch
>> >> >> with the installation?
>> >> >
>> >> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
>> >> > this, what does it do? Maybe provide an option to specify whether to
>> >> > use external dtc or bundled?
>> >>
>> >> So dropping dtc from our deps to try and get anything on 2017.07 built
>> >> I get for a bunch of devices I get this:
>> >>
>> >> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
>> >> 18: dtc: command not found
>> >> rm -f .tmp_quiet_recordmcount
>> >> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
>> >>
>> >> Can we please have some level of resolution for 2017.07 GA?
>> >
>> > Can we short term do the thing where I guess it was PYTHONPATH gets
>> > modified so that you only pick up U-Boot provided parts here?
>>
>> Sure, as long as we have a commitment to a read fix for 2017.09
>
> The "real" fix is to get upstream libfdt stuff in sync with us again,
> yes?  If so, yes, I think we can agree that we need to sync up with them
> and get on the same page.

It would be easy enough to drop the new error. I think that would fix
the current problem. I synced libfdt after the Python library was
applied upstream, so it may be possible to mix and match dtc now.

Re fdtgrep I did send fdtgrep patches to the list a long time ago but
it did not go anywhere. For v3 there was a long delay and then this
comment:

https://www.spinics.net/lists/devicetree-compiler/msg00108.html

I have been meaning to try again with something smaller as I think it
is a useful tool.

Regards,
Simon

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini]

On Sun, Jul 09, 2017 at 12:38:19PM -0600, Simon Glass wrote:
> Hi,
> 
> On 9 July 2017 at 06:49, Tom Rini <trini@konsulko.com> wrote:
> > On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote:
> >> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
> >> >> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> >> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
> >> >> >>>>>>>
> >> >> >>>>>>> --
> >> >> >>>>>>> Tom
> >> >> >>>>>>
> >> >> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
> >> >> >>>>>> else reported this too.
> >> >> >>>>>>
> >> >> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
> >> >> >>>>>
> >> >> >>>>> No, I'm not sure that's completely the case because I first saw a
> >> >> >>>>> related issue before my dtc had the python patch set added to it, I
> >> >> >>>>> would actually prefer to build with the distro dtc rather than a fork
> >> >> >>>>> of upstream like we use to.
> >> >> >>>>
> >> >> >>>> OK I think I see what is happening then. It seems to be picking up
> >> >> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
> >> >> >>>> seems like a bad idea at the best of times.
> >> >> >>>>
> >> >> >>>> Despite upstreaming efforts we still have local libfdt changes in
> >> >> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
> >> >> >>>> but failed. I've been thinking of trying again but have not mustered
> >> >> >>>> the energy.
> >> >> >>>>
> >> >> >>>> This particular error could probably be worked around in the short
> >> >> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
> >> >> >>>> sort of thing? I think we should either use one libfdt module or the
> >> >> >>>> other, not a mixture of the two
> >> >> >>>
> >> >> >>> I suspect your right but I don't want to get into a situation where
> >> >> >>> something might work in the kernel and and not in u-boot or
> >> >> >>> vice-versa, and as things like overlays come into play where they
> >> >> >>> could be applied to either the possible differences get greater and
> >> >> >>> from a distro PoV that increased the requirements of support and debug
> >> >> >>> and believe me people will do weird shit that they expect you to
> >> >> >>> magically fix with little information hence my reluctance to diverge.
> >> >> >>
> >> >> >> I'm not sure what to do about this other than what I suggested. I
> >> >> >> wonder it if is possible to detect the case where there is a mismatch
> >> >> >> with the installation?
> >> >> >
> >> >> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
> >> >> > this, what does it do? Maybe provide an option to specify whether to
> >> >> > use external dtc or bundled?
> >> >>
> >> >> So dropping dtc from our deps to try and get anything on 2017.07 built
> >> >> I get for a bunch of devices I get this:
> >> >>
> >> >> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
> >> >> 18: dtc: command not found
> >> >> rm -f .tmp_quiet_recordmcount
> >> >> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
> >> >>
> >> >> Can we please have some level of resolution for 2017.07 GA?
> >> >
> >> > Can we short term do the thing where I guess it was PYTHONPATH gets
> >> > modified so that you only pick up U-Boot provided parts here?
> >>
> >> Sure, as long as we have a commitment to a read fix for 2017.09
> >
> > The "real" fix is to get upstream libfdt stuff in sync with us again,
> > yes?  If so, yes, I think we can agree that we need to sync up with them
> > and get on the same page.
> 
> It would be easy enough to drop the new error. I think that would fix
> the current problem. I synced libfdt after the Python library was
> applied upstream, so it may be possible to mix and match dtc now.
> 
> Re fdtgrep I did send fdtgrep patches to the list a long time ago but
> it did not go anywhere. For v3 there was a long delay and then this
> comment:
> 
> https://www.spinics.net/lists/devicetree-compiler/msg00108.html
> 
> I have been meaning to try again with something smaller as I think it
> is a useful tool.

OK, so I need a patch for the moment then please, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170709/a4230082/attachment.sig>

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

Hi Tom,

On 9 July 2017 at 16:36, Tom Rini <trini@konsulko.com> wrote:
> On Sun, Jul 09, 2017 at 12:38:19PM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 9 July 2017 at 06:49, Tom Rini <trini@konsulko.com> wrote:
>> > On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote:
>> >> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
>> >> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
>> >> >> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>> >> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>> >> >> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>> >> >> >>>>>>>
>> >> >> >>>>>>> --
>> >> >> >>>>>>> Tom
>> >> >> >>>>>>
>> >> >> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
>> >> >> >>>>>> else reported this too.
>> >> >> >>>>>>
>> >> >> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>> >> >> >>>>>
>> >> >> >>>>> No, I'm not sure that's completely the case because I first saw a
>> >> >> >>>>> related issue before my dtc had the python patch set added to it, I
>> >> >> >>>>> would actually prefer to build with the distro dtc rather than a fork
>> >> >> >>>>> of upstream like we use to.
>> >> >> >>>>
>> >> >> >>>> OK I think I see what is happening then. It seems to be picking up
>> >> >> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>> >> >> >>>> seems like a bad idea at the best of times.
>> >> >> >>>>
>> >> >> >>>> Despite upstreaming efforts we still have local libfdt changes in
>> >> >> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>> >> >> >>>> but failed. I've been thinking of trying again but have not mustered
>> >> >> >>>> the energy.
>> >> >> >>>>
>> >> >> >>>> This particular error could probably be worked around in the short
>> >> >> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>> >> >> >>>> sort of thing? I think we should either use one libfdt module or the
>> >> >> >>>> other, not a mixture of the two
>> >> >> >>>
>> >> >> >>> I suspect your right but I don't want to get into a situation where
>> >> >> >>> something might work in the kernel and and not in u-boot or
>> >> >> >>> vice-versa, and as things like overlays come into play where they
>> >> >> >>> could be applied to either the possible differences get greater and
>> >> >> >>> from a distro PoV that increased the requirements of support and debug
>> >> >> >>> and believe me people will do weird shit that they expect you to
>> >> >> >>> magically fix with little information hence my reluctance to diverge.
>> >> >> >>
>> >> >> >> I'm not sure what to do about this other than what I suggested. I
>> >> >> >> wonder it if is possible to detect the case where there is a mismatch
>> >> >> >> with the installation?
>> >> >> >
>> >> >> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
>> >> >> > this, what does it do? Maybe provide an option to specify whether to
>> >> >> > use external dtc or bundled?
>> >> >>
>> >> >> So dropping dtc from our deps to try and get anything on 2017.07 built
>> >> >> I get for a bunch of devices I get this:
>> >> >>
>> >> >> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
>> >> >> 18: dtc: command not found
>> >> >> rm -f .tmp_quiet_recordmcount
>> >> >> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
>> >> >>
>> >> >> Can we please have some level of resolution for 2017.07 GA?
>> >> >
>> >> > Can we short term do the thing where I guess it was PYTHONPATH gets
>> >> > modified so that you only pick up U-Boot provided parts here?
>> >>
>> >> Sure, as long as we have a commitment to a read fix for 2017.09
>> >
>> > The "real" fix is to get upstream libfdt stuff in sync with us again,
>> > yes?  If so, yes, I think we can agree that we need to sync up with them
>> > and get on the same page.
>>
>> It would be easy enough to drop the new error. I think that would fix
>> the current problem. I synced libfdt after the Python library was
>> applied upstream, so it may be possible to mix and match dtc now.
>>
>> Re fdtgrep I did send fdtgrep patches to the list a long time ago but
>> it did not go anywhere. For v3 there was a long delay and then this
>> comment:
>>
>> https://www.spinics.net/lists/devicetree-compiler/msg00108.html
>>
>> I have been meaning to try again with something smaller as I think it
>> is a useful tool.
>
> OK, so I need a patch for the moment then please, thanks!

OK I just sent something that might help. Peter can you please test and advise?

Regards,
Simon

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Peter Robinson]

On Mon, Jul 10, 2017 at 4:31 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On 9 July 2017 at 16:36, Tom Rini <trini@konsulko.com> wrote:
>> On Sun, Jul 09, 2017 at 12:38:19PM -0600, Simon Glass wrote:
>>> Hi,
>>>
>>> On 9 July 2017 at 06:49, Tom Rini <trini@konsulko.com> wrote:
>>> > On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote:
>>> >> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
>>> >> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
>>> >> >> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>>> >> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>>> >> >> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> --
>>> >> >> >>>>>>> Tom
>>> >> >> >>>>>>
>>> >> >> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
>>> >> >> >>>>>> else reported this too.
>>> >> >> >>>>>>
>>> >> >> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>>> >> >> >>>>>
>>> >> >> >>>>> No, I'm not sure that's completely the case because I first saw a
>>> >> >> >>>>> related issue before my dtc had the python patch set added to it, I
>>> >> >> >>>>> would actually prefer to build with the distro dtc rather than a fork
>>> >> >> >>>>> of upstream like we use to.
>>> >> >> >>>>
>>> >> >> >>>> OK I think I see what is happening then. It seems to be picking up
>>> >> >> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>>> >> >> >>>> seems like a bad idea at the best of times.
>>> >> >> >>>>
>>> >> >> >>>> Despite upstreaming efforts we still have local libfdt changes in
>>> >> >> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>>> >> >> >>>> but failed. I've been thinking of trying again but have not mustered
>>> >> >> >>>> the energy.
>>> >> >> >>>>
>>> >> >> >>>> This particular error could probably be worked around in the short
>>> >> >> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>>> >> >> >>>> sort of thing? I think we should either use one libfdt module or the
>>> >> >> >>>> other, not a mixture of the two
>>> >> >> >>>
>>> >> >> >>> I suspect your right but I don't want to get into a situation where
>>> >> >> >>> something might work in the kernel and and not in u-boot or
>>> >> >> >>> vice-versa, and as things like overlays come into play where they
>>> >> >> >>> could be applied to either the possible differences get greater and
>>> >> >> >>> from a distro PoV that increased the requirements of support and debug
>>> >> >> >>> and believe me people will do weird shit that they expect you to
>>> >> >> >>> magically fix with little information hence my reluctance to diverge.
>>> >> >> >>
>>> >> >> >> I'm not sure what to do about this other than what I suggested. I
>>> >> >> >> wonder it if is possible to detect the case where there is a mismatch
>>> >> >> >> with the installation?
>>> >> >> >
>>> >> >> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
>>> >> >> > this, what does it do? Maybe provide an option to specify whether to
>>> >> >> > use external dtc or bundled?
>>> >> >>
>>> >> >> So dropping dtc from our deps to try and get anything on 2017.07 built
>>> >> >> I get for a bunch of devices I get this:
>>> >> >>
>>> >> >> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
>>> >> >> 18: dtc: command not found
>>> >> >> rm -f .tmp_quiet_recordmcount
>>> >> >> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
>>> >> >>
>>> >> >> Can we please have some level of resolution for 2017.07 GA?
>>> >> >
>>> >> > Can we short term do the thing where I guess it was PYTHONPATH gets
>>> >> > modified so that you only pick up U-Boot provided parts here?
>>> >>
>>> >> Sure, as long as we have a commitment to a read fix for 2017.09
>>> >
>>> > The "real" fix is to get upstream libfdt stuff in sync with us again,
>>> > yes?  If so, yes, I think we can agree that we need to sync up with them
>>> > and get on the same page.
>>>
>>> It would be easy enough to drop the new error. I think that would fix
>>> the current problem. I synced libfdt after the Python library was
>>> applied upstream, so it may be possible to mix and match dtc now.
>>>
>>> Re fdtgrep I did send fdtgrep patches to the list a long time ago but
>>> it did not go anywhere. For v3 there was a long delay and then this
>>> comment:
>>>
>>> https://www.spinics.net/lists/devicetree-compiler/msg00108.html
>>>
>>> I have been meaning to try again with something smaller as I think it
>>> is a useful tool.
>>
>> OK, so I need a patch for the moment then please, thanks!
>
> OK I just sent something that might help. Peter can you please test and advise?

Testing it now.

Peter

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

On 10 July 2017 at 02:26, Peter Robinson <pbrobinson@gmail.com> wrote:
> On Mon, Jul 10, 2017 at 4:31 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Tom,
>>
>> On 9 July 2017 at 16:36, Tom Rini <trini@konsulko.com> wrote:
>>> On Sun, Jul 09, 2017 at 12:38:19PM -0600, Simon Glass wrote:
>>>> Hi,
>>>>
>>>> On 9 July 2017 at 06:49, Tom Rini <trini@konsulko.com> wrote:
>>>> > On Sun, Jul 09, 2017 at 10:45:52AM +0100, Peter Robinson wrote:
>>>> >> On Sat, Jul 8, 2017 at 1:21 PM, Tom Rini <trini@konsulko.com> wrote:
>>>> >> > On Sat, Jul 08, 2017 at 09:27:59AM +0100, Peter Robinson wrote:
>>>> >> >> On Wed, Jul 5, 2017 at 8:37 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
>>>> >> >> >> On 21 June 2017 at 01:07, Peter Robinson <pbrobinson@gmail.com> wrote:
>>>> >> >> >>>>>>> Simon, do you have some suggestions on what to do here?  Thanks!
>>>> >> >> >>>>>>>
>>>> >> >> >>>>>>> --
>>>> >> >> >>>>>>> Tom
>>>> >> >> >>>>>>
>>>> >> >> >>>>>> My guess is that there is already a libfdt.py in the system. Someone
>>>> >> >> >>>>>> else reported this too.
>>>> >> >> >>>>>>
>>>> >> >> >>>>>> We could perhaps change the ordering in PYTHONPATH so that our one is first.
>>>> >> >> >>>>>
>>>> >> >> >>>>> No, I'm not sure that's completely the case because I first saw a
>>>> >> >> >>>>> related issue before my dtc had the python patch set added to it, I
>>>> >> >> >>>>> would actually prefer to build with the distro dtc rather than a fork
>>>> >> >> >>>>> of upstream like we use to.
>>>> >> >> >>>>
>>>> >> >> >>>> OK I think I see what is happening then. It seems to be picking up
>>>> >> >> >>>> _libfdt.so from your system and libfdy.py from U-Boot. If so that
>>>> >> >> >>>> seems like a bad idea at the best of times.
>>>> >> >> >>>>
>>>> >> >> >>>> Despite upstreaming efforts we still have local libfdt changes in
>>>> >> >> >>>> U-Boot. The main one is fdtgrep. I did try to upstream it a while back
>>>> >> >> >>>> but failed. I've been thinking of trying again but have not mustered
>>>> >> >> >>>> the energy.
>>>> >> >> >>>>
>>>> >> >> >>>> This particular error could probably be worked around in the short
>>>> >> >> >>>> term by dropping FDT_ERR_TOODEEP. But do we really want to allow this
>>>> >> >> >>>> sort of thing? I think we should either use one libfdt module or the
>>>> >> >> >>>> other, not a mixture of the two
>>>> >> >> >>>
>>>> >> >> >>> I suspect your right but I don't want to get into a situation where
>>>> >> >> >>> something might work in the kernel and and not in u-boot or
>>>> >> >> >>> vice-versa, and as things like overlays come into play where they
>>>> >> >> >>> could be applied to either the possible differences get greater and
>>>> >> >> >>> from a distro PoV that increased the requirements of support and debug
>>>> >> >> >>> and believe me people will do weird shit that they expect you to
>>>> >> >> >>> magically fix with little information hence my reluctance to diverge.
>>>> >> >> >>
>>>> >> >> >> I'm not sure what to do about this other than what I suggested. I
>>>> >> >> >> wonder it if is possible to detect the case where there is a mismatch
>>>> >> >> >> with the installation?
>>>> >> >> >
>>>> >> >> > Was that dropping FDT_ERR_TOODEEP? Why do we diverge from upstream on
>>>> >> >> > this, what does it do? Maybe provide an option to specify whether to
>>>> >> >> > use external dtc or bundled?
>>>> >> >>
>>>> >> >> So dropping dtc from our deps to try and get anything on 2017.07 built
>>>> >> >> I get for a bunch of devices I get this:
>>>> >> >>
>>>> >> >> /builddir/build/BUILD/u-boot-2017.07-rc3/scripts/dtc-version.sh: line
>>>> >> >> 18: dtc: command not found
>>>> >> >> rm -f .tmp_quiet_recordmcount
>>>> >> >> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
>>>> >> >>
>>>> >> >> Can we please have some level of resolution for 2017.07 GA?
>>>> >> >
>>>> >> > Can we short term do the thing where I guess it was PYTHONPATH gets
>>>> >> > modified so that you only pick up U-Boot provided parts here?
>>>> >>
>>>> >> Sure, as long as we have a commitment to a read fix for 2017.09
>>>> >
>>>> > The "real" fix is to get upstream libfdt stuff in sync with us again,
>>>> > yes?  If so, yes, I think we can agree that we need to sync up with them
>>>> > and get on the same page.
>>>>
>>>> It would be easy enough to drop the new error. I think that would fix
>>>> the current problem. I synced libfdt after the Python library was
>>>> applied upstream, so it may be possible to mix and match dtc now.
>>>>
>>>> Re fdtgrep I did send fdtgrep patches to the list a long time ago but
>>>> it did not go anywhere. For v3 there was a long delay and then this
>>>> comment:
>>>>
>>>> https://www.spinics.net/lists/devicetree-compiler/msg00108.html
>>>>
>>>> I have been meaning to try again with something smaller as I think it
>>>> is a useful tool.
>>>
>>> OK, so I need a patch for the moment then please, thanks!
>>
>> OK I just sent something that might help. Peter can you please test and advise?
>
> Testing it now.

Just for reference this is:

http://patchwork.ozlabs.org/patch/786042/

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Andreas Färber]

Hi,

On mvebu_db-88f3720 I am seeing endless resets when doing "scsi scan" or
"scan reset" (SATA). I am chain-loading U-Boot from the vendor U-Boot.

It seems the latest version working was v2017.01, v2017.03 is failing.
Haven't had time to bisect between releases yet.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Simon Glass]

Hi Andreas,

On 23 June 2017 at 10:19, Andreas Färber <afaerber@suse.de> wrote:
> Hi,
>
> On mvebu_db-88f3720 I am seeing endless resets when doing "scsi scan" or
> "scan reset" (SATA). I am chain-loading U-Boot from the vendor U-Boot.
>
> It seems the latest version working was v2017.01, v2017.03 is failing.
> Haven't had time to bisect between releases yet.

I don't have one of those boards, but it might be worth testing again
u-boot-dm/master or even u-boot-dm/ata2-working. If not then diagnosis
or bisect might help figure out what is going on.

Regards,
Simon

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Kostya Porotchkin]

Hi, Andreas,

What is your PCB revision (silkscreen)?
Possible variants:
- Rev 1.0 (2 pluggable modules with eMMC/SD)
- Rev 2.0 (single module, eMMC soldered on board)


Thanks
Kosta

> -----Original Message-----
> From: Andreas Färber [mailto:afaerber at suse.de]
> Sent: Friday, June 23, 2017 19:20
> To: u-boot at lists.denx.de; Stefan Roese
> Cc: Ken Ma; Nadav Haklai; Wilson Ding; Kostya Porotchkin; Alexander
> Graf; Matthias Brugger
> Subject: [EXT] Re: [U-Boot] [ANN] U-Boot v2017.07-rc2 released
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi,
> 
> On mvebu_db-88f3720 I am seeing endless resets when doing "scsi scan" or
> "scan reset" (SATA). I am chain-loading U-Boot from the vendor U-Boot.
> 
> It seems the latest version working was v2017.01, v2017.03 is failing.
> Haven't had time to bisect between releases yet.
> 
> Regards,
> Andreas
> 
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG
> Nürnberg)