Hi,
On Tue, Jan 16, 2018 at 04:56:49PM -0500, Tom Rini wrote:
On Tue, Jan 16, 2018 at 10:16:36AM +0100, Maxime Ripard wrote:
Hi,
Here is a second attempt at transitioning away from the MMC raw environment to a FAT-based one for Allwinner SoCs. Since the RFC was quite well received, I actually tested it and fixed a few rough edges.
You'll find the first RFC here for reference: https://lists.denx.de/pipermail/u-boot/2017-October/310111.html
And the second that originated in this series: https://lists.denx.de/pipermail/u-boot/2017-November/311608.html
I gave it a travis run, and one test seems to fail in one test: https://travis-ci.org/mripard/u-boot/jobs/329229382
I really cannot really make any sense of why a change in the way the environment loads could affect the operation of a DHCP client. Is there a way to reproduce locally?
In this case, roughly, clone https://github.com/swarren/uboot-test-hooks and then: $ export PATH=${PATH}:/path/to/uboot-test-hooks/bin $ export PYTHONPATH=/path/to/uboot-test-hooks/py/travis-ci:${PYTHONPATH} $ export UBOOT_TRAVIS_BUILD_DIR=`cd .. && pwd`/.bm-work/$1 $ ./test/py/test.py --bd vexpress_ca15_tc2 --build-dir "$UBOOT_TRAVIS_BUILD_DIR" -k 'net'
Thanks, I had to tweak it a bit to add --id qemu, and copy the conf.vexpress_ca15_tc2_qemu file in a directory with my hostname in the uboot-test-hooks repo.
And this is really getting weird, since the tests passes on my machine: http://code.bulix.org/rp6z29-258577
Maxime