From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web11.8155.1618372331375414794 for ; Tue, 13 Apr 2021 20:52:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=AGXKZWHX; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 13E3ldO2009570; Tue, 13 Apr 2021 20:52:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=U9fVPAMJCs8bvSIEjzwT2a3IUu5aC/qZcYgVpfkUw2Q=; b=AGXKZWHX8ea9qVBLPgBb8AjQVBwwt6vCuz9sUXnoxMW+q0/su6uQFF6AdX4/ybv9tLZJ lpadfHhGRRH6OBsS5P+yj0qjKjM1mGT2sMUrVO57812KiapMAkIvBOKd75T+2qcx59R2 Qe2Ewo0k/iW37GxmpoI65gHS+QijUt9Z7FaRtmp1rR9pnl14OMXlrS3EkNlC9v3I4jbm pwOhmt8bY+yuFW6ORVflWaB0WpUgrBKHxpl3xFQdcmf+bn6aYE8xAuxMj8ijGBOgz3SF Rb7PX5GrhI+prRRq7voM2HjAHZbMUNox4UnuTU8fa70WytkVI3Bl0MsBZsmszYB5C+QW GQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 37uaatfdv6-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Apr 2021 20:52:10 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRJ00PUQC2YBN30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 13 Apr 2021 20:52:10 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRJ00I00C2PEJ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 13 Apr 2021 20:52:10 -0700 (PDT) X-Va-A: X-Va-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: 2b256433-69f6-4e64-a3ed-f68cb8e2d368 X-V-A: X-V-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: edd0e90e-c72d-4a58-89a9-809bf35b543e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-14_01:2021-04-13,2021-04-14 signatures=0 Received: from [17.235.26.197] (unknown [17.235.26.197]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRJ000AUC2XW800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 13 Apr 2021 20:52:10 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) Date: Tue, 13 Apr 2021 20:52:09 -0700 In-reply-to: Cc: edk2-devel-groups-io , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann To: Ethin Probst References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-14_01:2021-04-13,2021-04-14 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_7CB7684E-5A71-42CD-90B4-FAB224EFC647" --Apple-Mail=_7CB7684E-5A71-42CD-90B4-FAB224EFC647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ethin, In terms of defining the protocol stack it is good to start with the produ= cers and consumers and think about the problem from both perspectives. It i= s easy enough to think about the producer part of it as you are thinking ab= out writing the driver. The driver is going to consume things like the PCI = I/O Protocol.=20 The consumer of the sound Protocol is going to most likely be generic EFI = platform code, and possibly an OS loader. In the boot process Audio has tra= ditionally be used for error codes, sign of life (for example the famous Ma= c startup sound). We are also would like to have the option of enabling bet= ter accessibility features, especially for people how are visually impaired= . These days a lot of software engineers think of disk space as free and re= ally don=E2=80=99t consider the size of software, but this is not true for = firmware. Firmware generally lives in NOR FLASH that is considered expensiv= e (it is more expensive than NAND, but at the same time more reliable) so f= irmware implementations are constrained by the size of the code that can be= carried, and the size of assets/resources that can be used for user interf= aces. The OS loader is some what less constrained, but it still has to shar= e the EFI System Partition on the disk with potentially other OS loaders.= =20 So the consumer wants a protocol that is unleveled and focused on the task= at hand. I=E2=80=99m not too caught up on the names but in general I think= things you want are (How many knobs we need is probably better answered by= an audiophile, and that is not me): 1) CompatibleBuffer() - Does driver support this buffer format.=20 2) PlayBuffer() - Play the sound a) We probably want a synchronous and asynchronous version of this API. F= or example you don=E2=80=99t want to slow down the boot to wait for a boot = beep to complete, and you may chose to implement an API that waits for the = sound to complete (and do some GUI work in parallel) vs. blocking on the so= und.=20 b) async in EFI usually means you return a pointer to an EFI_EVENT that g= ets signaled on completion. 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be stoppe= d. Think error exit.=20 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying to= avoid db as that gets into capability and math that is likely best abstrac= ted by the driver)? 4) Mute()/UnMute() - Mute and volume are often independent features in a U= I keeping them separate in API makes it easier to implement things.=20 5) PlayTone() - Maybe for error sounds that don=E2=80=99t require canned s= ound files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat.= = =20 6) Do we need tuning values or Tone settings?=20 At some point we might consider defining nvram variable for the default st= ate of some of the tunable, especially mute and volume. For example the use= r may want to turn off all volume on the system so it would be nice if the = OS can set the EFI volume and mute. In the short run we can probably use PC= D values to set the default values.=20 So I think we have a generic AUDIO API on top and likely a PCI I/O on the = bottom. If we need more protocols to manage hardware devices then those pro= tocols can be defined in the context of that hardware. So for example we wo= uld probably end up with an HDA_CODEC protocol. I think the best way to thi= nk about this is a disk. A lot of disk adapters just produce a raw Block I/= O protocol, but for a more common bus like ATA or SCSI you might have an e= xtra driver in place to make the common bits common code. I think some of t= he same layers may be in place here. So likely VirtIo is simple and just pr= oduces the generic AUDIO API, while an HDA audio driver also has to abstrac= t some of the complexity of its hardware implementation and standard.=20 In terms of picking the set of APIs and tunables it is probably good to st= art with VirtIo and USB and see what set make sense and what you could and = could not implement. HDA Audio is so complex you might want to look at it i= n terms of the minute you have to implement to make it function. Think what= assumptions are you forced to make to implement.=20 This is a vey 10,000 foot view to start with. I think you will need to mix= this in the the reality of how it works in the real world to figure out th= e right abstraction, but then again that is the beauty of having an impleme= ntation. Likely also get some feedback from audiophiles.=20 Oh and make sure you don=E2=80=99t go off an implement a lot of code just = because we chose the wrong complexity or abstraction point. This is the one= time we get to change the public APIs so lets feel free to adjust them to = make the most sense for the job at hand.=20 Thanks, Andrew Fish > On Apr 13, 2021, at 6:20 PM, Ethin Probst wrot= e: >=20 > Okay, so looking at the EDK2 driver developers guide, here are my though= ts: >=20 > - Each audio driver will be a bus driver, even if it doesn't control > buses in the traditional sense. > - I think the initialization sequence should be different: there > should be an AudioDxe, but it should contain three separate bus > drivers for each kind of audio device supported. > - For the VirtIO audio device driver, it'll most likely consume the > PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and > EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an > ordinary UEFI device driver. > - The HDA audio device driver will consume the PCI I/O protocol and > will produce different device handles per HDA controller found. I'd > produce a handle per codec, but that seems overkill. Each handle will > be attached to both an audio stream protocol and a controller > management protocol. The audio stream protocol will manage the > creation, control, and deletion of audio streams as well as the > processing of audio data. The controller management protocol is > responsible for allowing applications or other drivers to manage the > HDA controller itself. >=20 > I haven't planned for the USB audio device driver yet, but these are > my thoughts so far. What do you guys think? Am I over-complicating > this setup? How can it be improved upon? >=20 > On 4/13/21, Ethin Probst via groups.io > > wrote: >> Hi Andrew, >>=20 >> The developer guide for EDK2 drivers is a godsend. Thank you very >> much, and thank you, Mike, for your excellent work on the guide! I may >> just ahve to do my building on Linux and not Windows -- unless the Bug >> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at >> any rate, since Windows hosts do not support VirtIO emulation and I >> can't seem to find any way of emulating them in a guest machine with >> Windows as a host. >>=20 >> On 4/13/21, Andrew Fish > wrot= e: >>>=20 >>>=20 >>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst >>>> wrote: >>>>=20 >>>> Would it be possible for us to conduct discussion on the UEFI talkbox= ? >>>> I don't mind using email, but things could definitely get moving >>>> quicker over there (though its not a requirement obviously). >>>>=20 >>>=20 >>> Sure, don=E2=80=99t think I=E2=80=99ve really used that but as long as= I get pointed int >>> he >>> right direction I can make it work. >>>=20 >>> For a device driver the general UEFI model is for the Entry point of t= he >>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() >>> function >>> matches on the PCI devices. The Start() function installs the Protocol= s >>> to >>> do work, and the Stop() undoes the Start(). >>>=20 >>> Mike Kinney started this back in the day and it describes how to write >>> UEFI >>> drivers: >>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writ= er%27s-Guide >>>=20 >>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protoc= ol/DriverBinding.h#L157 >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=20 >>>> Here's how I generally envision the driver functioning: >>>>=20 >>>> 1. Firmware/platform code calls InitaudioOutput() or something like >>>> it. This function scans the PCIe bus and scans for one of the >>>> following: >>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device >>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for >>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4, >>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my >>>> hands. If so, it will make things easier. >>>> - For USB audio devices I'm not quite sure what to look for; I'm >>>> definitely unused to USB. >>>> 2. If any of the above cases are found, appropriate driver >>>> initialization occurs. Since for the time being I am solely focusing >>>> on VirtIO sound devices, the VirtIO general initialization sequence >>>> will occur as outlined in sec. 3 of the VirtIO specification availabl= e >>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html >>>> >. >>>> As for actual protocol exposure that would be spec-worthy, for >>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO >>>> is rather simple: there's a buffer for sending and receiving audio >>>> data in PCM streams. So for that we could expose a Reset(), >>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(), >>>> Prepare(), Release(), Start(), and Stop() function for the >>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG, >>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG, >>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE, >>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and >>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a >>>> lot more complex, so I'm not sure how that should work. >>>> For VirtIO -- which is what I'll focus on for now -- everything is >>>> described, in excellent detail, in sec. 5.14 of the above-linked >>>> document. What are your guys's thoughts thus far and how should >>>> everything be mapped to UEFI interfaces? >>>>=20 >>>> On 4/13/21, Andrew Fish >> >>>> wrote: >>>>> Leif, >>>>>=20 >>>>> Since I have put some brain cells around this area in the past I can= be >>>>> the >>>>> backup and help out too. >>>>>=20 >>>>> I=E2=80=99d also point out if you are having issues building or have= general >>>>> questions on how things work it is fine to use the mailing list. I= =E2=80=99ve >>>>> got >>>>> a >>>>> lot of feedback that folks read or search the mailing list looking f= or >>>>> answer to their questions so one person asking can help out a lot of >>>>> other >>>>> people. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Andrew Fish >>>>>=20 >>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm > wrote: >>>>>>=20 >>>>>> Hi all, especially Ethin. >>>>>>=20 >>>>>> Apologies for radio silence - last week I was off on holiday, and >>>>>> before >>>>>> that ... let's just say corporate acquisitions generate some >>>>>> distractions. >>>>>> Anyway, I'm back, and since I'm down as the mentor for this task, f= eel >>>>>> free to spam me with any remaining/new questions. >>>>>>=20 >>>>>> / >>>>>> Leif >>>>>>=20 >>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst >>>>>> >>> >>>>>> wrote: >>>>>> I'll attach the bug for the build tools to the BZ shortly. >>>>>> Laszlo, thanks for that. I don't know their email addresses though. >>>>>> And yes, I was going to make it device independent, as the majority >>>>>> (if not all) of UEFI protocols are. >>>>>>=20 >>>>>> On 4/6/21, Laszlo Ersek > >>>>>> >>> >>>>>> wrote: >>>>>>> On 03/31/21 08:41, Nate DeSimone wrote: >>>>>>>> Another option is to put the protocol definition in MdeModulePkg = and >>>>>>>> mark it with the EDKII_ prefix. For my last =E2=80=9Ccode first= =E2=80=9D UEFI spec >>>>>>>> contribution I did this with the PPI that added up getting added. >>>>>>>=20 >>>>>>> The new audio protocol should be generic, only its implementation = in >>>>>>> question should be virtio specific. >>>>>>>=20 >>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as wel= l >>>>>>> as >>>>>>> the developers of the virtio-sound device model in QEMU. >>>>>>>=20 >>>>>>> Thanks >>>>>>> Laszlo >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Nate >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> *From: * > >>>>>>>> >>> on >>>>>>>> behalf >>>>>>>> of "Andrew Fish via groups.io > >>>>>>>> >>" >>>>>>>> = > >>>>>>>> >>> >>>>>>>> *Reply-To: *"devel@edk2.groups.io <= mailto:devel@edk2.groups.io > >>>>>>>> >>" >>>>>>>> > >>>>>>>> >>>, >>>>>>>> "afish@apple.com > >>>>>>>> >>" > >>>>>>>> >>> >>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM >>>>>>>> *To: *edk2-devel-groups-io >>>>>>>> > >>>>>>>> >>>, >>>>>>>> "harlydavidsen@gmail.com > >>>>>>>> = >>" >>>>>>>> > >>>>>>>> = >>> >>>>>>>> *Cc: *Rafael Rodrigues Machado >>>>>>>> > >>>>>>>> >>>>>>>> >>> >>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst >>>>>>>> >>>>>>>> > >>>>>>>> = >> >>>>>>>> > >>>>>>>> = >>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I'm wondering where exactly I should add the VirtIO sound >>>>>>>> protocol. >>>>>>>> I >>>>>>>> just familiarized myself with the build system and am about to >>>>>>>> test >>>>>>>> it >>>>>>>> by building OVMF if possible, but I'm wondering where I should >>>>>>>> actually put the protocol and all that stuff. Maybe there's >>>>>>>> documentation I've missed as well. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Ethin, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For the driver I=E2=80=99d match the patter of OVMF [1] and use >>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers = as >>>>>>>> a >>>>>>>> template. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The protocol is more of a public thing. I think eventually we wou= ld >>>>>>>> like >>>>>>>> to publish the protocol in the UEFI Spec (I can help with that pa= rt) >>>>>>>> and >>>>>>>> that would mean we put the Protocol definition in >>>>>>>> MdePkg/Include/Protocol, but we don=E2=80=99t want to do that bef= ore it is >>>>>>>> standardized as that causes compatibility issues. So this is a = =E2=80=9Ccode >>>>>>>> first project=E2=80=9D (code prototype and then contribute to the= UEFI Forum >>>>>>>> for >>>>>>>> inclusion in the specification) so we need to follow some code fi= rst >>>>>>>> rules that I don=E2=80=99t remember of the top of my head? So why= not start >>>>>>>> out >>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also ad= d a >>>>>>>> test application looks like you can just use the root [2] of OVMF >>>>>>>> for >>>>>>>> that. That way the project is not blocked. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> We can have a conversation on the mailing list about better place= s >>>>>>>> to >>>>>>>> put stuff, and it should be easy enough to move stuff around if >>>>>>>> everything else is working. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [1] find OvmfPkg -iname '*Virtio*.inf' >>>>>>>>=20 >>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf >>>>>>>>=20 >>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.i= nf >>>>>>>> | >>>>>>>> grep MODULE_TYPE >>>>>>>>=20 >>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13: MODULE_TYPE >>>>>>>> =3D UEFI_APPLICATION >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Andrew Fish >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 3/30/21, Ethin Probst via groups.io > >>>>>>>> >> >>>>>>>> > >>>>>>>> >>> >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >> >>>>>>>> =3Dgmail.com@groups= .io >>>>>>>> > >>>>>>>> >>>> wrote: >>>>>>>>=20 >>>>>>>> I agree. Plus, it gives me a chance to finally learn the ED= K2 >>>>>>>> build >>>>>>>> system and how it works! I've been working on a hobby OS as= a >>>>>>>> side >>>>>>>> project and, though learning from other code examples from >>>>>>>> OSes >>>>>>>> is >>>>>>>> fun, I have to say that learning from the firmware code lik= e >>>>>>>> from >>>>>>>> SeaBIOS has been some of the most enlightening and >>>>>>>> interesting >>>>>>>> times >>>>>>>> thus far. >>>>>>>> Thanks for the link to your code, Rafael; once I get virtIO >>>>>>>> support >>>>>>>> in, I can work on HDA support, though I might tackle USB >>>>>>>> support >>>>>>>> second and HDA third. We'll see, but VirtIO definitely is >>>>>>>> coming >>>>>>>> first. >>>>>>>>=20 >>>>>>>> As I said before, I look forward to working with all of you >>>>>>>> wonderful >>>>>>>> people! >>>>>>>>=20 >>>>>>>> On 3/30/21, Rafael Rodrigues Machado >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> This would be amazing so people can continue my work >>>>>>>> related >>>>>>>> to >>>>>>>> accessibility at BIOS. Something desired by the blind >>>>>>>> people >>>>>>>> since the >>>>>>>> 90's >>>>>>>> Just for reference, this is what I have done: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility= >>>>>>>> > >>>>>>>> >>>>>>>> >> >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Rafael >>>>>>>>=20 >>>>>>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst >>>>>>>> > >>>>>>>> = >>> >>>>>>>> escreveu: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hello everyone, >>>>>>>>=20 >>>>>>>> This is the first time I've ever contributed to EDK= 2. >>>>>>>> As >>>>>>>> part of GSoC >>>>>>>> 2021, I have submitted a proposal to implement a UE= FI >>>>>>>> audio output >>>>>>>> protocol that will utilize the VirtIO sound driver. >>>>>>>> I've >>>>>>>> already >>>>>>>> submitted a draft proposal, and apologize if I've >>>>>>>> done >>>>>>>> things out of >>>>>>>> order. This is my first time doing GSoC 2021, and >>>>>>>> contributing to EDK2 >>>>>>>> felt like a really fun thing to do! >>>>>>>>=20 >>>>>>>> I look forward to working with you guys on this and >>>>>>>> any >>>>>>>> future projects! >>>>>>>> :-) >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Signed, >>>>>>>> Ethin D. Probst >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Signed, >>>>>>>> Ethin D. Probst >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Signed, >>>>>>>> Ethin D. Probst >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Signed, >>>>>> Ethin D. Probst >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> -- >> Signed, >> Ethin D. Probst >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > Signed, > Ethin D. Probst --Apple-Mail=_7CB7684E-5A71-42CD-90B4-FAB224EFC647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ethin,
In terms of defining the protocol stack i= t is good to start with the producers and consumers and think about the pro= blem from both perspectives. It is easy enough to think about the producer = part of it as you are thinking about writing the driver. The driver is goin= g to consume things like the PCI I/O Protocol. 
<= br class=3D"">
The consumer of the sound Protocol is g= oing to most likely be generic EFI platform code, and possibly an OS loader= . In the boot process Audio has traditionally be used for error codes, sign= of life (for example the famous Mac startup sound). We are also would like= to have the option of enabling better accessibility features, especially f= or people how are visually impaired. These days a lot of software engineers= think of disk space as free and really don=E2=80=99t consider the size of = software, but this is not true for firmware. Firmware generally lives in NO= R FLASH that is considered expensive (it is more expensive than NAND, but a= t the same time more reliable) so firmware implementations are constrained = by the size of the code that can be carried, and the size of assets/resourc= es that can be used for user interfaces. The OS loader is some what less co= nstrained, but it still has to share the EFI System Partition on the disk w= ith potentially other OS loaders. 

So the consumer wants a protocol that is unleveled a= nd focused on the task at hand. I=E2=80=99m not too caught up on the names = but in general I think things you want are (How many knobs we need is proba= bly better answered by an audiophile, and that is not me):
1) CompatibleBuffer() - Does driver support this buffer format. = ;
2) PlayBuffer() - Play the sound
a) We pr= obably want a synchronous and asynchronous version of this API. For example= you don=E2=80=99t want to slow down the boot to wait for a boot beep to co= mplete, and you may chose to implement an API that waits for the sound to c= omplete (and do some GUI work in parallel) vs. blocking on the sound. =
b) async in EFI usually means you return a pointer to an EFI_EV= ENT that gets signaled on completion.  
3) StopBu= ffer() - In case the asynchronous PlayBuffer() needs to be stopped. Think e= rror exit. 
3) SetVolume()/GetVolume() - Set/Get = Volume in units of 0 - 100 (trying to avoid db as that gets into capability= and math that is likely best abstracted by the driver)?
4) Mute()/UnMute() - Mute and volume are often independent features in a= UI keeping them separate in API makes it easier to implement things. =
5) PlayTone() - Maybe for error sounds that don=E2=80= = =99t require canned sound files. Maybe TimeOn, TimeOff, Frequency, and how= many times to repeat. 
6) Do we need tuning valu= es or Tone settings? 

At some point we might consider defining nvram variable for the d= efault state of some of the tunable, especially mute and volume. For exampl= e the user may want to turn off all volume on the system so it would be nic= e if the OS can set the EFI volume and mute. In the short run we can probab= ly use PCD values to set the default values. 
So I think we have a generic AUDIO API on= top and likely a PCI I/O on the bottom. If we need more protocols to manag= e hardware devices then those protocols can be defined in the context of th= at hardware. So for example we would probably end up with an HDA_CODEC prot= ocol. I think the best way to think about this is a disk. A lot of disk ada= pters just produce a raw Block I/O  protocol, but for a more common bu= s like ATA or SCSI you might have an extra driver in place to make the comm= on bits common code. I think some of the same layers may be in place here. = So likely VirtIo is simple and just produces the generic AUDIO API, while a= n HDA audio driver also has to abstract some of the complexity of its hardw= are implementation and standard. 

=
In terms of picking the set of APIs and tunables it i= s probably good to start with VirtIo and USB and see what set make sense an= d what you could and could not implement. HDA Audio is so complex you might= want to look at it in terms of the minute you have to implement to make it= function. Think what assumptions are you forced to make to implement. = ;

This is a vey 1= 0,000 foot view to start with. I think you will need to mix this in the the= reality of how it works in the real world to figure out the right abstract= ion, but then again that is the beauty of having an implementation. Likely = also get some feedback from audiophiles. 

Oh and make sure you don=E2=80=99t go off an = implement a lot of code just because we chose the wrong complexity or abstr= action point. This is the one time we get to change the public APIs so lets= feel free to adjust them to make the most sense for the job at hand. =

Thanks,

Andrew Fish

O= n Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Okay, so looking at the EDK2 driver developers guide, here = are my thoughts:

- Each audio driver will be a bus driver, = even if it doesn't control
buses in the traditional sense.
- I think the initialization sequence should be different: = there
should be an Audi= oDxe, but it should contain three separate bus
drivers for each kind of audio device supported.
- For the VirtIO audio de= vice driver, it'll most likely consume the
PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPU= T_PROTOCOL and
EFI_VIRT= IO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
ordinary UEFI device driver.
- The HDA audio device driver will c= onsume the PCI I/O protocol and
will produce different device handles per HDA controller found. I'= d
produce a handle per = codec, but that seems overkill. Each handle will
be attached to both an audio stream protocol and = a controller
management= protocol. The audio stream protocol will manage the
creation, control, and deletion of audio stre= ams as well as the
pro= cessing of audio data. The controller management protocol is
responsible for allowing applications= or other drivers to manage the
HDA controller itself.

I haven't planned for the U= SB audio device driver yet, but these are
my thoughts so far. What do you guys think? Am I over-co= mplicating
this setup? = How can it be improved upon?
<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">On 4/13/21, Ethin Probst via groups.io
<harlydavidsen=3Dgmail.com@groups.io> wrote:
Hi Andrew,

The developer guide for EDK2 drivers is a godsend. Thank yo= u very
much, and thank you, Mike, for your excellent work on = the guide! I may
just ahve to do my building on Linux and not= Windows -- unless the Bug
-- bug 3302 -- has been fixed. I'l= l have to do testing on Linux, at
any rate, since Windows hos= ts do not support VirtIO emulation and I
can't seem to find a= ny way of emulating them in a guest machine with
Windows as a= host.

On 4/13/21, Andrew Fish <afish@apple.com> wrote:


<= blockquote type=3D"cite" class=3D"">On Apr 13, 2021, at 9:53 AM, Ethin Prob= st <harlydavidsen@= gmail.com>
wrote:

Would i= t be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).


Sure, don=E2=80=99t think= I=E2=80=99ve really used that but as long as I get pointed int
he
right direction I can make it work.

For a device driver the general UEFI model is for the Entry point= of the
driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. T= he Supported()
function
matches on the PCI devi= ces. The Start() function installs the Protocols
to
do work, and the Stop() undoes the Start().

Mike Kinney started this back in the day and it describes how to wri= te
UEFI
drivers:
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-D= river-Writer%27s-Guide

[1]https://github.c= om/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157<= br class=3D"">
Thanks,

Andrew Fi= sh

Here's= how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like<= br class=3D"">it. This function scans the PCIe bus and scans for one of the=
following:
- Vendor ID 0x1AF4, device ID 0x105= 9: VirtIO sound device
- PCI class 0x0C, subclass 0x03, progr= am interface 0x30 or 0x40: for
USB audio interface (I'm only = thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or E= HCI). But maybe EDK2 will take that out of my
hands. If so, i= t will make things easier.
- For USB audio devices I'm not qu= ite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusin= g
on VirtIO sound devices, the VirtIO general initialization = sequence
will occur as outlined in sec. 3 of the VirtIO speci= fication available
at https://www.kraxel.org/virtio/virtio-v1= .1-cs01-sound-v7.html
<https://www.kraxel.org/vir= tio/virtio-v1.1-cs01-sound-v7.html>.
As for actual pro= tocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPU= T_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rath= er simple: there's a buffer for sending and receiving audio
d= ata in PCM streams. So for that we could expose a Reset(),
Re= mapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
P= repare(), Release(), Start(), and Stop() function for the
cor= responding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO= _SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_= PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RE= LEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP cont= rol requests. However, for HDA things are a
lot more complex,= so I'm not sure how that should work.
For VirtIO -- which is= what I'll focus on for now -- everything is
described, in ex= cellent detail, in sec. 5.14 of the above-linked
document. Wh= at are your guys's thoughts thus far and how should
everythin= g be mapped to UEFI interfaces?

On 4/13/21, An= drew Fish <afish@apple.com=  <mailto:afish@apple.com>>
wrote:
Leif,

Since I have put some brain cells around this area= in the past I can be
the
backup and help out t= oo.

I=E2=80=99d also point out if you are havi= ng issues building or have general
questions on how things wo= rk it is fine to use the mailing list. I=E2=80=99ve
got
a
lot of feedback that folks read or search the mail= ing list looking for
answer to their questions so one person = asking can help out a lot of
other
people.

Thanks,

Andrew Fish
On Apr 13,= 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:

Hi = all, especially Ethin.

Apologies for radio sil= ence - last week I was off on holiday, and
before
that ... let's just say corporate acquisitions generate some
distractions.
Anyway, I'm back, and since I'm down as the = mentor for this task, feel
free to spam me with any remaining= /new questions.

/
  Le= if

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst= <harlydavidsen@gm= ail.com
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wrote:
I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.<= br class=3D"">And yes, I was going to make it device independent, as the ma= jority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@redhat.com&nbs= p;<mailto:lersek@= redhat.com>
<mailto:lersek@redhat.com <mailto:le= rsek@redhat.com>>>
wrote:
On 03/31/21 08:41, Nate DeSimone wrote:
Another option is to put the p= rotocol definition in MdeModulePkg and
mark it with the EDKII= _ prefix. For my last =E2=80=9Ccode first=E2=80=9D UEFI spec
= contribution I did this with the PPI that added up getting added.

The new audio protocol should be generic= , only its implementation in
question should be virtio specif= ic.

Please include Gerd Hoffmann (CC'd) in the= protocol design, as well
as
the developers of = the virtio-sound device model in QEMU.

Thanks<= br class=3D"">Laszlo





Tha= nks,

Nate



*From: *<devel@edk2.groups.io&n= bsp;<mailto:de= vel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> on
behalf=
of "Andrew Fish via&nb= sp;groups.io <http://groups.io/> <http://groups.io/
<http://groups.io/>>"
<afish=3Dapple.com@groups.io <mailto:afish=3Dapple.com@groups.io>
<= mailto:apple.com@groups.io <= /span><mailto:apple.co= m@groups.io>>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>"
<devel@edk2.g= roups.io <mailto:devel@edk2.groups.io>
<= mailto:devel@edk2.groups.io = <mailto:devel@= edk2.groups.io>>>,
"afish@apple.com=  <mailto:afish= @apple.com> <mailto= :afish@apple.com
<mailto:afish@apple.com>>" <afish@apple.com <mailto:af= ish@apple.com>
<mailto:afish@apple.com=  <mailto:afish= @apple.com>>>
*Date: *Tuesday, March 30, 2021 at= 10:54 PM
*To: *edk2-devel-groups-io <devel@edk2.groups.io
<<= a href=3D"mailto:devel@edk2.groups.io" class=3D"">mailto:devel@edk2.groups.= io>
<mailto:devel@edk2.groups.io <mailto= :devel@edk2.groups.io>>>,
"harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<= ;mailto:harlydavidsen= @gmail.com <mailto:harlydavidsen@gmail.= com>>"
<harlydavidsen@gmail.com <= mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>=
*Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<= ;mailto:raf= aelrodrigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gm= ail.com>>>
*Subject: *Re: [edk2-devel] VirtIO So= und Driver (GSoC 2021)





  On Mar 30, 2021, at 5:01 P= M, Ethin Probst
<harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>= ;
<m= ailto:harlydavidsen@gmail.com&nbs= p;<mailto:h= arlydavidsen@gmail.com>>
  <mailto:harlydavidsen@gmail.com<= /a> <mailto:harlydavidsen@gmail.com>=
<ma= ilto:harlydavidsen@gmail.com = ;<mailto:ha= rlydavidsen@gmail.com>>>>
wrote:



  I'm wondering wh= ere exactly I should add the VirtIO sound
protocol.
I
  just familiarized myself with the build = system and am about to
test
it
&n= bsp; by building OVMF if possible, but I'm wondering where I should  actually put the protocol and all that stuff. Maybe= there's
  documentation I've missed as well.



Ethin,
=


For the driver I=E2=80=99d mat= ch the patter of OVMF [1] and use
OvmfPkg/VirtioSoundDxe/. Ma= ybe even use one of the other drivers as
a
temp= late.



The protoc= ol is more of a public thing. I think eventually we would
lik= e
to publish the protocol in the UEFI Spec (I can help with t= hat part)
and
that would mean we put the Protoc= ol definition in
MdePkg/Include/Protocol, but we don=E2=80=99= t want to do that before it is
standardized as that causes co= mpatibility issues. So this is a =E2=80=9Ccode
first project= =E2=80=9D (code prototype and then contribute to the UEFI Forum
for
inclusion in the specification) so we need to foll= ow some code first
rules that I don=E2=80=99t remember of the= top of my head? So why not start
out
the proto= col definition OvmfPkg/Include/Protocol. You can also add a
t= est application looks like you can just use the root [2] of OVMF
for
that. That way the project is not blocked.



We can have a conversat= ion on the mailing list about better places
to
= put stuff, and it should be easy enough to move stuff around if
everything else is working.


=
[1] find OvmfPkg  -iname '*Virtio*.inf'
<= br class=3D"">OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/VirtioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPkg/Library/VirtioLib/VirtioLib.inf

OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/VirtioBlk.inf

Ovmf= Pkg/Virtio10Dxe/Virtio10.inf

OvmfPkg/VirtioNet= Dxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioR= ng.inf



[2] /Volu= mes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf
|
grep MODULE_TYPE

EnrollDefaul= tKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
  = ;=3D UEFI_APPLICATION



Thanks,



A= ndrew Fish






  On 3/30/21, Ethin Probs= t via groups.io&n= bsp;<http://groups.io/>
<http://gr= oups.io/ <http://groups.io/>>
<http://groups.io/ <http://groups.io/> <http://groups.io/
<http://groups.io/>>>
 =  <harlydavidsen=3Dgmail.com@groups.io
<mailto:harlydavidsen=3Dgm= ail.com@groups.io>
<mailto:gmail.com@groups.io
<mailto:gmail.com@groups.io&= gt;>
  <mailto:harlydavidsen <mailto:harly= davidsen>=3Dgmail.com@= groups.io
<mailto:gmail.com@groups.io>
<mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>> wrote:
      I agree. Pl= us, it gives me a chance to finally learn the EDK2
build
      system and how it works! I've= been working on a hobby OS as a
side
 &nb= sp;    project and, though learning from other code exa= mples from
OSes
is
  &n= bsp;   fun, I have to say that learning from the firmware co= de like
from
     &nbs= p;SeaBIOS has been some of the most enlightening and
interest= ing
times
      t= hus far.
      Thanks for the l= ink to your code, Rafael; once I get virtIO
support
      in, I can work on HDA support, t= hough I might tackle USB
support
  &n= bsp;   second and HDA third. We'll see, but VirtIO definitel= y is
coming
      = ;first.

      As= I said before, I look forward to working with all of you
&nb= sp;     wonderful
   =    people!

   &n= bsp;  On 3/30/21, Rafael Rodrigues Machado
 &n= bsp;    <rafaelrodrigues.machado@gmail.com
&l= t;mailto:ra= faelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.macha= do@gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>>= ;
      <mailto:rafaelrodrigues.machado= @gmail.com
<mailto:rafaelrodrigues.machado@gmail.com>
<mailto:rafaelrodrigues.machado@gmail.com
<mailto:rafaelrodr= igues.machado@gmail.com>>>>
   = ;   wrote:

   &n= bsp;      This would be amazing so people can= continue my work
related
to
&nbs= p;         accessibility at BI= OS. Something desired by the blind
people
 = ;         since the
          90's
          Just= for reference, this is what I have done:


https://github.com/RafaelRMachado/Msc_UefiHda_PreO= s_Accessibility
<https://github.com/Rafa= elRMachado/Msc_UefiHda_PreOs_Accessibility>
<https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
<https://github.com/RafaelRMachado/Msc_Ue= fiHda_PreOs_Accessibility>>

 &n= bsp;        Thanks
&n= bsp;         Rafael

         = ; Em seg, 29 de mar de 2021 20:24, Ethin Probst
 &n= bsp;        <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
<mailto:harlydav= idsen@gmail.com <<= a href=3D"mailto:harlydavidsen@gmail.com" class=3D"">mailto:harlydavidsen@g= mail.com>>>
      =     escreveu:


            =   Hello everyone,

   =            This is t= he first time I've ever contributed to EDK2.
As
            &n= bsp; part of GSoC
      &n= bsp;       2021, I have submitted a prop= osal to implement a UEFI
      =         audio output
=             &nb= sp; protocol that will utilize the VirtIO sound driver.
= I've
         &n= bsp;    already
    &= nbsp;         submitted a draf= t proposal, and apologize if I've
done
 &n= bsp;            = ;things out of
       &nbs= p;      order. This is my first time doing GS= oC 2021, and
        =       contributing to EDK2
&nbs= p;            &= nbsp;felt like a really fun thing to do!

 = ;            &n= bsp;I look forward to working with you guys on this and
any          &n= bsp;   future projects!
   &nbs= p;          :-)

         = ;     --
    &nb= sp;         Signed,
           &n= bsp;  Ethin D. Probst









      --
      Signed,
 &n= bsp;    Ethin D. Probst





  --
  Signed,
  Ethin D. Probst









--
Signed,
Ethin D. Probst









<= br class=3D"">--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst

<= br class=3D"">



<= /blockquote>

-- =
Signed,
Ethin D. Probst

--Apple-Mail=_7CB7684E-5A71-42CD-90B4-FAB224EFC647--