From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 6815C74003D for ; Mon, 26 Feb 2024 15:14:00 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=GNcjMpwyzhW6pxKVLJKKqa+dHTpH1j5cRG+Eo4ni7sI=; c=relaxed/simple; d=groups.io; h=Subject:To:From:User-Agent:MIME-Version:Date:References:In-Reply-To:Message-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1708960439; v=1; b=GJ+YPFQ1pT7tNwS4fEGZFop8pozawC4a/dTxHvBC/hWCFseZeQRzd41iA42zPhvZWWAJ6/FQ U9mWgl+UYZ78CiXkPBsvUFmd29V5ieAwu6+fqbEqA0praaN8TtbuQ/Xoy/iV2td7EA90V6Wrx4J SE0+m4Rlv6tXs0G1rRSUfx68= X-Received: by 127.0.0.2 with SMTP id AhucYY7687511xMYMcGGO4EW; Mon, 26 Feb 2024 07:13:59 -0800 Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Load Serial driver earlier in DXE To: Laszlo Ersek ,devel@edk2.groups.io From: "Albecki, Mateusz" X-Originating-Location: Jerusalem, IL (134.191.196.171) X-Originating-Platform: Linux Chrome 116 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 26 Feb 2024 07:13:58 -0800 References: In-Reply-To: Message-ID: <5971.1708960438578293809@groups.io> Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,mateusz.albecki@intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 4LE3qgTYUPkr4VlUa1Lc1Evtx7686176AA= Content-Type: multipart/alternative; boundary="qoRDpMLXrATyEfafjrS3" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=GJ+YPFQ1; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --qoRDpMLXrATyEfafjrS3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1. Using SerialDxe instead of PciSioSerialDxe - from our perspective the ma= in idea is to avoid maintaining our own implementation of functions that ac= tually communicate with UART controller. To use SerialDxe we would have to = still maintain our own SerialPortLib that actually goes and sends data over= UART. Also a note on LPSS UART - in terms of registers it is just a standa= rd UART controller, the only quirk here is how to access it hence the custo= m PCI_IO_PROTOCOL implementation. 2. Using ConnectController before BDS - I noticed that the section I quoted= says that BDS will use ConnectController however it doesn't say that it ca= n't be used outside of that context. I did search the UEFI spec to see whet= her it provides additional restrictions and the only section that elaborate= s on this is the following: "Under the UEFI Driver Model , the act of connecting and disconnecting driv= ers from controllers in a platform is under the platform firmware=E2=80=99s= control. This will typically be implemented as part of the UEFI Boot Manag= er, but other implementations are possible. " - from=C2=A0 Section 2.5.6 Pl= atform components It seems to be rather permissive when it comes to who and when can call it. 3. How to make sure dispatch is early enough and not too late - this will d= epend on the overall platform implementation. For our part - we simply put = it into flash as early as we can get away with. Even apriori section isn't = strictly necessary if the platform is comfortable with relying on the fact = that DXE core in MdeModulePkg dispatches modules in order of their placemen= t in flash(that's not architectural as far as I know). Other platforms migh= t choose to introduce explicit depex on gEfiSerialIoProtocolGuid. To reiter= ate this is the implementation that works for us in a sense that we get log= s from all modules that change frequently from generation to generation, I = understand that the same might not be true for platforms other than Intel h= owever I think majority of platforms could still make at least some use of = early UART debugging. 4. When exactly do we connect LPSS UART and start logging - we try to be as= early as possible for this interface. We miss all of DXE_CORE logs(obvious= ly), Pcd.inf and a couple of modules that implement some of the architectur= al protocols(from PciSio perspective metronome is the only actually require= d as far as we can tell since stall has to work). I also want to note that I get why this is a controversial change. I didn't= realize it earlier but it would be the first DXE_DRIVER in EDK2 tree that = implements driver binding and in general it is strange to have PCI device d= river that could potentially dispatch before PCI bus driver(however it is w= orth noting here that PciSioSerialDxe is not just a PCI driver, it is a com= bo driver capable of supporting PCI and SIO). That said I still think EDK2 = in general needs a way to support early device drivers and using DXE_DRIVER= seems like the least invasive idea. We need early drivers not just for deb= ug(although that is one of the most important use cases I would say) other = important use case is platform management through SMBUS/I2C/other serial in= terface which might be required to even be able to enumerate full PCI hiera= rchy(for instance some of the PCI slots might be powered down and you need = to power them on sending commands over I2C) or maybe flash access to EFI va= riable storage(nothing says that you can't have it connected to PCI SPI con= troller) or maybe GPIO control to do any number of platform specific things= . Thanks, Mateusz -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115968): https://edk2.groups.io/g/devel/message/115968 Mute This Topic: https://groups.io/mt/104469297/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --qoRDpMLXrATyEfafjrS3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1. Using SerialDxe instead of PciSioSerialDxe - from our perspective the ma= in idea is to avoid maintaining our own implementation of functions that ac= tually communicate with UART controller. To use SerialDxe we would have to = still maintain our own SerialPortLib that actually goes and sends data over= UART. Also a note on LPSS UART - in terms of registers it is just a standa= rd UART controller, the only quirk here is how to access it hence the custo= m PCI_IO_PROTOCOL implementation.

2. Using ConnectController bef= ore BDS - I noticed that the section I quoted says that BDS will use Connec= tController however it doesn't say that it can't be used outside of that co= ntext. I did search the UEFI spec to see whether it provides additional res= trictions and the only section that elaborates on this is the following:"Under the UEFI Driver Model , the act of connecting and disconnecti= ng drivers from controllers in a platform is under the platform firmware&rs= quo;s control. This will typically be implemented as part of the UEFI Boot = Manager, but other implementations are possible. " - from  Section 2.5= .6 Platform components
It seems to be rather permissive when it c= omes to who and when can call it.

3. How to make sure dispatch i= s early enough and not too late - this will depend on the overall platform = implementation. For our part - we simply put it into flash as early as we c= an get away with. Even apriori section isn't strictly necessary if the plat= form is comfortable with relying on the fact that DXE core in MdeModulePkg = dispatches modules in order of their placement in flash(that's not architec= tural as far as I know). Other platforms might choose to introduce explicit= depex on gEfiSerialIoProtocolGuid. To reiterate this is the implementation= that works for us in a sense that we get logs from all modules that change= frequently from generation to generation, I understand that the same might= not be true for platforms other than Intel however I think majority of pla= tforms could still make at least some use of early UART debugging.
4. When exactly do we connect LPSS UART and start logging - we try to be= as early as possible for this interface. We miss all of DXE_CORE logs(obvi= ously), Pcd.inf and a couple of modules that implement some of the architec= tural protocols(from PciSio perspective metronome is the only actually requ= ired as far as we can tell since stall has to work).

I also want= to note that I get why this is a controversial change. I didn't realize it= earlier but it would be the first DXE_DRIVER in EDK2 tree that implements = driver binding and in general it is strange to have PCI device driver that = could potentially dispatch before PCI bus driver(however it is worth noting= here that PciSioSerialDxe is not just a PCI driver, it is a combo driver c= apable of supporting PCI and SIO). That said I still think EDK2 in general = needs a way to support early device drivers and using DXE_DRIVER seems like= the least invasive idea. We need early drivers not just for debug(although= that is one of the most important use cases I would say) other important u= se case is platform management through SMBUS/I2C/other serial interface whi= ch might be required to even be able to enumerate full PCI hierarchy(for in= stance some of the PCI slots might be powered down and you need to power th= em on sending commands over I2C) or maybe flash access to EFI variable stor= age(nothing says that you can't have it connected to PCI SPI controller) or= maybe GPIO control to do any number of platform specific things.

Thanks,
Mateusz
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#115968) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--qoRDpMLXrATyEfafjrS3--