From blibbet at gmail.com Mon Apr 9 17:07:19 2018 From: blibbet at gmail.com (Blibbet) Date: Mon, 9 Apr 2018 14:07:19 -0700 Subject: [Fw_Os_Forum] =?utf-8?q?Will_industry_follow_Intel=E2=80=99s_plan?= =?utf-8?q?_to_remove_UEFI_legacy_support=3F?= In-Reply-To: References: Message-ID: <3f18990b-b01b-3a31-46b3-8e626f548c7f@gmail.com> I don't know any details of Intel's 2020 BIOS deprecation plans. I asked Intel for questions, but got a complete non-answer, so don't expect anyone from Intel to jump into this UEFI thread with details. :-( I presume it means Intel will not longer ship Intel's BIOS implementation on any of their boards, presumably only shipping UEFI. If vendor is relying on Intel's BIOS implementation, they'll have to find another implementation (eg, seaBIOS). Vendor would also have to replace the firmware that Intel ships (probably UEFI-based) with their 'aftermarket' BIOS-payload-based solution. Today, Intel FSP is used by BIOS and UEFI. If Intel FSP no longer works for non-UEFI systems, that could be an issue. Don't most Intel-based vendors rely on FSP these days? And Intel plans to deprecate BIOS in 2020 are their own. What are plans of AMD and other x86-compat chip vendors? They may be other options for non-Intel BIOS beyond 2020. If nobody is maintaining the BIOS-centric code in Tianocore but Intel, and they stop in 2020, then presumably the BIOS code will get bitrot and eventually be removed, unless some vendor who wants BIOS support in UEFI maintains it. AFAICT, most UEFI maintainers prefer UEFI-only firmware, the CSM was Legacy code that nobody wants to see anymore. Bare-metal aside, I presume BIOS will live on a bit longer in virtual machines, supporting FreeDOS/MS-DOS legacy apps. Again, I don't know Intel's plans for BIOS deprecation. HTH, Lee From mark.doran at intel.com Mon Apr 9 18:09:05 2018 From: mark.doran at intel.com (Doran, Mark) Date: Mon, 9 Apr 2018 22:09:05 +0000 Subject: [Fw_Os_Forum] =?windows-1252?q?Will_industry_follow_Intel=92s_pla?= =?windows-1252?q?n_to_remove_UEFI_legacy_support=3F?= In-Reply-To: <3f18990b-b01b-3a31-46b3-8e626f548c7f@gmail.com> References: <3f18990b-b01b-3a31-46b3-8e626f548c7f@gmail.com> Message-ID: A non-text attachment was scrubbed... Name: smime.p7m Type: application/pkcs7-mime Size: 29098 bytes Desc: not available URL: From mark.doran at intel.com Mon Apr 9 19:15:31 2018 From: mark.doran at intel.com (Doran, Mark) Date: Mon, 9 Apr 2018 23:15:31 +0000 Subject: [Fw_Os_Forum] =?windows-1252?q?Will_industry_follow_Intel=92s_pla?= =?windows-1252?q?n_to_remove_UEFI_legacy_support=3F?= In-Reply-To: <3f18990b-b01b-3a31-46b3-8e626f548c7f@gmail.com> References: <3f18990b-b01b-3a31-46b3-8e626f548c7f@gmail.com> Message-ID: [hmm, apparently sending signed email to this list didn't work so let's try this again...] Well I don't know if this counts as details but there are some things I think I can say in this discussion. Principle among those, I want to make sure that it's clear what is being talked about because some terminology here is important and lack of clarity could definitely lead to misunderstanding. A little history. Legacy BIOS support in the context of implementations based on the EDK II code housed on Tianocore refers to the ability to support the 16-bit real mode interrupt based interfaces (and related structures) that some older OS and add-in card ROMs depend upon. Such legacy BIOS [interface] support for EDK II based implementations is delivered in the form of a Compatibility Support Module (CSM). In reality there are two parts to this. One is a gasket that glues the code that does the interface support work into an EDK II substrate and some of this is part of EDK II open sources. So far as I'm aware there's no plan to remove or deprecate this code -- it's part of the open source project and as such usual practice applies to code that may end up less used over time. The second part is the actual worker code behind those legacy interfaces; the guts of the CSM itself if you will. This code is not part of EDK II and there are commercial vendors who can support these and at least one open source project that has similar capability also. I've referred to this second part as the "furball" in various public venues (IDF etc.) with the notion that I'd like for the firmware ecosystem to cough it up and be rid of it as soon as that's practical. I've been saying that since the late 90's so discussion of this topic is hardly news but it does point out that actually making it happen takes longer than you might imagine. And now up to the minute... What's been said of Intel's position more recently is that there is a plan to deprecate support for legacy BIOS, which is to say the CSM since there are, so far as I'm aware, no teams working inside Intel on an actual legacy BIOS for products and it's been that way for many years in mainstream product groups. The 2020 date was associated with that deprecation statement. Exactly what that means may vary by product and market segment but the main theme here is that the plan is to stop validation of any CSM as part of enabling work that Intel will do. As anyone familiar with how this ecosystem works will quickly see, this is not the same at all as saying legacy BIOS will disappear from existence or that it will be impossible to get systems with legacy BIOS or CSMs on them in that timeframe. Ultimately the market decides. Those working on platforms and system software may well wish the CSM would go away (I certainly do! :)). Our experience with systems that have already moved over to legacy-free clearly demonstrates that it will simplify work, reduce cost, and improve security along with various other side benefits. However, so long as there are sufficient end customers asking for it and there's a business to be made in supporting it, I imagine legacy BIOS support CSMs will continue showing up on systems. As pointed out elsewhere, CSM support is pretty well wrung out and removing it, i.e. making a change, actually costs something to do so while those designing systems still see customer demand the incentives may appear mixed at best. I think it's fair to say that if your hypothetical agenda was to hasten the disappearance of the CSM then the real trick, and it is easier said than done I grant you, would be to reduce end customer demand down to zero. -- Cheers, Mark. > -----Original Message----- > From: fw_os_forum-bounces at mailman.uefi.org [mailto:fw_os_forum- > bounces at mailman.uefi.org] On Behalf Of Blibbet > Sent: Monday, April 9, 2018 2:07 PM > To: fw_os_forum at mailman.uefi.org > Subject: Re: [Fw_Os_Forum] Will industry follow Intel's plan to remove > UEFI legacy support? > > I don't know any details of Intel's 2020 BIOS deprecation plans. I > asked Intel for questions, but got a complete non-answer, so don't > expect anyone from Intel to jump into this UEFI thread with details. > :-( > > I presume it means Intel will not longer ship Intel's BIOS > implementation on any of their boards, presumably only shipping UEFI. > > If vendor is relying on Intel's BIOS implementation, they'll have to > find another implementation (eg, seaBIOS). > > Vendor would also have to replace the firmware that Intel ships > (probably UEFI-based) with their 'aftermarket' BIOS-payload-based > solution. > > Today, Intel FSP is used by BIOS and UEFI. If Intel FSP no longer > works for non-UEFI systems, that could be an issue. Don't most Intel- > based vendors rely on FSP these days? > > And Intel plans to deprecate BIOS in 2020 are their own. What are > plans of AMD and other x86-compat chip vendors? They may be other > options for non-Intel BIOS beyond 2020. > > If nobody is maintaining the BIOS-centric code in Tianocore but Intel, > and they stop in 2020, then presumably the BIOS code will get bitrot > and eventually be removed, unless some vendor who wants BIOS support > in UEFI maintains it. AFAICT, most UEFI maintainers prefer UEFI-only > firmware, the CSM was Legacy code that nobody wants to see anymore. > > Bare-metal aside, I presume BIOS will live on a bit longer in virtual > machines, supporting FreeDOS/MS-DOS legacy apps. > > Again, I don't know Intel's plans for BIOS deprecation. > > HTH, > Lee > _______________________________________________ > fw_os_forum mailing list > fw_os_forum at mailman.uefi.org > http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum