Re: [PATCH] ALSA: intel_hda - Add dock support for ThinkPad T460s
> Conrad Kostecki <c...@conrad-kostecki.de> hat am 26. April 2016 um 12:10 > geschrieben: > Hi! > The new ThinkPad T460s is the same way affected, as other current ThinkPads > (e.G. X260) generations. > That means, you won't be able to get sound output, when using the Lenovo > CES 2013 docking station series (basic, pro, ultra). > > It can be fixed the same way, as it was already done for X260, > as the T460s uses the same docking connector. > I am attaching a patch, which works for me. > > Cheers > Conrad Sorry, not enough coffee today :( The Patch is for T460p, NOT T460s.
Re: [PATCH] ALSA: intel_hda - Add dock support for ThinkPad T460s
> Conrad Kostecki hat am 26. April 2016 um 12:10 > geschrieben: > Hi! > The new ThinkPad T460s is the same way affected, as other current ThinkPads > (e.G. X260) generations. > That means, you won't be able to get sound output, when using the Lenovo > CES 2013 docking station series (basic, pro, ultra). > > It can be fixed the same way, as it was already done for X260, > as the T460s uses the same docking connector. > I am attaching a patch, which works for me. > > Cheers > Conrad Sorry, not enough coffee today :( The Patch is for T460p, NOT T460s.
[PATCH] ALSA: intel_hda - Add dock support for ThinkPad T460s
Hi! The new ThinkPad T460s is the same way affected, as other current ThinkPads (e.G. X260) generations. That means, you won't be able to get sound output, when using the Lenovo CES 2013 docking station series (basic, pro, ultra). It can be fixed the same way, as it was already done for X260, as the T460s uses the same docking connector. I am attaching a patch, which works for me. Cheers Conrad -- Fixes audio output on a ThinkPad T460s, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki <ck+linuxker...@bl4ckb0x.de> --- linux-4.6-rc5-vanilla/sound/pci/hda/patch_realtek.c 2016-04-26 11:32:09.124832372 +0200 +++ linux-4.6-rc5/sound/pci/hda/patch_realtek.c 2016-04-26 11:32:52.123834807 +0200 @@ -5585,6 +5585,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x5036, "Thinkpad T450s", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x503c, "Thinkpad L450", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x504b, "Thinkpad", ALC293_FIXUP_LENOVO_SPK_NOISE), + SND_PCI_QUIRK(0x17aa, 0x5050, "Thinkpad T460p", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), --
[PATCH] ALSA: intel_hda - Add dock support for ThinkPad T460s
Hi! The new ThinkPad T460s is the same way affected, as other current ThinkPads (e.G. X260) generations. That means, you won't be able to get sound output, when using the Lenovo CES 2013 docking station series (basic, pro, ultra). It can be fixed the same way, as it was already done for X260, as the T460s uses the same docking connector. I am attaching a patch, which works for me. Cheers Conrad -- Fixes audio output on a ThinkPad T460s, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki --- linux-4.6-rc5-vanilla/sound/pci/hda/patch_realtek.c 2016-04-26 11:32:09.124832372 +0200 +++ linux-4.6-rc5/sound/pci/hda/patch_realtek.c 2016-04-26 11:32:52.123834807 +0200 @@ -5585,6 +5585,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x5036, "Thinkpad T450s", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x503c, "Thinkpad L450", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x504b, "Thinkpad", ALC293_FIXUP_LENOVO_SPK_NOISE), + SND_PCI_QUIRK(0x17aa, 0x5050, "Thinkpad T460p", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), --
[PATCH] ALSA: intel_hda - Add dock support for ThinkPad X260
Hi! My shiny new ThinkPad X260 is the same way affected, as older ThinkPad (X*40, X*50) generations. That means, I am unable to get sound output, when I am using the Lenovo CES 2013 docking station series (basic, pro, ultra). It can be fixed the same way, as it was already done for X240 and X250, as the X260 uses the same docking connector. I am attaching my patch, which works for me. Cheers Conrad -- Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki <ck+linuxker...@bl4ckb0x.de> diff -uprN -X linux-4.6-rc4-vanilla/Documentation/dontdiff linux-4.6-rc4-vanilla/sound/pci/hda/patch_realtek.c linux-4.6-rc4/sound/pci/hda/patch_realtek.c --- linux-4.6-rc4-vanilla/sound/pci/hda/patch_realtek.c 2016-04-24 03:26:36.330983586 +0200 +++ linux-4.6-rc4/sound/pci/hda/patch_realtek.c 2016-04-24 03:27:13.737981843 +0200 @@ -5570,6 +5570,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x2218, "Thinkpad X1 Carbon 2nd", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK), + SND_PCI_QUIRK(0x17aa, 0x504a, "ThinkPad X260", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), --
[PATCH] ALSA: intel_hda - Add dock support for ThinkPad X260
Hi! My shiny new ThinkPad X260 is the same way affected, as older ThinkPad (X*40, X*50) generations. That means, I am unable to get sound output, when I am using the Lenovo CES 2013 docking station series (basic, pro, ultra). It can be fixed the same way, as it was already done for X240 and X250, as the X260 uses the same docking connector. I am attaching my patch, which works for me. Cheers Conrad -- Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013 docking station series (basic, pro, ultra). Signed-off-by: Conrad Kostecki diff -uprN -X linux-4.6-rc4-vanilla/Documentation/dontdiff linux-4.6-rc4-vanilla/sound/pci/hda/patch_realtek.c linux-4.6-rc4/sound/pci/hda/patch_realtek.c --- linux-4.6-rc4-vanilla/sound/pci/hda/patch_realtek.c 2016-04-24 03:26:36.330983586 +0200 +++ linux-4.6-rc4/sound/pci/hda/patch_realtek.c 2016-04-24 03:27:13.737981843 +0200 @@ -5570,6 +5570,7 @@ static const struct snd_pci_quirk alc269 SND_PCI_QUIRK(0x17aa, 0x2218, "Thinkpad X1 Carbon 2nd", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK), + SND_PCI_QUIRK(0x17aa, 0x504a, "ThinkPad X260", ALC292_FIXUP_TPT440_DOCK), SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC292_FIXUP_TPT460), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), --
AW: Early microcode not being loaded
> That file is way too big. In fact, it is exactly the size of the newest > ".dat" file from Intel. The kernel doesn't grok that text format, the > microcode updates have to be converted to binary format, first. > I suggest you use "iucode_tool -S --write-earlyfw=ucode.cpio" to generate > your ucode.cpio. > You can find iucode-tool at: > https://gitorious.org/iucode-tool/pages/Home Thanks! That's it. I wasn't aware, that I need to convert first the microcode to binary. It's now working fine. Cheers Conrad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: Early microcode not being loaded
> Hi!
> I'am trying to use the feature of loading early an intel microcode.
> According to the documentation (early-microcode.txt) that should be possible.
>
> I am currently using my own initrd, so I've created a second one, as the docs
> specified and merged it with my own.
>
> Galactica linux # file /tmp/ucode.cpio
> /tmp/ucode.cpio: ASCII cpio archive (SVR4 with no CRC)
>
> Galactica linux # file /tmp/my_own_initrd.cpio
> /tmp/my_own_initrd.cpio: ASCII cpio archive (SVR4 with no CRC)
>
> Galactica linux # cpio -itv < /tmp/ucode.cpio
> drwxr-xr-x 3 root root0 Jul 18 17:01 .
> drwxr-xr-x 3 root root0 Jul 18 17:01 kernel
> drwxr-xr-x 3 root root0 Jul 18 17:01 kernel/x86
> drwxr-xr-x 2 root root0 Jul 18 17:01 kernel/x86/microcode
> -rw-r--r-- 1 root root 1857432 Jul 18 17:01
> kernel/x86/microcode/GenuineIntel.bin
>
> Galactica tmp # cpio -itv < /tmp/my_own_initrd.cpio
> drwxr-xr-x 11 root root0 Jul 18 22:33 .
> drwxr-xr-x 3 root root0 Jul 18 22:33 mnt
> drwxr-xr-x 2 root root0 Jul 18 22:33 mnt/root
> drwxr-xr-x 2 root root0 Jul 18 22:33 lib64
> drwxr-xr-x 2 root root0 Jul 18 22:33 etc
> drwxr-xr-x 2 root root0 Jul 18 22:33 sys
> drwxr-xr-x 2 root root0 Jul 18 22:33 bin
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/ash -> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cat -> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/loadkmap ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cut -> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/setfont ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/kbd_mode ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/echo ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/umount ->
> /bin/busybox
> -rwxr-xr-x 1 root root 2638208 Jul 18 22:33 bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mount ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mdev ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/sleep ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/printf ->
> /bin/busybox
> drwxr-xr-x 3 root root0 Jul 18 22:33 usr
> drwxr-xr-x 2 root root0 Jul 18 22:33 usr/bin
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/setfont ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/kbd_mode ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/printf ->
> /bin/busybox
> drwxr-xr-x 3 root root0 Jul 18 22:33 dev
> crw-r--r-- 1 root root 5, 1 Jul 18 22:33 dev/console
> crw-r--r-- 1 root root 4, 64 Jul 18 22:33 dev/ttyS0
> crw-r--r-- 1 root root 1, 3 Jul 18 22:33 dev/null
> crw-r--r-- 1 root root 1, 5 Jul 18 22:33 dev/zero
> drwxr-xr-x 2 root root0 Jul 18 22:33 proc
> -rwxr-xr-x 1 root root 5707 Jul 18 22:33 init
> lrwxrwxrwx 1 root root5 Jul 18 22:33 lib -> lib64
> drwxr-xr-x 2 root root0 Jul 18 22:33 sbin
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/loadkmap ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/switch_root ->
> /bin/busybox
> lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/mdev ->
> /bin/busybox
> 5174 blocks
>
> Then I merged them, as the docs say:
> cat /tmp/ucode.cpio /tmp/my_own_initrd.cpio > /boot/initramfs-3.15.5.img
>
> Booting works fine with this combined initrd, but there is no new microcode
> applied.
>
> [1.058641] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104
> [1.063259] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104
> [1.068011] microcode: Microcode Update Driver: v2.00
> , Peter Oruba
>
> It's only applied much later, when my microcode_ctl runs as a service.
>
> [ 15.764517] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104
> [ 15.764979] microcode: CPU0 updated to revision 0x105, date = 2011-07-18
> [ 15.765970] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104
> [ 15.766430] microcode: CPU1 updated to revision 0x105, date = 2011-07-18
>
> Where is the problem? Why is the microcode not being loaded early?
>
> Cheers
> Conrad
Does anybody has some idea, why this is not working for me?
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
AW: Early microcode not being loaded
Hi!
I'am trying to use the feature of loading early an intel microcode.
According to the documentation (early-microcode.txt) that should be possible.
I am currently using my own initrd, so I've created a second one, as the docs
specified and merged it with my own.
Galactica linux # file /tmp/ucode.cpio
/tmp/ucode.cpio: ASCII cpio archive (SVR4 with no CRC)
Galactica linux # file /tmp/my_own_initrd.cpio
/tmp/my_own_initrd.cpio: ASCII cpio archive (SVR4 with no CRC)
Galactica linux # cpio -itv /tmp/ucode.cpio
drwxr-xr-x 3 root root0 Jul 18 17:01 .
drwxr-xr-x 3 root root0 Jul 18 17:01 kernel
drwxr-xr-x 3 root root0 Jul 18 17:01 kernel/x86
drwxr-xr-x 2 root root0 Jul 18 17:01 kernel/x86/microcode
-rw-r--r-- 1 root root 1857432 Jul 18 17:01
kernel/x86/microcode/GenuineIntel.bin
Galactica tmp # cpio -itv /tmp/my_own_initrd.cpio
drwxr-xr-x 11 root root0 Jul 18 22:33 .
drwxr-xr-x 3 root root0 Jul 18 22:33 mnt
drwxr-xr-x 2 root root0 Jul 18 22:33 mnt/root
drwxr-xr-x 2 root root0 Jul 18 22:33 lib64
drwxr-xr-x 2 root root0 Jul 18 22:33 etc
drwxr-xr-x 2 root root0 Jul 18 22:33 sys
drwxr-xr-x 2 root root0 Jul 18 22:33 bin
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/ash - /bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cat - /bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/loadkmap -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cut - /bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/setfont -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/kbd_mode -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/echo -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/umount -
/bin/busybox
-rwxr-xr-x 1 root root 2638208 Jul 18 22:33 bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mount -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mdev -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/sleep -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/printf -
/bin/busybox
drwxr-xr-x 3 root root0 Jul 18 22:33 usr
drwxr-xr-x 2 root root0 Jul 18 22:33 usr/bin
lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/setfont -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/kbd_mode -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/printf -
/bin/busybox
drwxr-xr-x 3 root root0 Jul 18 22:33 dev
crw-r--r-- 1 root root 5, 1 Jul 18 22:33 dev/console
crw-r--r-- 1 root root 4, 64 Jul 18 22:33 dev/ttyS0
crw-r--r-- 1 root root 1, 3 Jul 18 22:33 dev/null
crw-r--r-- 1 root root 1, 5 Jul 18 22:33 dev/zero
drwxr-xr-x 2 root root0 Jul 18 22:33 proc
-rwxr-xr-x 1 root root 5707 Jul 18 22:33 init
lrwxrwxrwx 1 root root5 Jul 18 22:33 lib - lib64
drwxr-xr-x 2 root root0 Jul 18 22:33 sbin
lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/loadkmap -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/switch_root -
/bin/busybox
lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/mdev -
/bin/busybox
5174 blocks
Then I merged them, as the docs say:
cat /tmp/ucode.cpio /tmp/my_own_initrd.cpio /boot/initramfs-3.15.5.img
Booting works fine with this combined initrd, but there is no new microcode
applied.
[1.058641] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104
[1.063259] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104
[1.068011] microcode: Microcode Update Driver: v2.00
tig...@aivazian.fsnet.co.uk, Peter Oruba
It's only applied much later, when my microcode_ctl runs as a service.
[ 15.764517] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104
[ 15.764979] microcode: CPU0 updated to revision 0x105, date = 2011-07-18
[ 15.765970] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104
[ 15.766430] microcode: CPU1 updated to revision 0x105, date = 2011-07-18
Where is the problem? Why is the microcode not being loaded early?
Cheers
Conrad
Does anybody has some idea, why this is not working for me?
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
AW: Early microcode not being loaded
That file is way too big. In fact, it is exactly the size of the newest .dat file from Intel. The kernel doesn't grok that text format, the microcode updates have to be converted to binary format, first. I suggest you use iucode_tool -S --write-earlyfw=ucode.cpio to generate your ucode.cpio. You can find iucode-tool at: https://gitorious.org/iucode-tool/pages/Home Thanks! That's it. I wasn't aware, that I need to convert first the microcode to binary. It's now working fine. Cheers Conrad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: Early microcode not being loaded
> On Fri, Jul 18, 2014 at 08:40:42PM +0000, Conrad Kostecki wrote: > > Where is the problem? Why is the microcode not being loaded early? > > CONFIG_MICROCODE_INTEL_EARLY=y set in .config? Yes! Galactica tmp # grep -i microcode /boot/config-3.15.5 CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_MICROCODE_INTEL_EARLY=y # CONFIG_MICROCODE_AMD_EARLY is not set CONFIG_MICROCODE_EARLY=y Cheers Conrad
Early microcode not being loaded
Hi! I'am trying to use the feature of loading early an intel microcode. According to the documentation (early-microcode.txt) that should be possible. I am currently using my own initrd, so I've created a second one, as the docs specified and merged it with my own. Galactica linux # file /tmp/ucode.cpio /tmp/ucode.cpio: ASCII cpio archive (SVR4 with no CRC) Galactica linux # file /tmp/my_own_initrd.cpio /tmp/my_own_initrd.cpio: ASCII cpio archive (SVR4 with no CRC) Galactica linux # cpio -itv < /tmp/ucode.cpio drwxr-xr-x 3 root root0 Jul 18 17:01 . drwxr-xr-x 3 root root0 Jul 18 17:01 kernel drwxr-xr-x 3 root root0 Jul 18 17:01 kernel/x86 drwxr-xr-x 2 root root0 Jul 18 17:01 kernel/x86/microcode -rw-r--r-- 1 root root 1857432 Jul 18 17:01 kernel/x86/microcode/GenuineIntel.bin Galactica tmp # cpio -itv < /tmp/my_own_initrd.cpio drwxr-xr-x 11 root root0 Jul 18 22:33 . drwxr-xr-x 3 root root0 Jul 18 22:33 mnt drwxr-xr-x 2 root root0 Jul 18 22:33 mnt/root drwxr-xr-x 2 root root0 Jul 18 22:33 lib64 drwxr-xr-x 2 root root0 Jul 18 22:33 etc drwxr-xr-x 2 root root0 Jul 18 22:33 sys drwxr-xr-x 2 root root0 Jul 18 22:33 bin lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/ash -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cat -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/loadkmap -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cut -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/setfont -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/kbd_mode -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/echo -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/umount -> /bin/busybox -rwxr-xr-x 1 root root 2638208 Jul 18 22:33 bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mount -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mdev -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/sleep -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/printf -> /bin/busybox drwxr-xr-x 3 root root0 Jul 18 22:33 usr drwxr-xr-x 2 root root0 Jul 18 22:33 usr/bin lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/setfont -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/kbd_mode -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/printf -> /bin/busybox drwxr-xr-x 3 root root0 Jul 18 22:33 dev crw-r--r-- 1 root root 5, 1 Jul 18 22:33 dev/console crw-r--r-- 1 root root 4, 64 Jul 18 22:33 dev/ttyS0 crw-r--r-- 1 root root 1, 3 Jul 18 22:33 dev/null crw-r--r-- 1 root root 1, 5 Jul 18 22:33 dev/zero drwxr-xr-x 2 root root0 Jul 18 22:33 proc -rwxr-xr-x 1 root root 5707 Jul 18 22:33 init lrwxrwxrwx 1 root root5 Jul 18 22:33 lib -> lib64 drwxr-xr-x 2 root root0 Jul 18 22:33 sbin lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/loadkmap -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/switch_root -> /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/mdev -> /bin/busybox 5174 blocks Then I merged them, as the docs say: cat /tmp/ucode.cpio /tmp/my_own_initrd.cpio > /boot/initramfs-3.15.5.img Booting works fine with this combined initrd, but there is no new microcode applied. [1.058641] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104 [1.063259] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104 [1.068011] microcode: Microcode Update Driver: v2.00 , Peter Oruba It's only applied much later, when my microcode_ctl runs as a service. [ 15.764517] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104 [ 15.764979] microcode: CPU0 updated to revision 0x105, date = 2011-07-18 [ 15.765970] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104 [ 15.766430] microcode: CPU1 updated to revision 0x105, date = 2011-07-18 Where is the problem? Why is the microcode not being loaded early? Cheers Conrad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Early microcode not being loaded
Hi! I'am trying to use the feature of loading early an intel microcode. According to the documentation (early-microcode.txt) that should be possible. I am currently using my own initrd, so I've created a second one, as the docs specified and merged it with my own. Galactica linux # file /tmp/ucode.cpio /tmp/ucode.cpio: ASCII cpio archive (SVR4 with no CRC) Galactica linux # file /tmp/my_own_initrd.cpio /tmp/my_own_initrd.cpio: ASCII cpio archive (SVR4 with no CRC) Galactica linux # cpio -itv /tmp/ucode.cpio drwxr-xr-x 3 root root0 Jul 18 17:01 . drwxr-xr-x 3 root root0 Jul 18 17:01 kernel drwxr-xr-x 3 root root0 Jul 18 17:01 kernel/x86 drwxr-xr-x 2 root root0 Jul 18 17:01 kernel/x86/microcode -rw-r--r-- 1 root root 1857432 Jul 18 17:01 kernel/x86/microcode/GenuineIntel.bin Galactica tmp # cpio -itv /tmp/my_own_initrd.cpio drwxr-xr-x 11 root root0 Jul 18 22:33 . drwxr-xr-x 3 root root0 Jul 18 22:33 mnt drwxr-xr-x 2 root root0 Jul 18 22:33 mnt/root drwxr-xr-x 2 root root0 Jul 18 22:33 lib64 drwxr-xr-x 2 root root0 Jul 18 22:33 etc drwxr-xr-x 2 root root0 Jul 18 22:33 sys drwxr-xr-x 2 root root0 Jul 18 22:33 bin lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/ash - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cat - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/loadkmap - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/cut - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/setfont - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/kbd_mode - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/echo - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/umount - /bin/busybox -rwxr-xr-x 1 root root 2638208 Jul 18 22:33 bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mount - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/mdev - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/sleep - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 bin/printf - /bin/busybox drwxr-xr-x 3 root root0 Jul 18 22:33 usr drwxr-xr-x 2 root root0 Jul 18 22:33 usr/bin lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/setfont - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/kbd_mode - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 usr/bin/printf - /bin/busybox drwxr-xr-x 3 root root0 Jul 18 22:33 dev crw-r--r-- 1 root root 5, 1 Jul 18 22:33 dev/console crw-r--r-- 1 root root 4, 64 Jul 18 22:33 dev/ttyS0 crw-r--r-- 1 root root 1, 3 Jul 18 22:33 dev/null crw-r--r-- 1 root root 1, 5 Jul 18 22:33 dev/zero drwxr-xr-x 2 root root0 Jul 18 22:33 proc -rwxr-xr-x 1 root root 5707 Jul 18 22:33 init lrwxrwxrwx 1 root root5 Jul 18 22:33 lib - lib64 drwxr-xr-x 2 root root0 Jul 18 22:33 sbin lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/loadkmap - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/switch_root - /bin/busybox lrwxrwxrwx 1 root root 12 Jul 18 22:33 sbin/mdev - /bin/busybox 5174 blocks Then I merged them, as the docs say: cat /tmp/ucode.cpio /tmp/my_own_initrd.cpio /boot/initramfs-3.15.5.img Booting works fine with this combined initrd, but there is no new microcode applied. [1.058641] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104 [1.063259] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104 [1.068011] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba It's only applied much later, when my microcode_ctl runs as a service. [ 15.764517] microcode: CPU0 sig=0x20661, pf=0x2, revision=0x104 [ 15.764979] microcode: CPU0 updated to revision 0x105, date = 2011-07-18 [ 15.765970] microcode: CPU1 sig=0x20661, pf=0x2, revision=0x104 [ 15.766430] microcode: CPU1 updated to revision 0x105, date = 2011-07-18 Where is the problem? Why is the microcode not being loaded early? Cheers Conrad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: Early microcode not being loaded
On Fri, Jul 18, 2014 at 08:40:42PM +, Conrad Kostecki wrote: Where is the problem? Why is the microcode not being loaded early? CONFIG_MICROCODE_INTEL_EARLY=y set in .config? Yes! Galactica tmp # grep -i microcode /boot/config-3.15.5 CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_MICROCODE_INTEL_EARLY=y # CONFIG_MICROCODE_AMD_EARLY is not set CONFIG_MICROCODE_EARLY=y Cheers Conrad
AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
> On 02/14/2014 10:13 AM, Conrad Kostecki wrote: > >> > >> Does it have DMI? > > > > Unfortunately not. > > > > # dmidecode 2.12 > > # No SMBIOS nor DMI entry point found, sorry. > > > > Sigh. Does anyone have contacts at Soekris who can complain about this > stuff? I don't think, that Soekris will fix this. No model of Soekris ever had implemented DMI. Their BIOS (called comBIOS) is completely written by them. Output is via serial port only. At least I know, that the technical engineers at Soekris respond on sa...@soekris.com. Maybe the patch could be extended, that HPET would be only enabled if there is no ACPI present? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
> On 02/14/2014 10:06 AM, Conrad Kostecki wrote: > > > > Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is > special, as Soekris does not implement ACPI. > > I don't know, how other E6xx systems do work. I guess, there will have > ACPI. There seem not to be many out there. > > This patch is now running for about six months without any problems for > me. > > > > I was also searching for some other systems. I found here only one manual. > > There are at least the same vendor/device id shown, as used also in > Soekris. > > -> http://www.ekf.de/p/pc2/pc2_ug.pdf > > > > Is there maybe any possibility to check for the specific Soekris model? At > least MPTABLE identifies the Soekris: > > [0.00] MPTABLE: OEM ID: Soekris > > [0.00] MPTABLE: Product ID: net6501 > > [0.00] MPTABLE: APIC at: 0xFEE0 > > > > Does it have DMI? Unfortunately not. # dmidecode 2.12 # No SMBIOS nor DMI entry point found, sorry. Cheers Conrad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: [PATCH] x86: HPET force enable for Soekris net6501
> On 02/14/2014 02:23 AM, Conrad Kostecki wrote: > > Hello, > > as the Soekris net6501 does not have any ACPI implementation, HPET > won't get enabled. > > This patch enables HPET on such platforms. > > > > [0.430149] pci :00:01.0: Force enabled HPET at 0xfed0 > > [0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu > > timer > > > > Original patch by Peter Neubauer, slightly modified by me. > > -> http://www.mail-archive.com/soekris- > t...@lists.soekris.com/msg06462.html > > > > Cheers > > Conrad > > Are you sure this won't break any other E6xx platforms? Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is special, as Soekris does not implement ACPI. I don't know, how other E6xx systems do work. I guess, there will have ACPI. There seem not to be many out there. This patch is now running for about six months without any problems for me. I was also searching for some other systems. I found here only one manual. There are at least the same vendor/device id shown, as used also in Soekris. -> http://www.ekf.de/p/pc2/pc2_ug.pdf Is there maybe any possibility to check for the specific Soekris model? At least MPTABLE identifies the Soekris: [0.00] MPTABLE: OEM ID: Soekris [0.00] MPTABLE: Product ID: net6501 [0.00] MPTABLE: APIC at: 0xFEE0 Cheers Conrad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: HPET force enable for Soekris net6501
Hello,
as the Soekris net6501 does not have any ACPI implementation, HPET won't get
enabled.
This patch enables HPET on such platforms.
[0.430149] pci :00:01.0: Force enabled HPET at 0xfed0
[0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Original patch by Peter Neubauer, slightly modified by me.
-> http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html
Cheers
Conrad
Signed-off-by: Peter Neubauer
Signed-off-by: Conrad Kostecki
--- a/arch/x86/kernel/quirks.c 2014-02-14 11:13:27.703432732 +0100
+++ b/arch/x86/kernel/quirks.c 2014-02-14 11:14:32.327496474 +0100
@@ -498,6 +498,25 @@ void force_hpet_resume(void)
}
/*
+ * Soekris net6501, based on Atom E6xx series, does not have ACPI.
+ * HPET should be force enabled on such platforms.
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+ if (hpet_address || force_hpet_address)
+ return;
+
+ force_hpet_address = 0xFED0;
+ force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+ dev_printk(KERN_DEBUG, >dev, "Force enabled HPET at "
+ "0x%lx\n", force_hpet_address);
+ return;
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+e6xx_force_enable_hpet);
+
+/*
* HPET MSI on some boards (ATI SB700/SB800) has side effect on
* floppy DMA. Disable HPET MSI on such platforms.
* See erratum #27 (Misinterpreted MSI Requests May Result in
--- a/include/linux/pci_ids.h 2014-02-14 11:13:00.575408953 +0100
+++ b/include/linux/pci_ids.h 2014-02-14 11:13:37.819442066 +0100
@@ -2854,6 +2854,7 @@
#define PCI_DEVICE_ID_INTEL_82372FB_1 0x7601
#define PCI_DEVICE_ID_INTEL_SCH_LPC0x8119
#define PCI_DEVICE_ID_INTEL_SCH_IDE0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU0x8183
#define PCI_DEVICE_ID_INTEL_ITC_LPC0x8186
#define PCI_DEVICE_ID_INTEL_82454GX0x84c4
#define PCI_DEVICE_ID_INTEL_82450GX0x84c5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: HPET force enable for Soekris net6501
Hello,
as the Soekris net6501 does not have any ACPI implementation, HPET won't get
enabled.
This patch enables HPET on such platforms.
[0.430149] pci :00:01.0: Force enabled HPET at 0xfed0
[0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
Original patch by Peter Neubauer, slightly modified by me.
- http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html
Cheers
Conrad
Signed-off-by: Peter Neubauer pneuba...@bluerwhite.org
Signed-off-by: Conrad Kostecki c...@conrad-kostecki.de
--- a/arch/x86/kernel/quirks.c 2014-02-14 11:13:27.703432732 +0100
+++ b/arch/x86/kernel/quirks.c 2014-02-14 11:14:32.327496474 +0100
@@ -498,6 +498,25 @@ void force_hpet_resume(void)
}
/*
+ * Soekris net6501, based on Atom E6xx series, does not have ACPI.
+ * HPET should be force enabled on such platforms.
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+ if (hpet_address || force_hpet_address)
+ return;
+
+ force_hpet_address = 0xFED0;
+ force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+ dev_printk(KERN_DEBUG, dev-dev, Force enabled HPET at
+ 0x%lx\n, force_hpet_address);
+ return;
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+e6xx_force_enable_hpet);
+
+/*
* HPET MSI on some boards (ATI SB700/SB800) has side effect on
* floppy DMA. Disable HPET MSI on such platforms.
* See erratum #27 (Misinterpreted MSI Requests May Result in
--- a/include/linux/pci_ids.h 2014-02-14 11:13:00.575408953 +0100
+++ b/include/linux/pci_ids.h 2014-02-14 11:13:37.819442066 +0100
@@ -2854,6 +2854,7 @@
#define PCI_DEVICE_ID_INTEL_82372FB_1 0x7601
#define PCI_DEVICE_ID_INTEL_SCH_LPC0x8119
#define PCI_DEVICE_ID_INTEL_SCH_IDE0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU0x8183
#define PCI_DEVICE_ID_INTEL_ITC_LPC0x8186
#define PCI_DEVICE_ID_INTEL_82454GX0x84c4
#define PCI_DEVICE_ID_INTEL_82450GX0x84c5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 02:23 AM, Conrad Kostecki wrote: Hello, as the Soekris net6501 does not have any ACPI implementation, HPET won't get enabled. This patch enables HPET on such platforms. [0.430149] pci :00:01.0: Force enabled HPET at 0xfed0 [0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer Original patch by Peter Neubauer, slightly modified by me. - http://www.mail-archive.com/soekris- t...@lists.soekris.com/msg06462.html Cheers Conrad Are you sure this won't break any other E6xx platforms? Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is special, as Soekris does not implement ACPI. I don't know, how other E6xx systems do work. I guess, there will have ACPI. There seem not to be many out there. This patch is now running for about six months without any problems for me. I was also searching for some other systems. I found here only one manual. There are at least the same vendor/device id shown, as used also in Soekris. - http://www.ekf.de/p/pc2/pc2_ug.pdf Is there maybe any possibility to check for the specific Soekris model? At least MPTABLE identifies the Soekris: [0.00] MPTABLE: OEM ID: Soekris [0.00] MPTABLE: Product ID: net6501 [0.00] MPTABLE: APIC at: 0xFEE0 Cheers Conrad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 10:06 AM, Conrad Kostecki wrote: Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is special, as Soekris does not implement ACPI. I don't know, how other E6xx systems do work. I guess, there will have ACPI. There seem not to be many out there. This patch is now running for about six months without any problems for me. I was also searching for some other systems. I found here only one manual. There are at least the same vendor/device id shown, as used also in Soekris. - http://www.ekf.de/p/pc2/pc2_ug.pdf Is there maybe any possibility to check for the specific Soekris model? At least MPTABLE identifies the Soekris: [0.00] MPTABLE: OEM ID: Soekris [0.00] MPTABLE: Product ID: net6501 [0.00] MPTABLE: APIC at: 0xFEE0 Does it have DMI? Unfortunately not. # dmidecode 2.12 # No SMBIOS nor DMI entry point found, sorry. Cheers Conrad -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 10:13 AM, Conrad Kostecki wrote: Does it have DMI? Unfortunately not. # dmidecode 2.12 # No SMBIOS nor DMI entry point found, sorry. Sigh. Does anyone have contacts at Soekris who can complain about this stuff? I don't think, that Soekris will fix this. No model of Soekris ever had implemented DMI. Their BIOS (called comBIOS) is completely written by them. Output is via serial port only. At least I know, that the technical engineers at Soekris respond on sa...@soekris.com. Maybe the patch could be extended, that HPET would be only enabled if there is no ACPI present? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
