From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mx.groups.io with SMTP id smtpd.web10.7128.1592301396343083349 for ; Tue, 16 Jun 2020 02:56:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=g8a4VIU7; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.128.68, mailfrom: pete@akeo.ie) Received: by mail-wm1-f68.google.com with SMTP id b82so2262173wmb.1 for ; Tue, 16 Jun 2020 02:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=2YxLaZRPSqJj1o7nec9hmZA92FjBrBgd3MWtCGBltk4=; b=g8a4VIU7FrfARd895/kL2mGgGU9Nn9bP6Y+4AIkdOqsXLxvEF3v6B+Qi7vi0AZ9uV3 dpO/t+mLepQm6EzWwSVcYAd5gjsEMTPvwHsyfqnuBLIf6X3vqMIxKpSmo7isEofU14mu TnnV4yUKSI46+VZtOS1xXNWtS7b+h53mnlfmBwQi6HqnimxzESLw2lN7dvOR3jPK9t1u JkIdttf06gMunL8VkqHtCAUOWmAA+v12YS05Sr3QD0pEiEhWeGhzNdUGUuEvQirMO4TU eo3vhsj/r+AJ6VvhvjWVVRnzx0/1bUKmVr7LPNBrwR6PrICTHpX+4Yj7+noWPbfiDv6N gv7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=2YxLaZRPSqJj1o7nec9hmZA92FjBrBgd3MWtCGBltk4=; b=mieHLDY1QXBizBRo1TqUcIrio0zkbGIiNiid7AwxwEyXMYX7WKy8k+P/QxMB/hRC6A PlP55I2biTDB90Wl25z9j+Gslk63ngw0DbrUPCS/PqAsoaL++BtgMUs3qOP9eDEXMeso Kig41Ggfif+OfCMHu9BYO8HYjuyMOg6GvXh0Jd/tuJruJIr8g0gNlAOfgPT36EU3zUTj aVIIikrl/ZCSnDgkCdSO8c3QsJ65dLYfwLjNSWcF2o9OPFi4Clu9ROeqTpih5xJDrfYm 3An37aOiTSDkScN2R5RXU2djTcyhahldLbDDFJj4uZjOeV4FWWjtCMUYSGrlazbfbcX9 BWPg== X-Gm-Message-State: AOAM533y8iW7YiNqBw6K+zByih8Sx3ezwsSCAT0RKEPvcVbdKGwGEnR6 2OvGZFtN0SV4E6kluWHNMyHISVgCo2iZlw== X-Google-Smtp-Source: ABdhPJxyj9bDmcVElrZbi6jD87aH3HndAPXWpKEd79QY9vB4DPjwMTEQeYZY/Bx1/NH1k0ZKKeNhLA== X-Received: by 2002:a7b:c852:: with SMTP id c18mr2426243wml.77.1592301394547; Tue, 16 Jun 2020 02:56:34 -0700 (PDT) Return-Path: Received: from localhost.localdomain ([84.203.48.247]) by smtp.gmail.com with ESMTPSA id o15sm29113111wrv.48.2020.06.16.02.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 02:56:34 -0700 (PDT) From: "Pete Batard" To: devel@edk2.groups.io Cc: zhichao.gao@intel.com, ray.ni@intel.com, ard.biesheuvel@arm.com, leif@nuviainc.com Subject: [edk2][PATCH 0/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery Date: Tue, 16 Jun 2020 10:56:21 +0100 Message-Id: <20200616095622.2820-1-pete@akeo.ie> X-Mailer: git-send-email 2.21.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This single patch addresses what we consider to be an overlook of the current EDK2 codeset in that the ReadyToBoot event is only signaled when a formal Boot Manager option is executed but not when a Platform Recovery one is, whereas the boot loaders executed in both cases tend to be similar in terms of requirements, and therefore, since there is no dedicated event associated with pre Platform Recovery execution, ReadyToBoot should also apply there. Especially, this patch is required to fix an issue that we encounter on the Raspberry Pi platform (https://github.com/pftf/RPi4/issues/64), as it uses EmbeddedPkg/Drivers/ConsolePrefDxe to set up the graphical console as default, but the code to switch to graphical is tied to the ReadyToBoot event being triggered. This means that, currently, unless users go to the UEFI options to save their boot preferences, the console defaults to a non-initialized instance that happens to be serial. Obviously, this is very problematic as it means that installation of an OS such as Debian-Linux (which Platform Recovery will boot into if the ISO content have been extracted to a bootable drive) will occur on the serial console rather than the graphical console by default, leaving users, who do not have a serial adapter plugged in, getting only an unexpected a black screen instead of the Debian installer... Also, due to the nature of the UEFI firmware for the Raspberry Pi platform, which actually resides on the bootable USB or SD media rather than flash, and therefore is something that platform users are excepted to update on a whim (with the effect of resetting all the UEFI variables when they do so), and as opposed to what might be the case for other platforms, it is not reasonable to expect for users to go to their settings to set up the Boot Manager options so that they don't end up using Platform Recovery. As a matter of fact, it's the opposite that is likely to hold true, with most Raspberry Pi users using Platform Recovery for their boot process. Especially, considering that the platform defaults should be fine for most users, we do expect that the bulk of UEFI vanilla Linux installations on the Raspberry Pi 4 are going to use Platform Recovery instead of Boot Manager. As such it is crucial that the Platform Recovery and formal Boot Manager boot processes do behave similarly in terms of ReadyToBoot event being signaled, hence the reason for this patch. Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have: > EFI_EVENT_GROUP_READY_TO_BOOT > This event group is notified by the system when the Boot Manager > is about to load and execute a boot option. and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery. Regards, /Pete Pete Batard (1): MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++ 1 file changed, 9 insertions(+) -- 2.21.0.windows.1