Hi Cezary and Alicja, Just chiming in a bit regarding Geminilake since I figured it out on my end. I have been able to get AVS (at least my port anyways) to run on a Geminilake chromebook after re-signing + re-packing the DSP firmware with the community keys and updating my driver's topology generation to look for the correct SSP's on the NHLT. I dug through the older SKL module in Linux and I noticed the topologies for that specify a "mixer" module (I'm noting it creates an output and an input mixer and binds them together in between the HDA and I2S copier modules). Do these mixer modules do any volume adjustment / volume limiting? as I didn't see any configuration for the mixers aside from the audio format. --CoolStar On Mon, Oct 3, 2022 at 9:09 AM <alicja.michalska@xxxxxxxxxxxx> wrote: > Hello Cezary, Amadeusz and CoolStar. > > I'm sure you're waiting for update from me, but unfortunately I got really > sick with tonsillitis. Hopefully it clears up a bit tomorrow. > > I did some preliminary testing as CoolStar mentioned, but I would like to > compare results with GeminiLake Refresh board (google/octopus) that should > be arriving tomorrow. It also uses DA7219 + 2x max98357a (max98357a is a > mono amplifier, so there are two amplifiers on the board - one per channel). > > Just from multimeter measurements there's nothing out of ordinary. 5.12v > (so basically 5v) driving max98357a, resulting with 2.7v on speaker output > which is within spec. I'm still learning how to use an oscilloscope, but > I've noticed that Vpp parameter goes up to 2.4v if you set the volume to > 100% (I'm testing on google/reef baseboard which is ApolloLake N3350 with > DA7219 + 2x max98357a). If you set volume to ~66% it stays around 2v and > speakers don't heat up. > > Here you can see that even without any audio playing, left speaker is > significantly warmer than right one. I began playback with volume set to > 25%, then increased it to 65% and then 100%. Once speaker reaches 60*C, > it's permanently damaged. Working speaker has 3.7Ohm resistance, while > damaged one has 3.9Ohm. > You can also see a pair of max98357a's heating up in the background while > playing with volume set to 100% - they reach 40*C. > > https://elly.rocks/tmp/avs_fryingpan.mp4 > Speaking of which, reading trough the code I've noticed that you intend on > supporting GLK platform. We don't have firmware signed with community keys > (GLK doesn't accept Intel-signed keys) so I've been wondering - would it be > possible for you to provide such FW? > > It is really baffling to me, because as far as we both (CoolStar and me) > see, max98357a is a very simple amplifier controlled by setting GPIO pin > low or high. Conclusion would be that the problem lies in how AVS is > driving ADAU7002 or DA7219, but I'm definitely not in shape right now to > read trough AVS code once again. > > > Best regards, > Alicja Michalska > -- > Sent from Tutanota Client for Linux x86_64 > > > > Oct 2, 2022, 00:09 by coolstarorganization@xxxxxxxxx: > > > Hi Cezary, > > I was able to get a capture streams working. Thanks for the guidance > on the order of operations for that. For the final iteration of my driver > port I'm going to be grabbing data from the NHLT to populate topologies it > generates so that should have less hardcoding. > > > > Regarding the volume problem, Alicja here ran some tests with AVS on > linux with a scope connected to the output pins of the max98357a (we're > testing on various Skylake, Kaby Lake and Apollo Lake chromebooks -- I > unfortunately blew the left speaker on pantheon here during testing (and > Alicja blew a left speaker on snappy). We're using topology files grabbed > from Chrome OS's Apollo Lake image (I edited the virtual bus id to get it > working on Kaby Lake here), and it seems there's nothing referencing DSM > inside either the alsa configs or topology. > > --CoolStar > > > > On Thu, Sep 29, 2022 at 9:41 AM Rojewski, Cezary <> > cezary.rojewski@xxxxxxxxx> > wrote: > > > >> > >> Hello, > >> > >> > >> > >> > >> > >> Indeed, there are means on dealing with volume problem you describe. > Not all of them are free though and we cannot share such to the community > without client’s ACK. > >> > >> > >> Judging by the max98357a, platform of yours is a Chromebook device, > perhaps AML-based, e.g.: Atlas. Said configuration contains the DSM module > which addresses the problem. The DSM topology and the configuration should > be available to public, so filtering google’s public domain should yield > positive results. > >> > >> > >> > >> > >> > >> I advise against hardcoding anything within the driver. Within a week > or two, tools for compiling the topology as well as several dozens of > examples should be present on the upstream, that is on the >> > github.com/thesofproject <http://github.com/thesofproject>>> . > >> > >> > >> But yes, there is a requirement for certain ordering of operations. In > general, you should be creating stuff from input to output (precisely in > that direction). For capture, input stands at BE side while for playback > it’s FE instead. There’s also part about configuring the actual hardware > that is represented in ASoC as a BE. Files: avs/path.c and avs/pcm.c should > provide the pattern you seek. > >> > >> > >> > >> > >> > >> > >> > >> > >> Kind regards, > >> > >> > >> Czarek > >> > >> > >> > >> > >> > >> From:>> CoolStar Organization <>> coolstarorganization@xxxxxxxxx>> > > >> >> Sent:>> Wednesday, September 28, 2022 11:17 PM > >> >> To:>> Rojewski, Cezary <>> cezary.rojewski@xxxxxxxxx>> > > >> >> Cc:>> >> amadeuszx.slawinski@xxxxxxxxxxxxxxx > >> >> Subject:>> Re: Buffer overflow in AVS driver > >> > >> > >> > >> > >> Hi Czarek, > >> > >> > >> You can mention CoolStar in the Reported-by tag, as that’s the > pseudonym I go by. > >> > >> > >> > >> > >> > >> Also I had 2 questions regarding AVS. > >> > >> > >> > >> > >> > >> A friend and I both noticed on max98357a that increasing the volume in > the OS past 70% can destroy the speakers. Is there a module or something > that could be bound on the speaker path to limit the volume as max98357a > itself just has an on/off switch? (I noticed catpt has volume controls. > Maybe AVS’s updown mix?). > >> > >> > >> > >> > >> > >> Also, I managed to get my AVS port to output sound on another OS (I’m > not using topology files and am hard coding the path). However I noticed > I’ve been unable to record sound. I noticed for output streams the > initialization sequence is: > >> > >> > >> 1. Create pipeline 0 > >> > >> > >> 2. Create i2s link output path on pipeline 0 > >> > >> > >> 3. Grab HDA render stream & program BDL > >> > >> > >> 4. Create pipeline 1 > >> > >> > >> 5. Create HDA output path on pipeline 1 with virtual link address > (HDA stream tag - 1) > >> > >> > >> 6. Bind pipeline 1 to 0 > >> > >> > >> 7. Set pipeline 0 and then 1 to reset & paused > >> > >> > >> 8. Start HDA stream playback > >> > >> > >> 9. Set pipelines 1 and then 0 to running > >> > >> > >> > >> > >> > >> I’ve been attempting to do a similar setup for input (except with i2s > link input path, an HDA capture stream, and HDA input path) but I don’t see > any input. Is there a particular order for input initialization for it to > work? (Similar to how for the output I had to set up the HDA stream before > creating the HDA pipeline before I could get any sound output?) > >> > >> > >> > >> > >> > >> —CoolStar > >> > >> > >> > >> > >> > >> On Wed, Sep 28, 2022 at 1:09 PM Rojewski, Cezary <>> > cezary.rojewski@xxxxxxxxx>> > wrote: > >> > >> > >>> > >>> Hello, > >>> > >>> > >>> > >>> > >>> > >>> Please excuse my delay in response. We appreciate the input – in > future, please do not be afraid to email us with alsa-devel in CC. It’s > easier to not have the mail missed that way. > >>> > >>> > >>> > >>> > >>> > >>> In regard to the actual bug, highly unlikely but indeed you’re > correct. While my response is delayed, patch fixing the problem in our > internal tree was not. Said patch should soon appear on the alsa-devel > mailing list. Are there any names that you would like us to mention in the > relevant commit message (through “Reported-by:” tag)?. > >>> > >>> > >>> > >>> > >>> > >>> Kind regards, > >>> > >>> > >>> Czarek > >>> > >>> > >>> > >>> > >>> > >>> From:>>> CoolStar Organization <>>> coolstarorganization@xxxxxxxxx>>> > > > >>> >>> Sent:>>> Saturday, September 10, 2022 10:00 PM > >>> >>> To:>>> Rojewski, Cezary <>>> cezary.rojewski@xxxxxxxxx>>> >; > >>> amadeuszx.slawinski@xxxxxxxxxxxxxxx > >>> >>> Subject:>>> Buffer overflow in AVS driver > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> > >>> I've been looking at porting the avs driver you've written to another > OS. During the process I noticed a potential buffer overflow issue in ipc.c. > >>> > >>> > >>> > >>> > >>> > >>> I noticed that ipc->rx.data is allocated a buffer of > `AVS_MAILBOX_SIZE` (or 4096 bytes) in the init, and this buffer is not > allocated anywhere else. In avs_dsp_receive_rx, if the msg type is set to a > large config get, it sets the size to the arbitrary value from the msg > struct without any checks, and then immediately does a memcpy to the buffer. > >>> > >>> > >>> > >>> > >>> > >>> I'd highly suggest putting a check to ensure this doesn't go larger > than AVS_MAILBOX_SIZE to avoid a buffer overflow as that could crash the > system (or potentially be a vulnerability to take over the host system if > an attacker somehow gets code execution on the DSP?) > >>> > >>> > >>> --CoolStar > >>> > >>> > >
