Hi all
The board is finally in. I'm aware that David bought it (i think he has f2a85-m CSM version which is USA specific), is there anyone else? PaulePanter maybe?
Has anyone tried "hot flashing" ? It seems linux crashes if I simply unplug the flash. I tried to work around and disabled SMI by software. But I want to be sure it happens also to other people.
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_pin_configs
Is it all?
The last, so far known issue is that SeaBIOS likes to boot only from first AHCI port. I need to check this.
Thanks Rudolf
On Tue, Mar 26, 2013 at 1:11 PM, Rudolf Marek r.marek@assembler.cz wrote:
Hi all
The board is finally in. I'm aware that David bought it (i think he has f2a85-m CSM version which is USA specific), is there anyone else? PaulePanter maybe?
Has anyone tried "hot flashing" ? It seems linux crashes if I simply unplug the flash. I tried to work around and disabled SMI by software. But I want to be sure it happens also to other people.
I haven't hot flashed very many times but it didn't crash. Maybe I was just lucky?
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_**pin_configs
Is it all?
The last, so far known issue is that SeaBIOS likes to boot only from first AHCI port. I need to check this.
I checked http://www.coreboot.org/ASUS_F2A85-M and it says test virtualization.
Maybe very low priority, but linux still complains "no compatible bridge window" - I suspect it's just some PCI-E config steps.
Anyway, I like where the current build is at. Kudos!
David
Hi there!
El 26/03/13 20:11, Rudolf Marek escribió:
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_pin_configs
I don't have a f2a85-m, but an Asrock 350M1-USB, but PaulePanter told me maybe my own data could be helpful to you, so:
cat /sys/class/sound/hwC1D0/init_pin_configs 0x11 0x411111f0 0x12 0x411111f0 0x14 0x01014010 0x15 0x01011012 0x16 0x01016011 0x17 0x411111f0 0x18 0x01a19840 0x19 0x02a19950 0x1a 0x0181304f 0x1b 0x02214120 0x1c 0x411111f0 0x1d 0x4005e601 0x1e 0x01452130 0x1f 0x411111f0
Have a nice day...
Dear Rudolf,
Am Dienstag, den 26.03.2013, 20:11 +0100 schrieb Rudolf Marek:
The board is finally in.
thank you again for your awesome work! Could you add the log stuff somewhere, please? For example the Wiki [1] or a message to this list.
I'm aware that David bought it (i think he has f2a85-m CSM version which is USA specific), is there anyone else? PaulePanter maybe?
I do *not* have this board. A friend of mine has one. Though he is not capable to test anything.
Has anyone tried "hot flashing" ? It seems linux crashes if I simply unplug the flash. I tried to work around and disabled SMI by software. But I want to be sure it happens also to other people.
That’s strange. What Linux kernel do you use? Do you get any error messages?
The issue with SeaBIOS is gone.
Awesome! Due to a newer SeaBIOS version or coreboot changes?
I will post some coded verb fix.
Nice. What errors do you get?
Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_pin_configs
Is it all?
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.
The last, so far known issue is that SeaBIOS likes to boot only from first AHCI port. I need to check this.
What SeaBIOS version do you use?
Thanks,
Paul
[1] http://www.coreboot.org/ASUS_F2A85-M [2] http://review.coreboot.org/#/c/2553/1/src/mainboard/lippert/frontrunner-af/p...
Dear Andor,
Am Mittwoch, den 27.03.2013, 11:49 +0100 schrieb Alvaro G. [Andor]:
El 26/03/13 20:11, Rudolf Marek escribió:
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_pin_configs
I don't have a f2a85-m, but an Asrock 350M1-USB, but PaulePanter told me maybe my own data could be helpful to you, so:
that was a misunderstanding in #coreboot. As the ASRock E350M1 uses the Realtek ALC892, which is probably different from the one of the ASUS F2A85-M, this will not be useful for the ASUS F2A85-M. But your dump from the vendor BIOS might be useful for the ASRock E350M1 coreboot port.
cat /sys/class/sound/hwC1D0/init_pin_configs 0x11 0x411111f0 0x12 0x411111f0 0x14 0x01014010 0x15 0x01011012 0x16 0x01016011 0x17 0x411111f0 0x18 0x01a19840 0x19 0x02a19950 0x1a 0x0181304f 0x1b 0x02214120 0x1c 0x411111f0 0x1d 0x4005e601 0x1e 0x01452130 0x1f 0x411111f0
Under coreboot with
commit 3cc0d1eb3f611cb7bf0e45d8ccdb0c84f54f54dc Author: David Hendricks dhendrix@chromium.org Date: Tue Mar 26 16:28:21 2013 -0700
exynos5250: assign RAM resources in cpu_init()
Reviewed-on: http://review.coreboot.org/2923
and one patch applied (unrelated to sound) I have
/sys/class/sound/hwC1D0/init_pin_configs: 0x11 0x411110f0 0x12 0x411111f0 0x14 0x01014030 0x15 0x01011031 0x16 0x01016032 0x17 0x01012033 0x18 0x01a19850 0x19 0x02a19c80 0x1a 0x01813051 0x1b 0x02214c40 0x1c 0x9933105f 0x1d 0x00000100 0x1e 0x01441070 0x1f 0x41c46060
which is different.
$ wdiff vendorbios coreboot 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+}
I have no idea about the Verb Table. And as I am only using the normal stereo out, I have not yet noticed any audio problems.
Andor, could you also please reply with the output of `alsa-info.sh`. Mine is attached.
Thanks,
Paul
Hi Paul,
I've posted it to:
http://www.alsa-project.org/db/?f=96ff75103a48ab8e58a216bd12f65d2755679cdc
Is it enough or want me to send it fully to the list?
Thanks!
El 27/03/13 12:17, Paul Menzel escribió:
Dear Andor,
Am Mittwoch, den 27.03.2013, 11:49 +0100 schrieb Alvaro G. [Andor]:
El 26/03/13 20:11, Rudolf Marek escribió:
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_pin_configs
I don't have a f2a85-m, but an Asrock 350M1-USB, but PaulePanter told me maybe my own data could be helpful to you, so:
that was a misunderstanding in #coreboot. As the ASRock E350M1 uses the Realtek ALC892, which is probably different from the one of the ASUS F2A85-M, this will not be useful for the ASUS F2A85-M. But your dump from the vendor BIOS might be useful for the ASRock E350M1 coreboot port.
cat /sys/class/sound/hwC1D0/init_pin_configs 0x11 0x411111f0 0x12 0x411111f0 0x14 0x01014010 0x15 0x01011012 0x16 0x01016011 0x17 0x411111f0 0x18 0x01a19840 0x19 0x02a19950 0x1a 0x0181304f 0x1b 0x02214120 0x1c 0x411111f0 0x1d 0x4005e601 0x1e 0x01452130 0x1f 0x411111f0
Under coreboot with
commit 3cc0d1eb3f611cb7bf0e45d8ccdb0c84f54f54dc Author: David Hendricks <dhendrix@chromium.org> Date: Tue Mar 26 16:28:21 2013 -0700 exynos5250: assign RAM resources in cpu_init() Reviewed-on: http://review.coreboot.org/2923and one patch applied (unrelated to sound) I have
/sys/class/sound/hwC1D0/init_pin_configs: 0x11 0x411110f0 0x12 0x411111f0 0x14 0x01014030 0x15 0x01011031 0x16 0x01016032 0x17 0x01012033 0x18 0x01a19850 0x19 0x02a19c80 0x1a 0x01813051 0x1b 0x02214c40 0x1c 0x9933105f 0x1d 0x00000100 0x1e 0x01441070 0x1f 0x41c46060which is different.
$ wdiff vendorbios coreboot 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+}I have no idea about the Verb Table. And as I am only using the normal stereo out, I have not yet noticed any audio problems.
Andor, could you also please reply with the output of `alsa-info.sh`. Mine is attached.
Thanks,
Paul
Hi Paul,
I'm attaching also a txt with all the dump...
El 27/03/13 12:27, Alvaro G. [Andor] escribió:
Hi Paul,
I've posted it to:
http://www.alsa-project.org/db/?f=96ff75103a48ab8e58a216bd12f65d2755679cdc
Is it enough or want me to send it fully to the list?
Thanks!
On 03/26/2013 01:11 PM, Rudolf Marek wrote:
Hi all
The board is finally in. I'm aware that David bought it (i think he has f2a85-m CSM version which is USA specific), is there anyone else? PaulePanter maybe?
Has anyone tried "hot flashing" ? It seems linux crashes if I simply unplug the flash. I tried to work around and disabled SMI by software. But I want to be sure it happens also to other people.
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_pin_configs
Is it all?
The last, so far known issue is that SeaBIOS likes to boot only from first AHCI port. I need to check this.
Thanks Rudolf
Hi Rudolf, I just got a f2a85-m CSM to test with here at Sage, but we're still waiting for a CPU to drop in before we can do anything.
I suspect that the crash might be caused by the USB3 controller. It could also be the IMC, but I think this is less likely. Both of these run code directly from the ROM chip. If you unplug the chip while they're trying to fetch, it's not surprising that "Bad Things" happen. You could test for this by doing a build that removes these roms and after booting from that version, see if it still crashes when the chip is pulled.
The ahci issue with seabios sounds like an issue I fixed in AGESA a couple of months ago. http://review.coreboot.org/#/c/2165/
Martin
On Wed, Mar 27, 2013 at 9:32 AM, Martin Roth martin.roth@se-eng.com wrote:
On 03/26/2013 01:11 PM, Rudolf Marek wrote:
Hi all
The board is finally in. I'm aware that David bought it (i think he has f2a85-m CSM version which is USA specific), is there anyone else? PaulePanter maybe?
Has anyone tried "hot flashing" ? It seems linux crashes if I simply unplug the flash. I tried to work around and disabled SMI by software. But I want to be sure it happens also to other people.
The issue with SeaBIOS is gone. I will post some coded verb fix. Is there a way how to extract verbs for codec from original system? I did simple: cat /sys/class/sound/hwC1D0/init_**pin_configs
Is it all?
The last, so far known issue is that SeaBIOS likes to boot only from first AHCI port. I need to check this.
Thanks Rudolf
Hi Rudolf,
I just got a f2a85-m CSM to test with here at Sage, but we're still waiting for a CPU to drop in before we can do anything.
I suspect that the crash might be caused by the USB3 controller. It could also be the IMC, but I think this is less likely. Both of these run code directly from the ROM chip. If you unplug the chip while they're trying to fetch, it's not surprising that "Bad Things" happen. You could test for this by doing a build that removes these roms and after booting from that version, see if it still crashes when the chip is pulled.
The ahci issue with seabios sounds like an issue I fixed in AGESA a couple of months ago. http://review.coreboot.org/#/**c/2165/http://review.coreboot.org/#/c/2165/
This is great! Having sage putting resources into the f2a85-m means a lot! (the CSM just indicates that Asus will keep the item stocked longer / support it longer.)
Thanks, David
That’s strange. What Linux kernel do you use? Do you get any error messages?
I think some latest version I need to check when I have time again. It is some panic because LED from keyboard blinks.
The issue with SeaBIOS is gone.
Awesome! Due to a newer SeaBIOS version or coreboot changes?
Don't know it is simply gone. I think new is issue with GART that linux stole it from memory. I need to check all logs carefuly (and post them ;)
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.
The last, so far known issue is that SeaBIOS likes to boot only from first AHCI port. I need to check this.
What SeaBIOS version do you use?
Latest master. Also need to re-check.
Thanks Rudolf
Thanks,
Paul
[1] http://www.coreboot.org/ASUS_F2A85-M [2] http://review.coreboot.org/#/c/2553/1/src/mainboard/lippert/frontrunner-af/p...
Hi Rudolf, I just got a f2a85-m CSM to test with here at Sage, but we're still waiting for a CPU to drop in before we can do anything.
Great! I tested with some cheapest dualcore CPU I could get.
I suspect that the crash might be caused by the USB3 controller. It could also be the IMC, but I think this is less likely. Both of these run code directly from the ROM chip. If you unplug the chip while they're trying to fetch, it's not surprising that "Bad Things" happen. You could test for this by doing a build that removes these roms and after booting from that version, see if it still crashes when the chip is pulled.
Yes IMC seems not to be enabled in legacy BIOS. The USB3 is good idea. But some preliminary test showed that turning off SMI helps. I need to re-check again. My intention is to make it as friendly as possible for other people so they dont need any flashing device, only extra chips.
The ahci issue with seabios sounds like an issue I fixed in AGESA a couple of months ago. http://review.coreboot.org/#/c/2165/
Great, I need to check if the issue still exists. I only tried recently with two hard drive which it found OK. I was suspecting some kind of PHY problem.
Suspend and resume does not work for me because I'm using 32mbit AMIC chip. I have some patch which adds this to coreboot. But not tested yet.
I'm glad that number of users of this board has risen ;) My plan is to add support for voltage control stuff too.
Thanks Rudolf
Martin
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_configswhen 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
That would make a good wiki page. Verb tables is a common problem.
Thanks, Marc
On Wed, Apr 3, 2013 at 2:58 AM, Paul Menzel < paulepanter@users.sourceforge.net> wrote:
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_configswhen 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
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Alvaro G. [Andor] -
David Hubbard -
Marc Jones -
Martin Roth -
Paul Menzel -
Rudolf Marek