From: Michal Simek <michal.simek@xilinx.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform
Date: Mon, 7 Jan 2019 13:18:46 +0100 [thread overview]
Message-ID: <2df1294d-188f-acea-164e-cb04b7bffacf@xilinx.com> (raw)
In-Reply-To: <20190104030152.GY16433@bill-the-cat>
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@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@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@xilinx.com> wrote:
>>>>>>>>>
>>>>>>>>> Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Michal Simek <michal.simek@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?
Thanks,
Michal
next prev parent reply other threads:[~2019-01-07 12:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 7:55 [U-Boot] [PATCH 1/2] travis: Setup QEMU_VERSION as variable Michal Simek
2018-12-20 7:55 ` [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform Michal Simek
2018-12-20 8:09 ` Bin Meng
2018-12-20 8:17 ` Michal Simek
2018-12-20 8:30 ` Bin Meng
2018-12-26 14:29 ` Tom Rini
2019-01-03 8:00 ` Michal Simek
2019-01-03 13:39 ` Tom Rini
2019-01-04 1:29 ` Bin Meng
2019-01-04 3:01 ` Tom Rini
2019-01-07 12:18 ` Michal Simek [this message]
2019-01-07 12:28 ` Tom Rini
2019-01-07 12:46 ` Michal Simek
2019-01-07 16:57 ` Alexander Graf
2019-01-07 17:13 ` Tom Rini
2019-01-07 20:15 ` Alexander Graf
2019-01-07 22:59 ` Tom Rini
2019-01-07 23:05 ` Stephen Warren
2019-01-15 7:07 ` Michal Simek
2019-01-15 8:54 ` Alexander Graf
2019-01-15 8:56 ` Michal Simek
2019-01-15 8:58 ` Alexander Graf
2019-01-16 13:10 ` Tom Rini
2019-01-16 14:21 ` Michal Simek
2018-12-20 8:08 ` [U-Boot] [PATCH 1/2] travis: Setup QEMU_VERSION as variable Bin Meng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2df1294d-188f-acea-164e-cb04b7bffacf@xilinx.com \
--to=michal.simek@xilinx.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox