From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by mx.groups.io with SMTP id smtpd.web09.4059.1618349940400329264 for ; Tue, 13 Apr 2021 14:39:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=Qx3vChgj; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 13DLWYVY012190; Tue, 13 Apr 2021 14:38:59 -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=1Ac02mkAVTZd8l8e8hovu/6FNlKvope76NonN1YAzOU=; b=Qx3vChgjTb+hkBWi+O/NEeXZkpu9iVSctpwmVdmxZ17BO79reyw1iF0KbdLSW8Ng2dgd fW/rjxZ/CrCKJSmqxekJZGl86QfcAgtit4OExpN2n+bD/IB+FdS1tgxQdyHXJOVvuNZJ wWLX9K95/zKnkUklrS5lVA2cLK6em9vto/OKUj87vGK5yMkP0HUEEUYfIkvoU8TpsZ88 PYTehvSWIYyHuAgOQaKSA8MRplGSGRw/39ZskfxkGwl9CSBLMjye3VFgzl4x1BSv4d/A G71KK5UIB8dI/X09rUPUc9ObGcpgyu6m+ekv0kI1qa4G1KocTCG/g1wARC3MBmaG00/A /A== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 37uap3adx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Apr 2021 14:38:59 -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-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRI00EI8USXPLI0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 13 Apr 2021 14:38:57 -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 <0QRI00W00UHNJQ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 13 Apr 2021 14:38:57 -0700 (PDT) X-Va-A: X-Va-T-CD: 7465fa55048cd8249c6ea5d21a328e37 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: bbaeab50-5697-4887-9636-0dfc8229bc91 X-V-A: X-V-T-CD: 7465fa55048cd8249c6ea5d21a328e37 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: aca705a6-e457-49e2-931f-337944d996da X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-13_15:2021-04-13,2021-04-13 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 <0QRI00WAPUSVJZ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 13 Apr 2021 14:38:56 -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 14:38:55 -0700 In-reply-to: Cc: Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann To: devel@edk2.groups.io, harlydavidsen@gmail.com References: <16713E6D64EE917D.25648@groups.io> <2379DE31-D6E1-491E-AE22-416085D73765@intel.com> <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> 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-13_15:2021-04-13,2021-04-13 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_84AE23C5-72B7-4E19-934E-ADD3C1FF5D3D" --Apple-Mail=_84AE23C5-72B7-4E19-934E-ADD3C1FF5D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 13, 2021, at 9:53 AM, Ethin Probst wrot= e: >=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 Sure, don=E2=80=99t think I=E2=80=99ve really used that but as long as I g= et 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 d= river to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() function= matches on the PCI devices. The Start() function installs the Protocols to= do work, and the Stop() undoes the Start().=20 Mike Kinney started this back in the day and it describes how to write UEF= I drivers: https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Drive= r-Writer%27s-Guide [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/D= riverBinding.h#L157 Thanks, Andrew Fish > 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 available > 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 ge= neral >> 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 for >> answer to their questions so one person asking can help out a lot of ot= her >> 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 befo= re >>> 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. >>>=20 >>> / >>> Leif >>>=20 >>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst >> >> wro= te: >>> 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 well a= s >>>> 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 >" >>>>> >>, >>>>> "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 protoco= l. >>>>> 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 would >>>>> like >>>>> to publish the protocol in the UEFI Spec (I can help with that part) >>>>> and >>>>> that would mean we put the Protocol definition in >>>>> MdePkg/Include/Protocol, but we don=E2=80=99t want to do that before= 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 UE= FI Forum >>>>> for >>>>> inclusion in the specification) so we need to follow some code first >>>>> rules that I don=E2=80=99t remember of the top of my head? So why no= t start >>>>> out >>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add a >>>>> test application looks like you can just use the root [2] of OVMF fo= r >>>>> that. That way the project is not blocked. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> We can have a conversation on the mailing list about better places t= o >>>>> 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 -- *.inf = | >>>>> 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.i= o >>>>> >>> wrote: >>>>>=20 >>>>> I agree. Plus, 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 >>>>> project and, though learning from other code examples from >>>>> OSes >>>>> is >>>>> fun, I have to say that learning from the firmware code like >>>>> from >>>>> SeaBIOS has been some of the most enlightening and interestin= g >>>>> 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 EDK2. >>>>> As >>>>> part of GSoC >>>>> 2021, I have submitted a proposal to implement a UEFI >>>>> audio output >>>>> protocol that will utilize the VirtIO sound driver. >>>>> I've >>>>> already >>>>> submitted a draft proposal, and apologize if I've don= e >>>>> 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 > --=20 > Signed, > Ethin D. Probst >=20 >=20 >=20 --Apple-Mail=_84AE23C5-72B7-4E19-934E-ADD3C1FF5D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 13, 2= 021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Would it be possible for us to conduct discussion on the UEFI talkbo= x?
I don't mind using e= mail, but things could definitely get moving
quicker over there (though its not a requirement obvi= ously).


Sure, do= n=E2=80=99t think I=E2=80=99ve really used that but as long as I get pointe= d 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]. The Supported() function matches on the PCI devices. The Start() funct= ion installs the Protocols to do work, and the Stop() undoes the Start(). <= /span>

Mike Kinney starte= d this back in the day and it describes how to write UEFI drivers: https://github.com/tianocore/tianocore.github.io/w= iki/UEFI-Driver-Writer%27s-Guide


Thanks= ,

Andrew Fish

Here's how I general= ly envision the driver functioning:

1. Firmware/platform c= ode calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for o= ne of the
following:
- Vendor ID 0x1AF4, devic= e 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
han= ds. 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 t= he above cases are found, appropriate driver
initialization occurs. Since for the time being I am = solely focusing
on Virt= IO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of t= he VirtIO specification available
at <= a href=3D"https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html" sty= le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var= iant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: au= to; text-align: start; text-indent: 0px; text-transform: none; white-space:= normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -= webkit-text-stroke-width: 0px;" class=3D"">https://www.kraxel.org/virtio/vi= rtio-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
da= ta in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmC= onfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SN= D_R_JACK_GET_CONFIG,
VI= RTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_= SND_R_PCM_PREPARE,
VIR= TIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control request= s. 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-lin= ked
document. What are = your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com&= gt; wrote:
Leif,

Since I have put some brain cells aroun= d this area in the past I can be the
backup and help out too.=

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 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> wrot= e:

Hi all, especially Ethin.
Apologies for radio silence - last week I was off on holiday, a= nd before
that ... let's just say corporate acquisitions gene= rate some
distractions.
Anyway, I'm back, and s= ince I'm down as the mentor for this task, feel
free to spam = me with any remaining/new questions.

/
   Leif

On Tue, Apr 6, 2= 021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>&= gt; wrote:
I'll attach the bug for the build tools to the BZ = shortly.
Laszlo, thanks for that. I don't know their email ad= dresses though.
And yes, I was going to make it device indepe= ndent, as the majority
(if not all) of UEFI protocols are.
On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>
wrote:
<= blockquote type=3D"cite" class=3D"">On 03/31/21 08:41, Nate DeSimone wrote:=
Another option is to pu= t the protocol definition in MdeModulePkg and
mark it with th= e 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 ge= neric, only its implementation in
question should be virtio s= pecific.

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

Thanks
Laszlo





Thanks,<= br class=3D"">
Nate



*From: *<devel@edk2.groups.io = <mailto:devel@= edk2.groups.io>> on behalf
of "Andrew Fish via groups.io <http://groups.io/>"<a= fish=3Dapple.com@groups.io <= /span><mailto:apple.co= m@groups.io>>
*Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>"
<devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
"afish@apple.com <mailto:afish@apple.com>" <afish@apple.com
<mailto:afish@apple.com>>
*Date: *Tuesday, March 30, 2021 at 10:54 PM
*To: *edk= 2-devel-groups-io <de= vel@edk2.groups.io
<mailto:devel@edk2.groups.io>>,
"harlydavidsen@gmail.com=  <mailto:harlydavidsen@gmail.com>= ;"
<= harlydavidsen@gmail.com <mailto:harlyda= vidsen@gmail.com>>
*Cc: *Rafael Rodrigues Machado &= lt;rafaelro= drigues.machado@gmail.com
<mailto:rafaelrodrigues.machado@gmail.c= om>>
*Subject: *Re: [edk2-devel] VirtIO Sound Drive= r (GSoC 2021)




   On Mar 30, 2021, at 5:01 PM, = Ethin Probst <harl= ydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
&= nbsp;  <= mailto:harlydavidsen@gmail.com&nb= sp;<mailto:= harlydavidsen@gmail.com>>>
wrote:
=


   I'm wonderin= g where 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 match the patter of OVMF [1] and use
OvmfPkg/Virt= ioSoundDxe/. Maybe even use one of the other drivers as a
tem= plate.



The proto= col is more of a public thing. I think eventually we would
li= ke
to publish the protocol in the UEFI Spec (I can help with = that part)
and
that would mean we put the Proto= col definition in
MdePkg/Include/Protocol, but we don=E2=80= =99t want to do that before it is
standardized as that cause= s compatibility issues. So this is a =E2=80=9Ccode
first proj= ect=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 conversation on the mail= ing list about better places to
put stuff, and it should be e= asy enough to move stuff around if
everything else is working= .



[1] find OvmfP= kg  -iname '*Virtio*.inf'

OvmfPkg/VirtioP= ciDeviceDxe/VirtioPciDeviceDxe.inf

OvmfPkg/Vir= tioScsiDxe/VirtioScsi.inf

OvmfPkg/Library/Virt= ioMmioDeviceLib/VirtioMmioDeviceLib.inf

OvmfPk= g/Library/VirtioLib/VirtioLib.inf

OvmfPkg/Virt= ioGpuDxe/VirtioGpu.inf

OvmfPkg/VirtioBlkDxe/Vi= rtioBlk.inf

OvmfPkg/Virtio10Dxe/Virtio10.inf
OvmfPkg/VirtioNetDxe/VirtioNet.inf

OvmfPkg/VirtioRngDxe/VirtioRng.inf



[2] /Volumes/Case/edk2-github/OvmfPkg&= gt;git grep APPLICATION -- *.inf |
grep MODULE_TYPE

EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MOD= ULE_TYPE
   =3D UEFI_APPLICATION



Thanks,



Andrew Fish






   On 3/30/21, Ethin Probst via group= s.io <http://groups.io/>
<http://groups.io/ <http://groups.io/>>
   <harlydavids= en=3Dgmail.com@groups.io <mailto:gmail.com@= groups.io>
   <mailto:harlydavidsen = <mailto:harlydavidsen>=3Dgmail.com@groups.io
<mailto:gmail.com@groups.io>>> wrote:
       I agr= ee. Plus, it gives me a chance to finally learn the EDK2
buil= d
       system and how it= works! I've been working on a hobby OS as a
side
       project and, though learning f= rom other code examples from
OSes
is
       fun, I have to say that le= arning from the firmware code like
from
 &= nbsp;     SeaBIOS has been some of the most enligh= tening and interesting
times
   =     thus far.
    &nb= sp;  Thanks for the link to your code, Rafael; once I get virtIO<= br class=3D"">support
      &nb= sp;in, I can work on HDA support, though I might tackle USB
s= upport
       second and H= DA third. We'll see, but VirtIO definitely is
coming
       first.

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

     = ;  On 3/30/21, Rafael Rodrigues Machado
  = ;     <rafaelrodrigues.machado@gmail.com
<mailto= :rafaelrodrigues.machado@gmail.com>
   =     <mailto:rafaelrodrigues.machado@gmail.com
<mailto= :rafaelrodrigues.machado@gmail.com>>>
 &nbs= p;     wrote:

 &= nbsp;         This would be am= azing so people can continue my work
related
to=
          =  accessibility at BIOS. Something desired by the blind
p= eople
         &= nbsp; since the
      &nbs= p;    90's
     =       Just for reference, this is what I have= done:


https://gi= thub.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
&= lt;https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Access= ibility>

     =       Thanks
   =         Rafael

           = Em seg, 29 de mar de 2021 20:24, Ethin Probst
  &nb= sp;        <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
           escreve= u:


    &nbs= p;          Hello everyon= e,

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

        &nb= sp;      I look forward to working with you g= uys on this and
any
    &nb= sp;          future proje= cts!
         &n= bsp;     :-)

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









       --
=        Signed,
  = ;     Ethin D. Probst







   --
   Signed= ,
   Ethin D. Probst










--
Signed,
Ethin D. Probst








-- 
Signed,
Ethin D. Probst



--Apple-Mail=_84AE23C5-72B7-4E19-934E-ADD3C1FF5D3D--