Re: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 12 Sep 2014, Eric Sesterhenn wrote:
> On 09/09/2014 05:26 PM, H. Peter Anvin wrote:
> > On 09/09/2014 07:54 AM, Thomas Gleixner wrote:
> >>
> >> @hpa: You asked whether this might affect any other e6xx devices.
> >>
> >> According to the atom e6xx-series datasheet the HPET is non optional
> >> and always memory mapped to 0xfed0. I don't see how that would
> >> harm any machine which has the hpet proper advertised via ACPI.
> >>
> >
> > That seems straightforward then.
>
> this means the original patch written by Conrad is going to be applied?
> Is there anything we can do to help regarding this issue?
Yes, it needs some massaging.
> Subject: [PATCH] x86: HPET force enable for Soekris net6501
This change is not soekris specific. It enables the force mechanism
for all e6xx based systems.
> Original patch by Peter Neubauer, slightly modified by me.
> -> http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html
> Signed-off-by: Peter Neubauer
I can't see a SOB from Peter in his post on the soekris list, but he's
clearly the original author. So the patch is missing a From: line
at the top of the mail body.
> 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.
> + */
Again this is not soekris specific. We rather want an explanation WHY
it is safe to do so, e.g. something like:
/*
* According to datasheet e6xx systems have the HPET hardwired to
* 0xfed0
*/
That's the information we need and which avoids questions about the
correctness of the approach. Its clear that ACPI did not populate HPET
if hpet_address is 0.
> +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;
> +}
> +
Remove the new line please.
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
> + e6xx_force_enable_hpet);
Thanks,
tglx
--
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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
hi, On 09/09/2014 05:26 PM, H. Peter Anvin wrote: > On 09/09/2014 07:54 AM, Thomas Gleixner wrote: >> >> @hpa: You asked whether this might affect any other e6xx devices. >> >> According to the atom e6xx-series datasheet the HPET is non optional >> and always memory mapped to 0xfed0. I don't see how that would >> harm any machine which has the hpet proper advertised via ACPI. >> > > That seems straightforward then. this means the original patch written by Conrad is going to be applied? Is there anything we can do to help regarding this issue? > I still wish someone would take a cluebat to Soekris. We keep hearing > crap like this about their firmware over and over and over again. It > isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly > on Open Source components these days... oh, wait. I have send them another message regarding this issue, but so far they did not respond. In the past their responsiveness also varied a lot according to my collegue. Regards, Eric -- LSE Leading Security Experts GmbH, Postfach 100121, 64201 Darmstadt Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB8649 Geschäftsführer: Oliver Michel, Sven Walther smime.p7s Description: S/MIME Cryptographic Signature
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
hi, On 09/09/2014 05:26 PM, H. Peter Anvin wrote: On 09/09/2014 07:54 AM, Thomas Gleixner wrote: @hpa: You asked whether this might affect any other e6xx devices. According to the atom e6xx-series datasheet the HPET is non optional and always memory mapped to 0xfed0. I don't see how that would harm any machine which has the hpet proper advertised via ACPI. That seems straightforward then. this means the original patch written by Conrad is going to be applied? Is there anything we can do to help regarding this issue? I still wish someone would take a cluebat to Soekris. We keep hearing crap like this about their firmware over and over and over again. It isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly on Open Source components these days... oh, wait. I have send them another message regarding this issue, but so far they did not respond. In the past their responsiveness also varied a lot according to my collegue. Regards, Eric -- LSE Leading Security Experts GmbH, Postfach 100121, 64201 Darmstadt Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB8649 Geschäftsführer: Oliver Michel, Sven Walther smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 12 Sep 2014, Eric Sesterhenn wrote:
On 09/09/2014 05:26 PM, H. Peter Anvin wrote:
On 09/09/2014 07:54 AM, Thomas Gleixner wrote:
@hpa: You asked whether this might affect any other e6xx devices.
According to the atom e6xx-series datasheet the HPET is non optional
and always memory mapped to 0xfed0. I don't see how that would
harm any machine which has the hpet proper advertised via ACPI.
That seems straightforward then.
this means the original patch written by Conrad is going to be applied?
Is there anything we can do to help regarding this issue?
Yes, it needs some massaging.
Subject: [PATCH] x86: HPET force enable for Soekris net6501
This change is not soekris specific. It enables the force mechanism
for all e6xx based systems.
Original patch by Peter Neubauer, slightly modified by me.
- http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html
Signed-off-by: Peter Neubauer pneuba...@bluerwhite.org
I can't see a SOB from Peter in his post on the soekris list, but he's
clearly the original author. So the patch is missing a From: line
at the top of the mail body.
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.
+ */
Again this is not soekris specific. We rather want an explanation WHY
it is safe to do so, e.g. something like:
/*
* According to datasheet e6xx systems have the HPET hardwired to
* 0xfed0
*/
That's the information we need and which avoids questions about the
correctness of the approach. Its clear that ACPI did not populate HPET
if hpet_address is 0.
+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;
+}
+
Remove the new line please.
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+ e6xx_force_enable_hpet);
Thanks,
tglx
--
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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Tue, 9 Sep 2014, H. Peter Anvin wrote: > On 09/09/2014 07:54 AM, Thomas Gleixner wrote: > > > > @hpa: You asked whether this might affect any other e6xx devices. > > > > According to the atom e6xx-series datasheet the HPET is non optional > > and always memory mapped to 0xfed0. I don't see how that would > > harm any machine which has the hpet proper advertised via ACPI. > > > > That seems straightforward then. > > I still wish someone would take a cluebat to Soekris. We keep hearing > crap like this about their firmware over and over and over again. It > isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly > on Open Source components these days... oh, wait. You can, but I have a non soekris e6xx platform with a BLDK based BIOS which lacks ACPI and some other features -- 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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 09/09/2014 07:54 AM, Thomas Gleixner wrote: > > @hpa: You asked whether this might affect any other e6xx devices. > > According to the atom e6xx-series datasheet the HPET is non optional > and always memory mapped to 0xfed0. I don't see how that would > harm any machine which has the hpet proper advertised via ACPI. > That seems straightforward then. I still wish someone would take a cluebat to Soekris. We keep hearing crap like this about their firmware over and over and over again. It isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly on Open Source components these days... oh, wait. -hpa -- 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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Tue, 9 Sep 2014, Eric Sesterhenn wrote:
> On 02/14/2014 07:28 PM, Conrad Kostecki wrote:
> This patch enables a quirk for the Soekris net6501 HPET if
> pciquirks=soekris_e6xx" is supplied at the kernel commandline,
> Without these patches the clocksource defaults to jiffies, which
> is unstable.
>
> Signed-off-by: Eric Sesterhenn
>
> diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
> index ff898bb..7c3faf5 100644
> --- a/arch/x86/kernel/quirks.c
> +++ b/arch/x86/kernel/quirks.c
> @@ -6,6 +6,25 @@
>
> #include
>
> +static int pciquirk_soekris;
> +
> +static int __init parse_pciquirks(char *str)
> +{
> +
> + while (str) {
> + char *next = strchr(str, ',');
> +
> + if (next)
> + *next++ = 0;
> + if (!strncmp("soekris_e6xx", str, 12))
> + pciquirk_soekris = 1;
> + str = next;
> + }
> +return 1;
> +}
> +__setup("pciquirks=", parse_pciquirks);
Eew. No, we really can do without random new quirk interfaces.
> #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
>
> static void quirk_intel_irqbalance(struct pci_dev *dev)
> @@ -498,6 +517,28 @@ 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;
> +
> + if (pciquirk_soekris != 1)
> + return;
Thinking more about it, this is really not necessary.
@hpa: You asked whether this might affect any other e6xx devices.
According to the atom e6xx-series datasheet the HPET is non optional
and always memory mapped to 0xfed0. I don't see how that would
harm any machine which has the hpet proper advertised via ACPI.
Thanks,
tglx
> +
> + 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);
--
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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
Hello Conrad,
On 02/14/2014 07:28 PM, Conrad Kostecki wrote:
>> 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?
we are facing the same issue with these systems. Maybe the following patch,
which is based on yours, would be acceptable for mainline.
Best regards,
Eric Sesterhenn
This patch enables a quirk for the Soekris net6501 HPET if
pciquirks=soekris_e6xx" is supplied at the kernel commandline,
Without these patches the clocksource defaults to jiffies, which
is unstable.
Signed-off-by: Eric Sesterhenn
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..7c3faf5 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -6,6 +6,25 @@
#include
+static int pciquirk_soekris;
+
+static int __init parse_pciquirks(char *str)
+{
+
+ while (str) {
+ char *next = strchr(str, ',');
+
+ if (next)
+ *next++ = 0;
+ if (!strncmp("soekris_e6xx", str, 12))
+ pciquirk_soekris = 1;
+ str = next;
+ }
+return 1;
+}
+__setup("pciquirks=", parse_pciquirks);
+
+
#if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
static void quirk_intel_irqbalance(struct pci_dev *dev)
@@ -498,6 +517,28 @@ 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;
+
+ if (pciquirk_soekris != 1)
+ 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
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb7..aa0d390 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2860,6 +2860,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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
Hello Conrad,
On 02/14/2014 07:28 PM, Conrad Kostecki wrote:
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?
we are facing the same issue with these systems. Maybe the following patch,
which is based on yours, would be acceptable for mainline.
Best regards,
Eric Sesterhenn
This patch enables a quirk for the Soekris net6501 HPET if
pciquirks=soekris_e6xx is supplied at the kernel commandline,
Without these patches the clocksource defaults to jiffies, which
is unstable.
Signed-off-by: Eric Sesterhenn eric.sesterh...@lsexperts.de
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..7c3faf5 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -6,6 +6,25 @@
#include asm/hpet.h
+static int pciquirk_soekris;
+
+static int __init parse_pciquirks(char *str)
+{
+
+ while (str) {
+ char *next = strchr(str, ',');
+
+ if (next)
+ *next++ = 0;
+ if (!strncmp(soekris_e6xx, str, 12))
+ pciquirk_soekris = 1;
+ str = next;
+ }
+return 1;
+}
+__setup(pciquirks=, parse_pciquirks);
+
+
#if defined(CONFIG_X86_IO_APIC) defined(CONFIG_SMP) defined(CONFIG_PCI)
static void quirk_intel_irqbalance(struct pci_dev *dev)
@@ -498,6 +517,28 @@ 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;
+
+ if (pciquirk_soekris != 1)
+ 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
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb7..aa0d390 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2860,6 +2860,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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Tue, 9 Sep 2014, Eric Sesterhenn wrote:
On 02/14/2014 07:28 PM, Conrad Kostecki wrote:
This patch enables a quirk for the Soekris net6501 HPET if
pciquirks=soekris_e6xx is supplied at the kernel commandline,
Without these patches the clocksource defaults to jiffies, which
is unstable.
Signed-off-by: Eric Sesterhenn eric.sesterh...@lsexperts.de
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..7c3faf5 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -6,6 +6,25 @@
#include asm/hpet.h
+static int pciquirk_soekris;
+
+static int __init parse_pciquirks(char *str)
+{
+
+ while (str) {
+ char *next = strchr(str, ',');
+
+ if (next)
+ *next++ = 0;
+ if (!strncmp(soekris_e6xx, str, 12))
+ pciquirk_soekris = 1;
+ str = next;
+ }
+return 1;
+}
+__setup(pciquirks=, parse_pciquirks);
Eew. No, we really can do without random new quirk interfaces.
#if defined(CONFIG_X86_IO_APIC) defined(CONFIG_SMP) defined(CONFIG_PCI)
static void quirk_intel_irqbalance(struct pci_dev *dev)
@@ -498,6 +517,28 @@ 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;
+
+ if (pciquirk_soekris != 1)
+ return;
Thinking more about it, this is really not necessary.
@hpa: You asked whether this might affect any other e6xx devices.
According to the atom e6xx-series datasheet the HPET is non optional
and always memory mapped to 0xfed0. I don't see how that would
harm any machine which has the hpet proper advertised via ACPI.
Thanks,
tglx
+
+ 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);
--
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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 09/09/2014 07:54 AM, Thomas Gleixner wrote: @hpa: You asked whether this might affect any other e6xx devices. According to the atom e6xx-series datasheet the HPET is non optional and always memory mapped to 0xfed0. I don't see how that would harm any machine which has the hpet proper advertised via ACPI. That seems straightforward then. I still wish someone would take a cluebat to Soekris. We keep hearing crap like this about their firmware over and over and over again. It isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly on Open Source components these days... oh, wait. -hpa -- 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/
Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Tue, 9 Sep 2014, H. Peter Anvin wrote: On 09/09/2014 07:54 AM, Thomas Gleixner wrote: @hpa: You asked whether this might affect any other e6xx devices. According to the atom e6xx-series datasheet the HPET is non optional and always memory mapped to 0xfed0. I don't see how that would harm any machine which has the hpet proper advertised via ACPI. That seems straightforward then. I still wish someone would take a cluebat to Soekris. We keep hearing crap like this about their firmware over and over and over again. It isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly on Open Source components these days... oh, wait. You can, but I have a non soekris e6xx platform with a BLDK based BIOS which lacks ACPI and some other features -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/17/2014 11:25 AM, Thomas Renninger wrote: > On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote: >> On 02/17/2014 10:23 AM, Thomas Renninger wrote: >>> Easiest I can think of instead of trying to modify RSDP or similar, is >>> to still pass the tables via unzipped, glued cpio which the kernel >>> can access early. The same way it is done for current ACPI table >>> overriding >>> and early microcode passing. >> >> We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are >> are pointers to the actual tables. Rather than hacking around it we >> should probably just fix the fundamental problem. > > That is what I described. > If something similar what I wrote gets implemented, you can simply > add ACPI tables to initrd as described here: > Documentation/acpi/initrd_table_override.txt > and if BIOS already provides them they get overridden, otherwise > they get added. > Right, that was the idea. Thomas Gleixner said it didn't work. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote: > On 02/17/2014 10:23 AM, Thomas Renninger wrote: > > Easiest I can think of instead of trying to modify RSDP or similar, is > > to still pass the tables via unzipped, glued cpio which the kernel > > can access early. The same way it is done for current ACPI table > > overriding > > and early microcode passing. > > We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are > are pointers to the actual tables. Rather than hacking around it we > should probably just fix the fundamental problem. That is what I described. If something similar what I wrote gets implemented, you can simply add ACPI tables to initrd as described here: Documentation/acpi/initrd_table_override.txt and if BIOS already provides them they get overridden, otherwise they get added. Thomas -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/17/2014 10:23 AM, Thomas Renninger wrote: > > Easiest I can think of instead of trying to modify RSDP or similar, is > to still pass the tables via unzipped, glued cpio which the kernel > can access early. The same way it is done for current ACPI table overriding > and early microcode passing. > We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are are pointers to the actual tables. Rather than hacking around it we should probably just fix the fundamental problem. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Monday, February 17, 2014 09:19:03 AM H. Peter Anvin wrote: > What I gather is that they want to add tables where there are none, and that > the ACPI code doesn't play along because there is no RSDP nor any > RSDT/XSDT. Yep, this does currently not work. Easiest I can think of instead of trying to modify RSDP or similar, is to still pass the tables via unzipped, glued cpio which the kernel can access early. The same way it is done for current ACPI table overriding and early microcode passing. Also find them via: file = find_cpio_data(cpio_path, data, size, ); (compare with drivers/acpi/osl.c) and add them to (compare with drivers/acpi/acpica/acglobal.h): /* * acpi_gbl_root_table_list is the master list of ACPI tables that were * found in the RSDT/XSDT. */ ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list; But right now, this is acpica internal only. Most elegant way should be that ACPICA people would add another OS callback: acpi_status acpi_os_physical_table_add(acpi_physical_address *address, u32 *table_length)); which is called right after acpi_os_physical_table_override. Implementation of it should be in osl.c again where it can easily be tracked whether a table has been replaced already and need not to be added, for example something like: __initdata struct cpio_data overridden_tables[ACPI_OVERRIDE_TABLES]; ACPICA part should not be hard as well. It's some time ago, but it may be a simple call to: /* Add the table to the global root table list */ status = acpi_tb_store_table(table_desc->address, table_desc->pointer, table_desc->length, table_desc->flags, table_index); if acpi_os_physical_table_add() has returned a valid address/length. This would then add the table to acpica internal: /* * acpi_gbl_root_table_list is the master list of ACPI tables that were * found in the RSDT/XSDT. */ ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list; and later all the tables in there get loaded and set up as if they were passed from BIOS. Thomas > On February 17, 2014 8:28:05 AM PST, Thomas Renninger wrote: > >On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote: > >> On Fri, 14 Feb 2014, H. Peter Anvin wrote: > >> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote: > >> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote: > >> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote: > >> > >>> I'm fine with ACPI tables if we can provide simple means for > > > >embedded > > > >> > >>> users to load one via grub or just attach it to the kernel > > > >image. > > > >> > >> That already exists, see > > > >Documentation/acpi/initrd_table_override.txt. > > > >> > > That requires, that you have already ACPI tables. > >> > > > >> > > ACPI_SIG_RSDP cannot be overridden and that's the base table you > > > >need > > > >> > > to get ACPI going in the first place. So we need support for that > > > >and > > > >> > > probably for storing the tables at some non canonical place. > >> > > >> > Well, the RSDP and RSDT/XSDT are nothing but pointers to other > > > >tables, > > > >> > so if explicitly overridden I'm not sure if one actually would need > >> > them. That doesn't mean our current code will work without them, > > > >though. > > > >> I tried once to overload all of the tables, but failed miserably in > >> the ACPI dungeon. RSDP was the major pain point IIRC. > > > >What exactly do you try to achieve? > >I cannot imagine a use-case where RSDP and XSDT overriding would help > >you. > > > >Have you tried the current mechanism to override tables? > >What is missing and for what do you need it for? > > > >I need more context, maybe I can help then. > > > > Thomas -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
What I gather is that they want to add tables where there are none, and that the ACPI code doesn't play along because there is no RSDP nor any RSDT/XSDT. On February 17, 2014 8:28:05 AM PST, Thomas Renninger wrote: >On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote: >> On Fri, 14 Feb 2014, H. Peter Anvin wrote: >> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote: >> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote: >> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote: >> > >>> I'm fine with ACPI tables if we can provide simple means for >embedded >> > >>> users to load one via grub or just attach it to the kernel >image. >> > >> >> > >> That already exists, see >Documentation/acpi/initrd_table_override.txt. >> > > >> > > That requires, that you have already ACPI tables. >> > > >> > > ACPI_SIG_RSDP cannot be overridden and that's the base table you >need >> > > to get ACPI going in the first place. So we need support for that >and >> > > probably for storing the tables at some non canonical place. >> > >> > Well, the RSDP and RSDT/XSDT are nothing but pointers to other >tables, >> > so if explicitly overridden I'm not sure if one actually would need >> > them. That doesn't mean our current code will work without them, >though. >> >> I tried once to overload all of the tables, but failed miserably in >> the ACPI dungeon. RSDP was the major pain point IIRC. > >What exactly do you try to achieve? >I cannot imagine a use-case where RSDP and XSDT overriding would help >you. > >Have you tried the current mechanism to override tables? >What is missing and for what do you need it for? > >I need more context, maybe I can help then. > > Thomas -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote: > On Fri, 14 Feb 2014, H. Peter Anvin wrote: > > On 02/14/2014 11:59 AM, Thomas Gleixner wrote: > > > On Fri, 14 Feb 2014, H. Peter Anvin wrote: > > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote: > > >>> I'm fine with ACPI tables if we can provide simple means for embedded > > >>> users to load one via grub or just attach it to the kernel image. > > >> > > >> That already exists, see Documentation/acpi/initrd_table_override.txt. > > > > > > That requires, that you have already ACPI tables. > > > > > > ACPI_SIG_RSDP cannot be overridden and that's the base table you need > > > to get ACPI going in the first place. So we need support for that and > > > probably for storing the tables at some non canonical place. > > > > Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, > > so if explicitly overridden I'm not sure if one actually would need > > them. That doesn't mean our current code will work without them, though. > > I tried once to overload all of the tables, but failed miserably in > the ACPI dungeon. RSDP was the major pain point IIRC. What exactly do you try to achieve? I cannot imagine a use-case where RSDP and XSDT overriding would help you. Have you tried the current mechanism to override tables? What is missing and for what do you need it for? I need more context, maybe I can help then. Thomas -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:59 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:15 AM, Thomas Gleixner wrote: I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. What exactly do you try to achieve? I cannot imagine a use-case where RSDP and XSDT overriding would help you. Have you tried the current mechanism to override tables? What is missing and for what do you need it for? I need more context, maybe I can help then. Thomas -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
What I gather is that they want to add tables where there are none, and that the ACPI code doesn't play along because there is no RSDP nor any RSDT/XSDT. On February 17, 2014 8:28:05 AM PST, Thomas Renninger tr...@suse.de wrote: On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:59 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:15 AM, Thomas Gleixner wrote: I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. What exactly do you try to achieve? I cannot imagine a use-case where RSDP and XSDT overriding would help you. Have you tried the current mechanism to override tables? What is missing and for what do you need it for? I need more context, maybe I can help then. Thomas -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Monday, February 17, 2014 09:19:03 AM H. Peter Anvin wrote: What I gather is that they want to add tables where there are none, and that the ACPI code doesn't play along because there is no RSDP nor any RSDT/XSDT. Yep, this does currently not work. Easiest I can think of instead of trying to modify RSDP or similar, is to still pass the tables via unzipped, glued cpio which the kernel can access early. The same way it is done for current ACPI table overriding and early microcode passing. Also find them via: file = find_cpio_data(cpio_path, data, size, offset); (compare with drivers/acpi/osl.c) and add them to (compare with drivers/acpi/acpica/acglobal.h): /* * acpi_gbl_root_table_list is the master list of ACPI tables that were * found in the RSDT/XSDT. */ ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list; But right now, this is acpica internal only. Most elegant way should be that ACPICA people would add another OS callback: acpi_status acpi_os_physical_table_add(acpi_physical_address *address, u32 *table_length)); which is called right after acpi_os_physical_table_override. Implementation of it should be in osl.c again where it can easily be tracked whether a table has been replaced already and need not to be added, for example something like: __initdata struct cpio_data overridden_tables[ACPI_OVERRIDE_TABLES]; ACPICA part should not be hard as well. It's some time ago, but it may be a simple call to: /* Add the table to the global root table list */ status = acpi_tb_store_table(table_desc-address, table_desc-pointer, table_desc-length, table_desc-flags, table_index); if acpi_os_physical_table_add() has returned a valid address/length. This would then add the table to acpica internal: /* * acpi_gbl_root_table_list is the master list of ACPI tables that were * found in the RSDT/XSDT. */ ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list; and later all the tables in there get loaded and set up as if they were passed from BIOS. Thomas On February 17, 2014 8:28:05 AM PST, Thomas Renninger tr...@suse.de wrote: On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:59 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:15 AM, Thomas Gleixner wrote: I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. What exactly do you try to achieve? I cannot imagine a use-case where RSDP and XSDT overriding would help you. Have you tried the current mechanism to override tables? What is missing and for what do you need it for? I need more context, maybe I can help then. Thomas -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/17/2014 10:23 AM, Thomas Renninger wrote: Easiest I can think of instead of trying to modify RSDP or similar, is to still pass the tables via unzipped, glued cpio which the kernel can access early. The same way it is done for current ACPI table overriding and early microcode passing. We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are are pointers to the actual tables. Rather than hacking around it we should probably just fix the fundamental problem. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote: On 02/17/2014 10:23 AM, Thomas Renninger wrote: Easiest I can think of instead of trying to modify RSDP or similar, is to still pass the tables via unzipped, glued cpio which the kernel can access early. The same way it is done for current ACPI table overriding and early microcode passing. We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are are pointers to the actual tables. Rather than hacking around it we should probably just fix the fundamental problem. That is what I described. If something similar what I wrote gets implemented, you can simply add ACPI tables to initrd as described here: Documentation/acpi/initrd_table_override.txt and if BIOS already provides them they get overridden, otherwise they get added. Thomas -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/17/2014 11:25 AM, Thomas Renninger wrote: On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote: On 02/17/2014 10:23 AM, Thomas Renninger wrote: Easiest I can think of instead of trying to modify RSDP or similar, is to still pass the tables via unzipped, glued cpio which the kernel can access early. The same way it is done for current ACPI table overriding and early microcode passing. We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are are pointers to the actual tables. Rather than hacking around it we should probably just fix the fundamental problem. That is what I described. If something similar what I wrote gets implemented, you can simply add ACPI tables to initrd as described here: Documentation/acpi/initrd_table_override.txt and if BIOS already provides them they get overridden, otherwise they get added. Right, that was the idea. Thomas Gleixner said it didn't work. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 01:47 PM, Thomas Gleixner wrote: > > I'm aware of that and I tried to hack around it but failed miserably > due to lack of masochism. It was simpler to abuse the DT stuff to get > things done. :) > Right... we should fix that, though. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: > On 02/14/2014 01:16 PM, Thomas Gleixner wrote: > >> > >> Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, > >> so if explicitly overridden I'm not sure if one actually would need > >> them. That doesn't mean our current code will work without them, though. > > > > I tried once to overload all of the tables, but failed miserably in > > the ACPI dungeon. RSDP was the major pain point IIRC. > > > > I suspect we need to handle the RSDP and RSDT/XSDT specially, since, > again, they are really just pointers to where to find the other tables. > They are part of the discovery, not the data. I'm aware of that and I tried to hack around it but failed miserably due to lack of masochism. It was simpler to abuse the DT stuff to get things done. :) Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 01:16 PM, Thomas Gleixner wrote: >> >> Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, >> so if explicitly overridden I'm not sure if one actually would need >> them. That doesn't mean our current code will work without them, though. > > I tried once to overload all of the tables, but failed miserably in > the ACPI dungeon. RSDP was the major pain point IIRC. > I suspect we need to handle the RSDP and RSDT/XSDT specially, since, again, they are really just pointers to where to find the other tables. They are part of the discovery, not the data. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: > On 02/14/2014 11:59 AM, Thomas Gleixner wrote: > > On Fri, 14 Feb 2014, H. Peter Anvin wrote: > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote: > >>> I'm fine with ACPI tables if we can provide simple means for embedded > >>> users to load one via grub or just attach it to the kernel image. > >> > >> That already exists, see Documentation/acpi/initrd_table_override.txt. > > > > That requires, that you have already ACPI tables. > > > > ACPI_SIG_RSDP cannot be overridden and that's the base table you need > > to get ACPI going in the first place. So we need support for that and > > probably for storing the tables at some non canonical place. > > > > Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, > so if explicitly overridden I'm not sure if one actually would need > them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 11:59 AM, Thomas Gleixner wrote: > On Fri, 14 Feb 2014, H. Peter Anvin wrote: >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote: >>> I'm fine with ACPI tables if we can provide simple means for embedded >>> users to load one via grub or just attach it to the kernel image. >> >> That already exists, see Documentation/acpi/initrd_table_override.txt. > > That requires, that you have already ACPI tables. > > ACPI_SIG_RSDP cannot be overridden and that's the base table you need > to get ACPI going in the first place. So we need support for that and > probably for storing the tables at some non canonical place. > Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. Thomas, Rafael, do you have any insights? -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: > On 02/14/2014 11:15 AM, Thomas Gleixner wrote: > > I'm fine with ACPI tables if we can provide simple means for embedded > > users to load one via grub or just attach it to the kernel image. > > That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 11:15 AM, Thomas Gleixner wrote: > > > On Fri, 14 Feb 2014, H. Peter Anvin wrote: > >> We could also just add an ACPI table... same concept. Still need to find it. > > I'm fine with ACPI tables if we can provide simple means for embedded > users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. > Sure, the user needs to know how to prepare one, but for similar > platforms, e.g. e6xx based stuff the tables would look all the > same. We probably could just recycle those from the BLDK. Yes, that might be a good way to do it. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: > We could also just add an ACPI table... same concept. Still need to find it. I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. Sure, the user needs to know how to prepare one, but for similar platforms, e.g. e6xx based stuff the tables would look all the same. We probably could just recycle those from the BLDK. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
We could also just add an ACPI table... same concept. Still need to find it. On February 14, 2014 10:38:24 AM PST, Thomas Gleixner wrote: >On Fri, 14 Feb 2014, H. Peter Anvin wrote: >> On 02/14/2014 10:21 AM, Thomas Gleixner wrote: >> > I wish we could just use devicetree for such cases and fix the crud >> > ourself. >> > >> >> We'd have to identify the platform, which is the main problem. Right >> now we support quirking for DMI or PCI, but I don't think we do for >MPTABLE. > >My point is that device tree support for some basic stuff like >hpet/ioapic and such would allow people like Conrad to avoid the >stupid hackery of quirks. > >Building your own DT requires to read a datasheet as does hacking a >quirk, but its definitely simpler. And we can collect the DTs for >known boards either in the kernel or in some external repository. > >People who are dealing with embedded stuff are not those who are >frightened by datasheets and building a custom kernel with some extra >blob. > >I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major >PITA. I have such a board as well and it simply sucks. > >Now you can't hack an ioapic quirk because that's way to complex, but >we have proven with the ce4100 that it is reasonably simple to get >that stuff working nicely when you can read a datasheet. If we could >generalize that for a few crucial devices that would help a lot. > >When I asked the board vendor why there are no acpi tables in the >device, I got the answer, that this is an embedded board and the >"BIOS" built with BLDK does not support that. We all know that's not >true, but how does that help? > >The people who brought up the initial target OS (WinCE) on that board >worked around the lack of ACPI by hacking HPET support into the CE >preloader and switched all device drivers to use MSI because CE failed >to handle the PIC properly. That avoided that they needed to hack the >ioapic into submission as well. > >That's the sad reality. And we have to cope with these boards whether >we like it or not. > >Thanks, > > tglx -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: > On 02/14/2014 10:21 AM, Thomas Gleixner wrote: > > I wish we could just use devicetree for such cases and fix the crud > > ourself. > > > > We'd have to identify the platform, which is the main problem. Right > now we support quirking for DMI or PCI, but I don't think we do for MPTABLE. My point is that device tree support for some basic stuff like hpet/ioapic and such would allow people like Conrad to avoid the stupid hackery of quirks. Building your own DT requires to read a datasheet as does hacking a quirk, but its definitely simpler. And we can collect the DTs for known boards either in the kernel or in some external repository. People who are dealing with embedded stuff are not those who are frightened by datasheets and building a custom kernel with some extra blob. I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major PITA. I have such a board as well and it simply sucks. Now you can't hack an ioapic quirk because that's way to complex, but we have proven with the ce4100 that it is reasonably simple to get that stuff working nicely when you can read a datasheet. If we could generalize that for a few crucial devices that would help a lot. When I asked the board vendor why there are no acpi tables in the device, I got the answer, that this is an embedded board and the "BIOS" built with BLDK does not support that. We all know that's not true, but how does that help? The people who brought up the initial target OS (WinCE) on that board worked around the lack of ACPI by hacking HPET support into the CE preloader and switched all device drivers to use MSI because CE failed to handle the PIC properly. That avoided that they needed to hack the ioapic into submission as well. That's the sad reality. And we have to cope with these boards whether we like it or not. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 10:21 AM, Thomas Gleixner wrote: > On Fri, 14 Feb 2014, H. Peter Anvin wrote: > >> 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? > > Well, lots of embedded stuff comes with a crippled BIOS. And there is > often no way to get any BIOS fixes from the vendor through the > subvendors and supplier chain. > > I wish we could just use devicetree for such cases and fix the crud > ourself. > We'd have to identify the platform, which is the main problem. Right now we support quirking for DMI or PCI, but I don't think we do for MPTABLE. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: > 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? Well, lots of embedded stuff comes with a crippled BIOS. And there is often no way to get any BIOS fixes from the vendor through the subvendors and supplier chain. I wish we could just use devicetree for such cases and fix the crud ourself. Thanks, tglx -- 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/
Re: 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? -hpa -- 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/
Re: 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? -hpa -- 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/
Re: [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-tech@lists.soekris.com/msg06462.html > > Cheers > Conrad Are you sure this won't break any other E6xx platforms? -hpa -- 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/
Re: [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-tech@lists.soekris.com/msg06462.html Cheers Conrad Are you sure this won't break any other E6xx platforms? -hpa -- 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/
Re: 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? -hpa -- 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/
Re: 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? -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: 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? Well, lots of embedded stuff comes with a crippled BIOS. And there is often no way to get any BIOS fixes from the vendor through the subvendors and supplier chain. I wish we could just use devicetree for such cases and fix the crud ourself. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 10:21 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: 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? Well, lots of embedded stuff comes with a crippled BIOS. And there is often no way to get any BIOS fixes from the vendor through the subvendors and supplier chain. I wish we could just use devicetree for such cases and fix the crud ourself. We'd have to identify the platform, which is the main problem. Right now we support quirking for DMI or PCI, but I don't think we do for MPTABLE. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 10:21 AM, Thomas Gleixner wrote: I wish we could just use devicetree for such cases and fix the crud ourself. We'd have to identify the platform, which is the main problem. Right now we support quirking for DMI or PCI, but I don't think we do for MPTABLE. My point is that device tree support for some basic stuff like hpet/ioapic and such would allow people like Conrad to avoid the stupid hackery of quirks. Building your own DT requires to read a datasheet as does hacking a quirk, but its definitely simpler. And we can collect the DTs for known boards either in the kernel or in some external repository. People who are dealing with embedded stuff are not those who are frightened by datasheets and building a custom kernel with some extra blob. I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major PITA. I have such a board as well and it simply sucks. Now you can't hack an ioapic quirk because that's way to complex, but we have proven with the ce4100 that it is reasonably simple to get that stuff working nicely when you can read a datasheet. If we could generalize that for a few crucial devices that would help a lot. When I asked the board vendor why there are no acpi tables in the device, I got the answer, that this is an embedded board and the BIOS built with BLDK does not support that. We all know that's not true, but how does that help? The people who brought up the initial target OS (WinCE) on that board worked around the lack of ACPI by hacking HPET support into the CE preloader and switched all device drivers to use MSI because CE failed to handle the PIC properly. That avoided that they needed to hack the ioapic into submission as well. That's the sad reality. And we have to cope with these boards whether we like it or not. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
We could also just add an ACPI table... same concept. Still need to find it. On February 14, 2014 10:38:24 AM PST, Thomas Gleixner t...@linutronix.de wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 10:21 AM, Thomas Gleixner wrote: I wish we could just use devicetree for such cases and fix the crud ourself. We'd have to identify the platform, which is the main problem. Right now we support quirking for DMI or PCI, but I don't think we do for MPTABLE. My point is that device tree support for some basic stuff like hpet/ioapic and such would allow people like Conrad to avoid the stupid hackery of quirks. Building your own DT requires to read a datasheet as does hacking a quirk, but its definitely simpler. And we can collect the DTs for known boards either in the kernel or in some external repository. People who are dealing with embedded stuff are not those who are frightened by datasheets and building a custom kernel with some extra blob. I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major PITA. I have such a board as well and it simply sucks. Now you can't hack an ioapic quirk because that's way to complex, but we have proven with the ce4100 that it is reasonably simple to get that stuff working nicely when you can read a datasheet. If we could generalize that for a few crucial devices that would help a lot. When I asked the board vendor why there are no acpi tables in the device, I got the answer, that this is an embedded board and the BIOS built with BLDK does not support that. We all know that's not true, but how does that help? The people who brought up the initial target OS (WinCE) on that board worked around the lack of ACPI by hacking HPET support into the CE preloader and switched all device drivers to use MSI because CE failed to handle the PIC properly. That avoided that they needed to hack the ioapic into submission as well. That's the sad reality. And we have to cope with these boards whether we like it or not. Thanks, tglx -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: We could also just add an ACPI table... same concept. Still need to find it. I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. Sure, the user needs to know how to prepare one, but for similar platforms, e.g. e6xx based stuff the tables would look all the same. We probably could just recycle those from the BLDK. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 11:15 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: We could also just add an ACPI table... same concept. Still need to find it. I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. Sure, the user needs to know how to prepare one, but for similar platforms, e.g. e6xx based stuff the tables would look all the same. We probably could just recycle those from the BLDK. Yes, that might be a good way to do it. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:15 AM, Thomas Gleixner wrote: I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 11:59 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:15 AM, Thomas Gleixner wrote: I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. Thomas, Rafael, do you have any insights? -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:59 AM, Thomas Gleixner wrote: On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 11:15 AM, Thomas Gleixner wrote: I'm fine with ACPI tables if we can provide simple means for embedded users to load one via grub or just attach it to the kernel image. That already exists, see Documentation/acpi/initrd_table_override.txt. That requires, that you have already ACPI tables. ACPI_SIG_RSDP cannot be overridden and that's the base table you need to get ACPI going in the first place. So we need support for that and probably for storing the tables at some non canonical place. Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 01:16 PM, Thomas Gleixner wrote: Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. I suspect we need to handle the RSDP and RSDT/XSDT specially, since, again, they are really just pointers to where to find the other tables. They are part of the discovery, not the data. -hpa -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On Fri, 14 Feb 2014, H. Peter Anvin wrote: On 02/14/2014 01:16 PM, Thomas Gleixner wrote: Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables, so if explicitly overridden I'm not sure if one actually would need them. That doesn't mean our current code will work without them, though. I tried once to overload all of the tables, but failed miserably in the ACPI dungeon. RSDP was the major pain point IIRC. I suspect we need to handle the RSDP and RSDT/XSDT specially, since, again, they are really just pointers to where to find the other tables. They are part of the discovery, not the data. I'm aware of that and I tried to hack around it but failed miserably due to lack of masochism. It was simpler to abuse the DT stuff to get things done. :) Thanks, tglx -- 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/
Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501
On 02/14/2014 01:47 PM, Thomas Gleixner wrote: I'm aware of that and I tried to hack around it but failed miserably due to lack of masochism. It was simpler to abuse the DT stuff to get things done. :) Right... we should fix that, though. -hpa -- 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/
