[U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform

Wed Jan 16 14:21:11 UTC 2019

On 16. 01. 19 14:10, Tom Rini wrote:
> On Tue, Jan 15, 2019 at 09:58:02AM +0100, Alexander Graf wrote:
>>
>>
>> On 15.01.19 09:56, Michal Simek wrote:
>>> On 15. 01. 19 9:54, Alexander Graf wrote:
>>>>
>>>>
>>>> On 15.01.19 08:07, Michal Simek wrote:
>>>>> On 07. 01. 19 23:59, Tom Rini wrote:
>>>>>> On Mon, Jan 07, 2019 at 09:15:17PM +0100, Alexander Graf wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 07.01.19 18:13, Tom Rini wrote:
>>>>>>>> On Mon, Jan 07, 2019 at 05:57:10PM +0100, Alexander Graf wrote:
>>>>>>>>> On 01/07/2019 01:46 PM, Michal Simek wrote:
>>>>>>>>>> On 07. 01. 19 13:28, Tom Rini wrote:
>>>>>>>>>>> On Mon, Jan 07, 2019 at 01:18:46PM +0100, Michal Simek wrote:
>>>>>>>>>>>> On 04. 01. 19 4:01, Tom Rini wrote:
>>>>>>>>>>>>> On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
>>>>>>>>>>>>>> On Thu, Jan 3, 2019 at 9:39 PM Tom Rini <trini at konsulko.com> 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 <michal.simek at xilinx.com> wrote:
>>>>>>>>>>>>>>>>>>> On 20. 12. 18 9:09, Bin Meng wrote:
>>>>>>>>>>>>>>>>>>>> On Thu, Dec 20, 2018 at 3:55 PM Michal Simek <michal.simek at xilinx.com> wrote:
>>>>>>>>>>>>>>>>>>>>> Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> ... 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?
>>>>
>>>> Peter promised he would apply it (he maintains the arm tree in QEMU),
>>>> but it's not in QEMU's master yet.
>>>>
>>>>> 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.
>>>
>>> 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 :).
> 
> 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