travis: Setup QEMU_VERSION as variable

PATCH Superseded Michal Simek 5 participants 25 messages Dec 20, 2018 – Jan 16, 2019

Share & tools

Michal Simek

author

2018-12-20 07:55 UTC #0 lore raw

PATCH 1/2 travis: Setup QEMU_VERSION as variable

This change enables setting up specific Qemu version or sha1 for new targets which are added after (current) v3.0.0 version. This changes is preparation step for adding new Xilinx Versal Virt platform which was merge after v3.0.0.

Signed-off-by Michal Simek <[email protected]>

---

 .travis.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

.travis.yml +2 -1

index 321fd793a756..6e4b4ba0a34a 100644
@@ -63,6 +63,7 @@ env:
     - BUILD_DIR=build
     - HOSTCC="cc"
     - HOSTCXX="c++"
+    - QEMU_VERSION="v3.0.0"
 
 before_script:
   # install toolchains based on TOOLCHAIN} variable

@@ -97,7 +98,7 @@ before_script:
        git clone git://git.qemu.org/qemu.git /tmp/qemu;
        pushd /tmp/qemu;
        git submodule update --init dtc &&
-       git checkout v3.0.0 &&
+       git checkout ${QEMU_VERSION} &&
        ./configure --prefix=/tmp/qemu-install --target-list=${QEMU_TARGET} &&
        make -j4 all install;
        popd;

Signature · 1 line

1.9.1

Michal Simek

author

2018-12-20 07:55 UTC #1 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.

Signed-off-by Michal Simek <[email protected]>

---

Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21

---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)

.travis.yml +8 -0

index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
     - name: "test/py xtfpga"
       env:
         - TEST_PY_BD="xtfpga"

Signature · 1 line

1.9.1

Bin Meng

2018-12-20 08:09 UTC #2 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 19 lines · Michal Simek

Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +0 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"

.travis.yml matrix: · line 464

Quoted 10 lines

.travis.yml +8 -0

           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"

Can we turn on 3.1.0 for all QEMU targets?

Regards,
Bin

Michal Simek

author

2018-12-20 08:17 UTC #3 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 24 lines · Bin Meng

Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:

Quoted 8 lines

.travis.yml matrix: · line 464

Quoted 6 lines

.travis.yml +6 -0

+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"

Can we turn on 3.1.0 for all QEMU targets?

I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.

I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.

Thanks,
Michal

Bin Meng

2018-12-20 08:30 UTC #4 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Hi Michal,

Quoted 35 lines · Michal Simek

Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?

Quoted 7 lines

I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.

Yes, please try to test that. If everything is good, I see no reason not using it.

Regards,
Bin

Tom Rini

2018-12-26 14:29 UTC #5 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 42 lines · Bin Meng

Hi Michal,
Quoted 39 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.

Quoted 6 lines

Quoted 3 lines
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason not using it.

Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.

Signature · 8 lines

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

Michal Simek

author

2019-01-03 08:00 UTC #6 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 47 lines · Tom Rini

Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.

Quoted 6 lines

Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.

v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.

What do you think?

Thanks,
Michal

Tom Rini

2019-01-03 13:39 UTC #7 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 55 lines · Michal Simek

Quoted 47 lines · Tom Rini
Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Quoted 6 lines
Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.

Quoted 6 lines

v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?

The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option

And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!

Signature · 8 lines

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

Bin Meng

2019-01-04 01:29 UTC #8 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 69 lines · Tom Rini

Quoted 55 lines · Michal Simek
Quoted 47 lines · Tom Rini
Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Quoted 6 lines
Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option

Quoted 5 lines

And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!

I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?

Regards,
Bin

Tom Rini

2019-01-04 03:01 UTC #9 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 76 lines · Bin Meng

Quoted 69 lines · Tom Rini
Quoted 55 lines · Michal Simek
Quoted 47 lines · Tom Rini
Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Quoted 6 lines
Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
Quoted 5 lines
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!

Quoted 3 lines

I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?

Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.

Signature · 8 lines

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

Michal Simek

author

2019-01-07 12:18 UTC #10 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 77 lines · Tom Rini

Quoted 76 lines · Bin Meng
Quoted 74 lines · Tom Rini
Quoted 55 lines · Michal Simek
Quoted 47 lines · Tom Rini
Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Quoted 6 lines
Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!

Quoted 6 lines

Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.

I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22

But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.

=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #

	 2 MiB/s

done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu

I need to move to something else instead of hacking this target.

My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?

Thanks,
Michal

Tom Rini

2019-01-07 12:28 UTC #11 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 118 lines · Michal Simek

Quoted 77 lines · Tom Rini
Quoted 76 lines · Bin Meng
Quoted 74 lines · Tom Rini
Quoted 55 lines · Michal Simek
Quoted 47 lines · Tom Rini
Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Quoted 6 lines
Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 6 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu

Quoted 5 lines

I need to move to something else instead of hacking this target.
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?

Alex, any ideas? Can you take a look? Thanks!

Signature · 8 lines

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

Michal Simek

author

2019-01-07 12:46 UTC #12 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 119 lines · Tom Rini

Quoted 118 lines · Michal Simek
Quoted 77 lines · Tom Rini
Quoted 76 lines · Bin Meng
Quoted 74 lines · Tom Rini
Quoted 55 lines · Michal Simek
Quoted 47 lines · Tom Rini
Quoted 46 lines · Bin Meng
Hi Michal,
Quoted 42 lines · Michal Simek
Quoted 24 lines · Bin Meng
Quoted 23 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)
.travis.yml +2 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
           QEMU_TARGET="arm-softmmu"
           TEST_PY_ID="--id qemu"
           BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
+      env:
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 6 lines
.travis.yml +6 -0
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Quoted 6 lines
Quoted 2 lines
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 6 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu

Quoted 8 lines

Quoted 5 lines
I need to move to something else instead of hacking this target.
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!

Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468

https://travis-ci.org/michalsimek/u-boot/builds/475350468

Alexander Graf

2019-01-07 16:57 UTC #13 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 110 lines · Michal Simek

Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 48 lines · Michal Simek
Quoted 39 lines · Tom Rini
Quoted 38 lines · Bin Meng
Hi Michal,
Quoted 35 lines · Michal Simek
Quoted 22 lines · Bin Meng
Quoted 21 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
  .travis.yml | 8 ++++++++
  1 file changed, 8 insertions(+)
.travis.yml +1 -0
index 6e4b4ba0a34a..e14e6987e4cf 100644
@@ -454,6 +454,14 @@ matrix:
            QEMU_TARGET="arm-softmmu"
            TEST_PY_ID="--id qemu"
            BUILDMAN="^zynq_zc702$"
+    - name: "test/py xilinx_versal_virt"
Quoted 8 lines
.travis.yml matrix: · line 464
Quoted 7 lines
.travis.yml +7 -0
+      env:
+        - TEST_PY_BD="xilinx_versal_virt"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="aarch64-softmmu"
+          QEMU_VERSION="v3.1.0"
+          TEST_PY_ID="--id qemu"
+          BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468

So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:

1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
2) Find out *why* it's broken. That's probably a U-Boot bug.

Alex

Tom Rini

2019-01-07 17:13 UTC #14 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 120 lines · Alexander Graf

Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 48 lines · Michal Simek
Quoted 39 lines · Tom Rini
Quoted 38 lines · Bin Meng
Hi Michal,
Quoted 35 lines · Michal Simek
Quoted 22 lines · Bin Meng
Quoted 21 lines · Michal Simek
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
Quoted 8 lines
Quoted 7 lines
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468

Quoted 7 lines

So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior

... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.

Quoted 1 line

2) Find out *why* it's broken. That's probably a U-Boot bug.

Agreed.

Signature · 8 lines

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

Alexander Graf

2019-01-07 20:15 UTC #15 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 125 lines · Tom Rini

Quoted 124 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 48 lines · Michal Simek
Quoted 39 lines · Tom Rini
Quoted 38 lines · Bin Meng
Hi Michal,
Quoted 35 lines · Michal Simek
Quoted 30 lines · Bin Meng
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever version. Even sha1 for not released version.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I think we can try to test v3.1.0 qemu version for all boards but I will let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:

Quoted 6 lines

Quoted 3 lines
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.

Done: https://github.com/swarren/uboot-test-hooks/pull/23

Alex

Tom Rini

2019-01-07 22:59 UTC #16 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 128 lines · Alexander Graf

Quoted 125 lines · Tom Rini
Quoted 124 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 48 lines · Michal Simek
Quoted 39 lines · Tom Rini
Quoted 38 lines · Bin Meng
Hi Michal,
Quoted 35 lines · Michal Simek
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.
Done: https://github.com/swarren/uboot-test-hooks/pull/23

aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it. Thanks!

Signature · 8 lines

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

Stephen Warren

2019-01-07 23:05 UTC #17 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 3 lines · Tom Rini

Quoted 2 lines · Alexander Graf
Quoted 1 line · Tom Rini
On Mon, Jan 07, 2019 at 05:57:10PM +0100, Alexander Graf wrote:

...

Quoted 11 lines

Quoted 11 lines
Quoted 10 lines
Quoted 7 lines
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.

Quoted 6 lines

Quoted 1 line
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it. Thanks!

It's done.

Michal Simek

author

2019-01-15 07:07 UTC #18 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

In reply to Tom Rini

Quoted 133 lines · Tom Rini

Quoted 132 lines · Alexander Graf
Quoted 129 lines · Tom Rini
Quoted 127 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 48 lines · Michal Simek
Quoted 39 lines · Tom Rini
Quoted 38 lines · Bin Meng
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek <[email protected]> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
Quoted 8 lines
Quoted 5 lines
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it.

Alex: I expect this hook patch is not needed when you qemu patch is applied. Did it go to qemu tree?

Tom: I am proposing this way for upgrade.

Apply this one:
https://patchwork.ozlabs.org/patch/1016580/

Bump up qemu version to v3.1.0 with setting up
a) QEMU_VERSION="v3.0.0" for vexpress
or
b) QEMU_VERSION="qemu with Alex fix sha1" for vexpress

Please let me know which way you would like to go and I can create that patches.

Thanks,
Michal

Alexander Graf

2019-01-15 08:54 UTC #19 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 137 lines · Michal Simek

Quoted 136 lines · Tom Rini
Quoted 135 lines · Alexander Graf
Quoted 131 lines · Tom Rini
Quoted 120 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 48 lines · Michal Simek
Quoted 47 lines · Tom Rini
On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek <[email protected]> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the
version we use be spelled out will help with future reproducibility.
Quoted 6 lines
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2. take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
Quoted 7 lines
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it.
Alex: I expect this hook patch is not needed when you qemu patch is applied. Did it go to qemu tree?

Peter promised he would apply it (he maintains the arm tree in QEMU), but it's not in QEMU's master yet.

Quoted 9 lines

Tom: I am proposing this way for upgrade.
Apply this one:
https://patchwork.ozlabs.org/patch/1016580/
Bump up qemu version to v3.1.0 with setting up
a) QEMU_VERSION="v3.0.0" for vexpress
or
b) QEMU_VERSION="qemu with Alex fix sha1" for vexpress

v3.0.0 for now, then move everyone over to v3.2.0 (or v3.1.1) when it's out I'd say.

Alex

Quoted 7 lines

Please let me know which way you would like to go and I can create that patches.
Thanks,
Michal

Michal Simek

author

2019-01-15 08:56 UTC #20 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 157 lines · Alexander Graf

Quoted 137 lines · Michal Simek
Quoted 136 lines · Tom Rini
Quoted 135 lines · Alexander Graf
Quoted 131 lines · Tom Rini
Quoted 120 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
Quoted 54 lines · Michal Simek
On 26. 12. 18 15:29, Tom Rini wrote:
On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek <[email protected]> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the
version we use be spelled out will help with future reproducibility.
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let
vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup ----------------------------- +u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on the other QEMU-based targets. Can you update uboot-test-hooks (change .travis.yml to clone your fork of uboot-test-hooks rather than swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
Quoted 7 lines
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it.
Alex: I expect this hook patch is not needed when you qemu patch is applied. Did it go to qemu tree?
Peter promised he would apply it (he maintains the arm tree in QEMU), but it's not in QEMU's master yet.
Quoted 5 lines
Tom: I am proposing this way for upgrade.
Apply this one:
https://patchwork.ozlabs.org/patch/1016580/

Quoted 7 lines

Quoted 4 lines
Bump up qemu version to v3.1.0 with setting up
a) QEMU_VERSION="v3.0.0" for vexpress
or
b) QEMU_VERSION="qemu with Alex fix sha1" for vexpress
v3.0.0 for now, then move everyone over to v3.2.0 (or v3.1.1) when it's out I'd say.

Then I would like to use that patches I have sent already and enabled verson on v3.1.0 just for versal.

Thanks,
Michal

Alexander Graf

2019-01-15 08:58 UTC #21 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 163 lines · Michal Simek

Quoted 162 lines · Alexander Graf
Quoted 137 lines · Michal Simek
Quoted 136 lines · Tom Rini
Quoted 135 lines · Alexander Graf
Quoted 131 lines · Tom Rini
Quoted 120 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
Quoted 65 lines · Tom Rini
On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
On 26. 12. 18 15:29, Tom Rini wrote:
On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek <[email protected]> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the
version we use be spelled out will help with future reproducibility.
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let
vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup -----------------------------
+u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we
need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
the other QEMU-based targets. Can you update uboot-test-hooks (change
.travis.yml to clone your fork of uboot-test-hooks rather than
swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
Quoted 7 lines
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it.
Alex: I expect this hook patch is not needed when you qemu patch is applied. Did it go to qemu tree?
Peter promised he would apply it (he maintains the arm tree in QEMU), but it's not in QEMU's master yet.
Quoted 9 lines
Tom: I am proposing this way for upgrade.
Apply this one:
https://patchwork.ozlabs.org/patch/1016580/
Bump up qemu version to v3.1.0 with setting up
a) QEMU_VERSION="v3.0.0" for vexpress
or
b) QEMU_VERSION="qemu with Alex fix sha1" for vexpress

Quoted 5 lines

Quoted 2 lines
v3.0.0 for now, then move everyone over to v3.2.0 (or v3.1.1) when it's out I'd say.
Then I would like to use that patches I have sent already and enabled verson on v3.1.0 just for versal.

Ah, sorry, what I was trying to say was "v3.1.0 for everyone but vexpress, v3.0.0 for vexpress_a15" and then "v3.2.0 for everyone once it's out".

If we have to have one exception, we may as well have the broken case be the exception, which is vexpress_15 :).

Alex

Tom Rini

2019-01-16 13:10 UTC #22 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 172 lines · Alexander Graf

Quoted 163 lines · Michal Simek
Quoted 162 lines · Alexander Graf
Quoted 137 lines · Michal Simek
Quoted 136 lines · Tom Rini
Quoted 135 lines · Alexander Graf
Quoted 131 lines · Tom Rini
Quoted 120 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 67 lines · Tom Rini
Quoted 66 lines · Bin Meng
On Thu, Jan 3, 2019 at 9:39 PM Tom Rini <[email protected]> wrote:
On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
On 26. 12. 18 15:29, Tom Rini wrote:
On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek <[email protected]> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the
version we use be spelled out will help with future reproducibility.
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let
vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup -----------------------------
+u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we
need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
the other QEMU-based targets. Can you update uboot-test-hooks (change
.travis.yml to clone your fork of uboot-test-hooks rather than
swarren's) to have the modern syntax? Thanks!
Quoted 5 lines
Quoted 3 lines
I think the correct approach is to update uboot-test-hooks and send PR
to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
Quoted 7 lines
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it.
Alex: I expect this hook patch is not needed when you qemu patch is applied. Did it go to qemu tree?
Peter promised he would apply it (he maintains the arm tree in QEMU), but it's not in QEMU's master yet.
Quoted 9 lines
Tom: I am proposing this way for upgrade.
Apply this one:
https://patchwork.ozlabs.org/patch/1016580/
Bump up qemu version to v3.1.0 with setting up
a) QEMU_VERSION="v3.0.0" for vexpress
or
b) QEMU_VERSION="qemu with Alex fix sha1" for vexpress
Quoted 5 lines
Quoted 2 lines
v3.0.0 for now, then move everyone over to v3.2.0 (or v3.1.1) when it's out I'd say.
Then I would like to use that patches I have sent already and enabled verson on v3.1.0 just for versal.

Quoted 6 lines

Ah, sorry, what I was trying to say was "v3.1.0 for everyone but vexpress, v3.0.0 for vexpress_a15" and then "v3.2.0 for everyone once it's out".
If we have to have one exception, we may as well have the broken case be the exception, which is vexpress_15 :).

Yes, please, lets see a v2 with v3.0.0 for just vexpress_ca15_tc2 and v3.1.0 for everyone else, and then we can bump to v3.1.1 / v3.2.0 / whatever globally once the bugfix is in. Thanks!

Signature · 8 lines

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

Michal Simek

author

2019-01-16 14:21 UTC #23 lore raw

PATCH 2/2 travis: Wire Xilinx Versal Virt platform

Quoted 177 lines · Tom Rini

Quoted 176 lines · Alexander Graf
Quoted 163 lines · Michal Simek
Quoted 162 lines · Alexander Graf
Quoted 137 lines · Michal Simek
Quoted 136 lines · Tom Rini
Quoted 135 lines · Alexander Graf
Quoted 131 lines · Tom Rini
Quoted 120 lines · Alexander Graf
Quoted 110 lines · Michal Simek
Quoted 109 lines · Tom Rini
Quoted 108 lines · Michal Simek
Quoted 72 lines · Tom Rini
On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
On Thu, Jan 3, 2019 at 9:39 PM Tom Rini <[email protected]> wrote:
On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
On 26. 12. 18 15:29, Tom Rini wrote:
On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
Hi Michal,
On Thu, Dec 20, 2018 at 4:17 PM Michal Simek <[email protected]> wrote:
On 20. 12. 18 9:09, Bin Meng wrote:
On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <[email protected]> wrote:
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
Signed-off-by: Michal Simek <[email protected]>
---
Patch needs to be applied when this PR is merged.
https://github.com/swarren/uboot-test-hooks/pull/21
---
.travis.yml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/.travis.yml b/.travis.yml
index 6e4b4ba0a34a..e14e6987e4cf 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -454,6 +454,14 @@ matrix:
QEMU_TARGET="arm-softmmu"
TEST_PY_ID="--id qemu"
BUILDMAN="^zynq_zc702$"
+ - name: "test/py xilinx_versal_virt"
+ env:
+ - TEST_PY_BD="xilinx_versal_virt"
+ TEST_PY_TEST_SPEC="not sleep"
+ QEMU_TARGET="aarch64-softmmu"
+ QEMU_VERSION="v3.1.0"
+ TEST_PY_ID="--id qemu"
+ BUILDMAN="^xilinx_versal_virt$"
Can we turn on 3.1.0 for all QEMU targets?
I expected this question.
First of all I wanted to enable an option to be able to wire whatever
version. Even sha1 for not released version.
I think we can try to test v3.1.0 qemu version for all boards but I will
let Tom to decide is we can move or not.
Yes, please try to test that. If everything is good, I see no reason
not using it.
Yes, I would also like to move everyone up to v3.1.0 and also having the
version we use be spelled out will help with future reproducibility.
v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let
vexpress guys to figured out what's wrong with v3.1 and configs around.
What do you think?
The error is:
---------------------------- Captured stdout setup -----------------------------
+u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option
And I guess the problem is that by v3.1.0 -tftp has been removed and we
need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
the other QEMU-based targets. Can you update uboot-test-hooks (change
.travis.yml to clone your fork of uboot-test-hooks rather than
swarren's) to have the modern syntax? Thanks!
I think the correct approach is to update uboot-test-hooks and send PR
to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
still have U-Boot's .travis.yml point to swarren's git repo, no?
Yes, sorry, to be clear, I was just saying how to debug / confirm the
changes to uboot-test-hooks.
I have created new pull request for fixing that network issue here.
https://github.com/swarren/uboot-test-hooks/pull/22
But for vexpress_ca15_tc2 there is still an issue with helloworld efi. It works on v3.0 but not on v3.1.
=> => tftpboot 80000000 lib/efi_loader/helloworld.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'lib/efi_loader/helloworld.efi'. Load address: 0x80000000
Loading: #
	 2 MiB/s
done
Bytes transferred = 2144 (860 hex)
smc911x: MAC 52:54:00:12:34:56
=> => crc32 80000000 $filesize
CRC32 for 80000000 ... 8000085f ==> b76d87c0
=> => bootefi 80000000
Scanning disks on mmc...
^[[61;213RCard did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: booting without device tree
## Starting EFI application at 80000000 ...
Fs+u-boot-test-reset vexpress_ca15_tc2 qemu
I need to move to something else instead of hacking this target.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
My goal is to get Versal to travis to make sure that none is breaking it not debugging issues with platform I don't know.
Can I keep this platform on v3.0 and move the rest to 3.1?
Alex, any ideas? Can you take a look? Thanks!
Just in case you want to see some logs from travis.
https://travis-ci.org/michalsimek/u-boot/builds/475350468
Quoted 7 lines
So the offending change is a new capability in QEMU that exposes EL2 (HYP) mode on the Cortex-A15 core which this vexpress model uses. There are 2 steps here IMHO:
1) Disable EL2 again by hand. This is easily doable by passing "-cpu cortex-a15,has_el2=off" to the QEMU command line. That restores the previous behavior
... which is one more change to the uboot-test-scripts repo, can someone please? Thanks.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Done: https://github.com/swarren/uboot-test-hooks/pull/23
aaaand this breaks older QEMU. I think for the moment, can you please revert this Stephen? We'll take the QEMU version bump early on in the next release and I'll let you know off-list when I'm grabbing it.
Alex: I expect this hook patch is not needed when you qemu patch is applied. Did it go to qemu tree?
Peter promised he would apply it (he maintains the arm tree in QEMU), but it's not in QEMU's master yet.
Quoted 9 lines
Tom: I am proposing this way for upgrade.
Apply this one:
https://patchwork.ozlabs.org/patch/1016580/
Bump up qemu version to v3.1.0 with setting up
a) QEMU_VERSION="v3.0.0" for vexpress
or
b) QEMU_VERSION="qemu with Alex fix sha1" for vexpress
Quoted 5 lines
Quoted 2 lines
v3.0.0 for now, then move everyone over to v3.2.0 (or v3.1.1) when it's out I'd say.
Then I would like to use that patches I have sent already and enabled verson on v3.1.0 just for versal.
Ah, sorry, what I was trying to say was "v3.1.0 for everyone but vexpress, v3.0.0 for vexpress_a15" and then "v3.2.0 for everyone once it's out".

Quoted 7 lines

Quoted 2 lines
If we have to have one exception, we may as well have the broken case be the exception, which is vexpress_15 :).
Yes, please, lets see a v2 with v3.0.0 for just vexpress_ca15_tc2 and v3.1.0 for everyone else, and then we can bump to v3.1.1 / v3.2.0 / whatever globally once the bugfix is in. Thanks!

I have sent v2 with this. I will push versal enabling via my tree when this is applied.
I have tested it on the top of my xilinx changes and things looks good.
https://travis-ci.org/michalsimek/u-boot/builds/479836458

Thanks,
Michal

Bin Meng

2018-12-20 08:08 UTC #24 lore raw

PATCH 1/2 travis: Setup QEMU_VERSION as variable

In reply to Michal Simek

Quoted 6 lines · Michal Simek

This change enables setting up specific Qemu version or sha1 for new targets which are added after (current) v3.0.0 version. This changes is preparation step for adding new Xilinx Versal Virt platform which was merge after v3.0.0.

Quoted 6 lines

Signed-off-by Michal Simek <[email protected]>
---
 .travis.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by Bin Meng <[email protected]>