From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 0B56B22352286 for ; Wed, 28 Feb 2018 04:05:14 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 348334040073; Wed, 28 Feb 2018 12:11:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-11.rdu2.redhat.com [10.10.120.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2351D10AF9CE; Wed, 28 Feb 2018 12:11:20 +0000 (UTC) To: Ard Biesheuvel , Michael Zimmermann Cc: "Ni, Ruiyu" , edk2-devel-01 , Andrew Fish , Leif Lindholm References: <26da6afd-102b-0006-c6b7-a10d8e13f96e@Intel.com> From: Laszlo Ersek Message-ID: <9c53a083-d56d-7523-fe62-b87d20c32a0e@redhat.com> Date: Wed, 28 Feb 2018 13:11:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 28 Feb 2018 12:11:21 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 28 Feb 2018 12:11:21 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: 'fastboot boot' TPL X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 12:05:15 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/28/18 09:19, Ard Biesheuvel wrote: > On 28 February 2018 at 08:15, Michael Zimmermann > wrote: >>> I agree. Did you run into any issues due to this? >> Surprisingly no. I was just trying to understand the fastboot implementation >> before I use it on my platform >> and was surprised that this works at all. I can imagine that's because this >> is supposed to load linux's efistub which probably doesn't do anything but >> calling SetVirtualMemoryMap and ExitBootServices. > > The ARM/Linux EFI stub does quite a bit more than that, actually. It > uses the various memory allocation and protocol handling services, to > carve out an allocation for the kernel, initrd and device tree, and to > access the command line, the EFI_RNG_PROTOCOL (if available) and to > interrogate the protocol database for GOP instances. > >> I can imagine that more complex loaders like the one used for Windows >> wouldn't work this way. >> > > No, and this is indeed something that should be fixed. Any clue as to how? - Change the type of the event "ReceiveEvent" from EVT_NOTIFY_SIGNAL to zero (0) - remove the DataReady() function - continue passing "ReceiveEvent" to mTransport->Start() - in the WaitForEvent() call near the end of FastbootAppEntryPoint(), also wait for "ReceiveEvent" - whenever "ReceiveEvent" fires, implement the same logic as seen originally in DataReady(), but now near the end of FastbootAppEntryPoint(). The idea -- already used with "mFinishedEvent" BTW -- is that an event can have type 0, which means it can be signaled and waited for without ever queueing a notification function (at either signaling or waiting). So mTransport should continue signaling ReceiveEvent whenever data is ready. But, readiness should be observed in the "main loop", and the data should be read, parsed and acted upon in that context as well, not in a callback. Thanks, Laszlo