[coreboot] How to create correct (HD Audio/Azalia) verb tables (was: f2a85-m related topics)

[Paul Menzel]

Dear Rudolf,


Am Donnerstag, den 28.03.2013, 08:36 +0100 schrieb Rudolf Marek:

[…]

> > No idea. As you know already, according to Jens the Verb Table format is
> > undocumented and Realtek does not give out any information [2].
> >
> > What chip do you have? Realtek ALC887? At least that is what searching
> > for »f2a85-m realtek alc« seems to suggest.
> 
> Yes  think so. I my patch will simply write that verbs.

thanks to the helpful reply of the ALSA developer Takashi Iwai [1], we
can use some tools from ALSA to decode the verb tables.


Am Dienstag, den 02.04.2013, 12:08 +0200 schrieb Takashi Iwai:
At Thu, 28 Mar 2013 22:56:37 +0100,
> Paul Menzel wrote:

[…]

> Our developer Rudolf suggests to take the values from
> > 
> >     /sys/class/sound/hwC1D0/init_pin_configs
> > 
> > when running the vendor BIOS [2].
> 
> Yes, that would work.  You don't have to initialize the codec fully
> just to get the initial pin configs.  Pass probe_only=1 to
> snd-hda-intel driver so that it will skip the codec initializations
> but just probing the codecs.  The sysfs file should be available even
> in this mode.
> 
> > How can a correct verb table be verified?
> 
> It's difficult to say what's correct in general, because the pin setup
> is what's really depending on the hardware.  Also, BIOS doesn't always
> give a correct pin config.  There might be the pin config overridden
> by *.INI file on Windows.
> 
> Also, BIOS may set up more than pin configs.  It may set also some
> COEF verbs.
> 
> > As for the ASRock E350M1 [4][5], I attach the output of `alsa-info.sh`
> > [6] when running coreboot. The one running with the vendor BIOS is
> > uploaded to the server [7] due to the size limit of this mailing list.
> > 
> >         $ wdiff vendorbios coreboot # init_pin_configs
> >         0x11 [-0x411111f0-] {+0x411110f0+}
> >         0x12 0x411111f0
> >         0x14 [-0x01014010-] {+0x01014030+}
> >         0x15 [-0x01011012-] {+0x01011031+}
> >         0x16 [-0x01016011-] {+0x01016032+}
> >         0x17 [-0x411111f0-] {+0x01012033+}
> >         0x18 [-0x01a19840-] {+0x01a19850+}
> >         0x19 [-0x02a19950-] {+0x02a19c80+}
> >         0x1a [-0x0181304f-] {+0x01813051+}
> >         0x1b [-0x02214120-] {+0x02214c40+}
> >         0x1c [-0x411111f0-] {+0x9933105f+}
> >         0x1d [-0x4005e601-] {+0x00000100+}
> >         0x1e [-0x01452130-] {+0x01441070+}
> >         0x1f [-0x411111f0-] {+0x41c46060+}
> 
> The values there can be decoded by hda-decode-pincfg program included
> in hda-emu:
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git
> 
> In the case above, pins 0x14-16 are changed to have association number
> 3 instead of 1, and add the pin 0x17 as the side channel jack.


[…]


Thanks,

Paul


[3] http://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/060775.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130403/fcf7df6d/attachment.sig>