From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0C47021E14528 for ; Tue, 15 Aug 2017 14:54:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E361DC01416E; Tue, 15 Aug 2017 21:57:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E361DC01416E Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-68.phx2.redhat.com [10.3.116.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5896D60BE8; Tue, 15 Aug 2017 21:57:15 +0000 (UTC) To: Brijesh Singh , edk2-devel@lists.01.org Cc: Jordan Justen , Tom Lendacky , Ard Biesheuvel References: <1502107139-412-1-git-send-email-brijesh.singh@amd.com> <7dc9df48-98c4-4df4-9b8b-7732ad3f4f2d@amd.com> <528814fa-03a9-cb12-57b2-5a516d087b96@redhat.com> <5751db0c-8a86-1a2e-16b0-f0292f84f120@amd.com> <82e062ef-3df6-7aef-cb3a-fa0db4e3ada6@redhat.com> <8bf5c6aa-6e73-e5c2-c10f-7196b7dbe782@amd.com> <4177725c-8d92-48dc-e688-508c0424a76c@amd.com> <63e71cee-95c0-de99-8428-81fe2676b235@amd.com> From: Laszlo Ersek Message-ID: Date: Tue, 15 Aug 2017 23:57:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <63e71cee-95c0-de99-8428-81fe2676b235@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 15 Aug 2017 21:57:17 +0000 (UTC) Subject: Re: [PATCH v1 00/14] OvmfPkg/Virtio: Add APIs to map system physical to device address X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 21:54:52 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/15/17 22:44, Brijesh Singh wrote: > > > On 08/15/2017 03:39 PM, Laszlo Ersek wrote: >> On 08/15/17 22:26, Brijesh Singh wrote: >>> >>> >>> On 08/15/2017 02:48 PM, Laszlo Ersek wrote: >>>> On 08/15/17 21:32, Brijesh Singh wrote: >>>>> Hi Laszlo, >>>>> >>>>> On 08/15/2017 05:42 AM, Laszlo Ersek wrote: >>>>> [snip] >>>>> >>>>>>> >>>>>>> I have been following the steps from >>>>>>> https://wiki.linaro.org/LEG/UEFIforQEMU >>>>>>> >>>>>>> qemu-system-aarch64 \ >>>>>>> -m 1024 \ >>>>>>> -cpu cortex-a57 \ >>>>>>> -M virt \ >>>>>>> -bios QEMU_EFI.fd \ >>>>>>> -serial stdio >>>>>>> >>>>>>> I tried this steps with and without my patches and it resulted in >>>>>>> the >>>>>>> same. >>>>>>> It seems like I am missing something in the qemu cli, do I need to >>>>>>> pass >>>>>>> special dtb file or something similar ? >>>>>> >>>>>> The above command line is not right ("-bios"). Please scroll down the >>>>>> wiki page, to the section heading saying "Using persistent UEFI >>>>>> variables". There it explains how to pad the images and how to use >>>>>> two >>>>>> -pflash options. ... Perhaps even that part of the article is a bit >>>>>> out-of-date now. >>>>>> >>>>>> Basically, today ArmVirtQemu should be used the same way as OVMF, >>>>>> except >>>>>> for the padding. The build produces two files: >>>>>> - QEMU_EFI.fd (fw binary) >>>>>> - QEMU_VARS.fd (varstore template) >>>>>> >>>>>> Each should be padded to 64MiB with zeros at the end (write a small >>>>>> script for that), then use them with two pflash drives similarly to >>>>>> OVMF. >>>>>> >>>>> >>>>> Still no luck, you can see my log error [1]. I never get to UEFI >>>>> shell, >>>>> I have >>>>> tried with and without virtio disk. >>>>> >>>>> https://gist.github.com/codomania/0aed024702b817761ee55fd30929200a >>>>> >>>>> I will continuing googling ... >>>> >>>> In order to get as detailed as possible logs, I suggest adding the >>>> following option to the ArmVirtQemu build command line: >>>> >>>> -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F >>>> >>>> The current log looks quite strange to me in places, but I'm not >>>> sure if >>>> that's because there are problems in those parts, or because the log >>>> does not contain DEBUG_VERBOSE entries. >>>> >>> >>> >>> https://gist.github.com/codomania/8b2fc5424fda259236405c5e257d8f47 >>> >>> I am using Ubuntu 16.04 for builds and runs >>> >>> $ qemu-system-aarch64 --version >>> QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright >>> (c) 2003-2008 Fabrice Bellard >> >> What is your complete QEMU command line? >> > > I have been using the following two qemu cli > > # qemu-system-aarch64 -m 2048 -cpu cortex-a57 -M virt \ > -pflash flash0.img -pflash flash1.img \ > -nographic > > # qemu-system-aarch64 -m 2048 -cpu cortex-a57 -M virt \ > -pflash flash0.img -pflash flash1.img \ > -drive > if=none,file=/home/brijesh/xenial-server-cloudimg-arm64.img,id=hd0,format=raw > -device virtio-blk-device,drive=hd0 \ > -nographic I can reproduce the boot hang. It looks like an edk2 regression. I'm currently bisecting the issue. Thanks Laszlo