From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=137.74.110.75; helo=2.mo302.mail-out.ovh.net; envelope-from=raphael.glon@corp.ovh.com; receiver=edk2-devel@lists.01.org Received: from 2.mo302.mail-out.ovh.net (2.mo302.mail-out.ovh.net [137.74.110.75]) (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 DCB29222A54D8 for ; Mon, 8 Jan 2018 05:27:13 -0800 (PST) Received: from EX2.OVH.local (gw1.corp.ovh.com [51.255.55.226]) by mo302.mail-out.ovh.net (Postfix) with ESMTPS id 6FBFB31C56 for ; Mon, 8 Jan 2018 14:32:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=corp.ovh.com; s=mailout; t=1515418340; bh=JgfrJwn3xmiuvxIIvxTYV6acWuPsA8jsYRSE0MNfPho=; h=To:From:Subject:Date:From; b=b8ipNVw7TjNXLv1+C3+gHtF2Ot9wIuNK5iAb5H8jh4Td5B2n5ffqQmOfjtGymp+/f QYKvV8n6OuZ0TyLqMMHolAfCoB175fpkWuTDlXBzUCMDwbQn1obo9KaSkChn79YkQJ 4IDBziux6hBIXJhQspZ9K+fj8yMPbxo6kJGsgywk= Received: from [10.46.51.206] (109.190.254.4) by EX2.OVH.local (172.16.2.2) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1415.2; Mon, 8 Jan 2018 14:32:19 +0100 To: From: Raphael G Message-ID: <761832e5-77f1-657a-c4ea-c9276a8335b8@corp.ovh.com> Date: Mon, 8 Jan 2018 14:32:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 X-Originating-IP: [109.190.254.4] X-ClientProxiedBy: ex2.OVH.local (172.16.2.2) To EX2.OVH.local (172.16.2.2) X-Ovh-Tracer-Id: 8278742018464307159 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 50 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtuddrkeefgdehgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecuogetfeejfedqtdegucdlhedtmd Subject: efi application to update the proc microcode 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: Mon, 08 Jan 2018 13:27:15 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Hello, We are currently attempting to find an 'OS-independent' way of applying some updated microcode early during the efi boot sequence (note we cannot flash the motherboard firmware directly since we have not yet been provided with the latest constructor firmwares) Would it somehow be possible, for motherboards booting in uefi mode, to chain an efi application that would apply some microcode bin (in a uefi capsule or not) on flight before chaining to the next efi app (the os one) ? Or do you have any other generic way to do this, regardless of the final operating system ? We have found some interesting hints in edk2 framework, that seem promising (IntelSiliconPkg) https://github.com/tianocore/edk2/tree/master/IntelSiliconPkg but so far we have not managed to make it work, so any help/solution would be great :) If possible we do not want to persist anything in any non volatile storage at all, just apply it at the right time (we commented the flags persist_across_reset+trigger_reset in the capsule fdf for this, not sure this was the right thing to do) # ##################### workflow example: whatever.efi -> chain microcodeupdate.efi (apply ucode) -> chain final_os.efi #!ipxe echo Fetch images and capsule imgfetch http://${server}/microcode_efi/MicrocodeUpdateDxe.efi imgfetch http://${server}/microcode_efi/MICROCODECAPSULE.Cap chain MicrocodeUpdateDxe.efi MICROCODECAPSULE.Cap || goto fail [...] Regards,