Skip to contentSkip to conversation

x86 CPU detection for RDC

PATCH Superseded Mark Kelly 5 participants 18 messages Aug 16, 2009 – Aug 18, 2009

Subsystems (2)
lore
Share & tools
lore

Mark Kelly

author
#0 lore raw

PATCH 1/1 x86 CPU detection for RDC

Quoted 2 lines

From about 2.6.29, CPU detection appears to have changed such that a

patch is required for RDC x86-compatible CPUs (possibly other undetected x86 CPUs as well). A work-around was to add a couple of null checks to arch/x86/kernel/cpu/common.c, e.g.:

if (this_cpu && this_cpu->c_identify)

             ~~~~~~~~~~~~~~~~~~~~~~~
    this_cpu->c_identify(c);

However the patch below attempts to do this detection properly, and also detect all variants of RDC CPUs. I have also added some documentation for this platform.

See also:
http://sites.google.com/site/bifferboard/Home/s3282-kernel-issues

kind regards,
Mark.

Documentation/x86/rdc.txt new file +69 -0
new file mode 100644
index 0000000..9c6baaa
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of 
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility 
+coupled with very low power consumption[1] and low cost make them ideal 
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically 
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com   
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look 
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to [email protected].
+
+
+Refs
+====
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
[email protected] 2009
+
arch/x86/include/asm/processor.h +2 -1
index c2cceae..6f9f853 100644
@@ -121,7 +121,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
arch/x86/kernel/cpu/Makefile +1 -0
index 4e242f9..9906064 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_X86_MCE)	+= mcheck/
 obj-$(CONFIG_MTRR)	+= mtrr/
arch/x86/kernel/cpu/rdc.c new file +20 -0
new file mode 100644
index 0000000..5a6aea7
@@ -0,0 +1,72 @@
+/*
+   See Documentation/x86/rdc.txt
+
+   [email protected]
+*/
+
+#include <linux/pci.h>
+#include <asm/pci-direct.h>
+#include "cpu.h"
+
+
+static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
+{
+	u16 vendor, device;
+	
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present. */
+	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
+	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
+
+	/* We could go on and check other devices, e.g. r6040 NIC, but that's probably

overkill */
+ if (vendor == PCI_VENDOR_ID_RDC && device == PCI_DEVICE_ID_RDC_R6020)
+ {
+ u32 customer_id;
+
+ strcpy(c->x86_vendor_id, "RDC");
+ c->x86_vendor = X86_VENDOR_RDC;
+
+ customer_id = read_pci_config(0, 0, 0, 0x90);
+
+ switch (customer_id)
+ {
+ // id names are from RDC.
+ case 0x00321000 :
+ strcpy(c->x86_model_id, "R3210/R3211");
+ break;
+ case 0x00321001 :
+ strcpy(c->x86_model_id, "AMITRISC20000/20010");
+ break;
+ case 0x00321002 :
+ strcpy(c->x86_model_id, "R3210X/Edimax");
+ break;
+ case 0x00321003 :
+ strcpy(c->x86_model_id, "R3210/Kcodes");
+ break;
+ case 0x00321004 : // tested
+ strcpy(c->x86_model_id, "S3282/CodeTek");
+ break;
+ case 0x00321007 :
+ strcpy(c->x86_model_id, "R8610");
+ break;
+ default :
+ printk(KERN_INFO "Unrecognised Customer ID (0x%x) please report to
[email protected]\n", customer_id);
+
+ /* We'll default to the R321x since that's mentioned elsewhere in the
+ kernel sources. */
+ strcpy(c->x86_model_id, "R321x");
+
+ /* blank the vendor_id, so we get a warning that this is unsupported, your
+ system may be unstable etc... Is there a better way? */
+ strcpy(c->x86_vendor_id, "");
+ }
+ }
+}
+
+static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
+ .c_vendor = "RDC",
+ .c_ident = { "RDC" },
+ .c_identify = rdc_identify,
+ .c_x86_vendor = X86_VENDOR_RDC,
+};
+
+cpu_dev_register(rdc_cpu_dev);

#1 lore raw
Quoted 10 lines · Mark Kelly

From about 2.6.29, CPU detection appears to have changed such that
a patch is required for RDC x86-compatible CPUs (possibly other undetected x86 CPUs as well). A work-around was to add a couple of null checks to arch/x86/kernel/cpu/common.c, e.g.:

if (this_cpu && this_cpu->c_identify)

             ~~~~~~~~~~~~~~~~~~~~~~~
    this_cpu->c_identify(c);
Quoted 6 lines

However the patch below attempts to do this detection properly, and also detect all variants of RDC CPUs. I have also added some documentation for this platform.

See also:
http://sites.google.com/site/bifferboard/Home/s3282-kernel-issues

ok, this definitely looks like a step in the right direction. The patch needs a few small fixes:

- the one you sent was line-wrapped. (please see Documentation/email-clients.txt about how to send plain-text patches.)

- there's a few stylistic errors in the patch,
scripts/checkpatch.pl reports:

total: 24 errors, 5 warnings, 0 checks, 157 lines checked

Ingo

author
#2 lore raw
Quoted 3 lines

ok, this definitely looks like a step in the right direction. The patch needs a few small fixes:

Sorry about that - try this one instead:

Documentation/x86/rdc.txt new file +69 -0
new file mode 100644
index 0000000..f9591af
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to [email protected].
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
[email protected] 2009
+
arch/x86/include/asm/processor.h +2 -1
index c2cceae..6f9f853 100644
@@ -121,7 +121,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
arch/x86/kernel/cpu/Makefile +1 -0
index 4e242f9..9906064 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_X86_MCE)	+= mcheck/
 obj-$(CONFIG_MTRR)	+= mtrr/
arch/x86/kernel/cpu/rdc.c new file +74 -0

74 lines not on this page · raw message

#3 lore raw
Quoted 4 lines · Mark Kelly
arch/x86/kernel/cpu/rdc.c new file +4 -0
+static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
+{
+	u16 vendor, device;
+	u32 customer_id;

arch/x86/kernel/cpu/rdc.c line 25

Quoted 10 lines
arch/x86/kernel/cpu/rdc.c new file +10 -0
+
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present. */
+	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
+	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
+
+	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
+		return;  /* not RDC */
+
+	/* NB: We could go on and check other devices, e.g. r6040 NIC, but
+	   that's probably overkill */

please use the customary (multi-line) comment style:

/*
* Comment .....
* ...... goes here.
*/

specified in Documentation/CodingStyle.

Quoted 18 lines
arch/x86/kernel/cpu/rdc.c new file +18 -0
+	strcpy(c->x86_vendor_id, "RDC");
+	c->x86_vendor = X86_VENDOR_RDC;
+
+	customer_id = read_pci_config(0, 0, 0, 0x90);
+
+	switch (customer_id) {
+		/* id names are from RDC */
+	case 0x00321000:
+		strcpy(c->x86_model_id, "R3210/R3211");
+		break;
+	case 0x00321001:
+		strcpy(c->x86_model_id, "AMITRISC20000/20010");
+		break;
+	case 0x00321002:
+		strcpy(c->x86_model_id, "R3210X/Edimax");
+		break;
+	case 0x00321003:
+		strcpy(c->x86_model_id, "R3210/Kcodes");

arch/x86/kernel/cpu/rdc.c line 54

Quoted 10 lines
arch/x86/kernel/cpu/rdc.c new file +10 -0
+		break;
+	case 0x00321004:  /* tested */
+		strcpy(c->x86_model_id, "S3282/CodeTek");
+		break;
+	case 0x00321007:
+		strcpy(c->x86_model_id, "R8610");
+		break;
+	default:
+		printk(KERN_INFO "Unrecognised Customer ID (0x%x) please "
+			"report to [email protected]\n", customer_id);

I'd rather see them reported to [email protected]. Also, please concatenate the string on a single line (and ignore the checkpatch warning in this case, even if the line is over-long).

Also, please use pr_info() here. Plus, put 'RDC' into the printout so that people know that the RDC cpu is unknown. (it's not clear from this printk)

arch/x86/kernel/cpu/rdc.c line 62

Quoted 7 lines
arch/x86/kernel/cpu/rdc.c new file +7 -0
+		/* We'll default to the R321x since that's mentioned
+		   elsewhere in the kernel sources */
+		strcpy(c->x86_model_id, "R321x");
+
+		/* blank the vendor_id, so we get a warning that this
+		   is unsupported, your system may be unstable etc...
+		   Is there a better way? */

(these multi-line comments too need to be fixed.)

arch/x86/kernel/cpu/rdc.c line 63

Quoted 1 line
arch/x86/kernel/cpu/rdc.c new file +1 -0
+		strcpy(c->x86_vendor_id, "");

hm, the default should already be an empty string (i.e. \0) - why does this need to be cleared again?

Ingo

author
#4 lore raw
Quoted 2 lines · Ingo Molnar

hm, the default should already be an empty string (i.e. \0) - why does this need to be cleared again?

I've hopefully made this one a bit clearer by introducing another local instead of doing a set-then-unset.

Here's the next attempt:

Documentation/x86/rdc.txt new file +69 -0
new file mode 100644
index 0000000..f9591af
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to [email protected].
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
[email protected] 2009
+
arch/x86/include/asm/processor.h +2 -1
index c2cceae..6f9f853 100644
@@ -121,7 +121,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
arch/x86/kernel/cpu/Makefile +1 -0
index 4e242f9..9906064 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_X86_MCE)	+= mcheck/
 obj-$(CONFIG_MTRR)	+= mtrr/
arch/x86/kernel/cpu/rdc.c new file +77 -0

77 lines not on this page · raw message

#17 lore raw
In reply to Mark Kelly

arch/x86/kernel/cpu/rdc.c line 18

Quoted 6 lines · Mark Kelly
arch/x86/kernel/cpu/rdc.c new file +6 -0
+{
+	u16 vendor, device;
+	
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present. */
+	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
+	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);

This needs some check first if PCI is even enabled. You can use early_pci_allowed() for this or just add a handler in early quirks that sets a flag you test here.

Also I would suggest to not hard code your own email addresses in printk (which might go away), but use some list like linux-kernel.

-Andi

Signature · 1 line
[email protected] -- Speaking for myself only.
#5 lore raw
In reply to Mark Kelly

arch/x86/kernel/cpu/Makefile obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o · line 28

Quoted 12 lines · Mark Kelly
arch/x86/kernel/cpu/Makefile +1 -0
index 4e242f9..9906064 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_X86_MCE)	+= mcheck/
 obj-$(CONFIG_MTRR)	+= mtrr/

I don't see this defined anywhere. Where it is defined, it needs to depend on or select CONFIG_PCI, since the detection code you're proposing is using unguarded PCI references.

-hpa

#6 lore raw
Quoted 11 lines · H. Peter Anvin
Quoted 10 lines · Mark Kelly
arch/x86/kernel/cpu/Makefile +1 -0
index 4e242f9..9906064 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
Quoted 6 lines

arch/x86/kernel/cpu/Makefile obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o · line 28

Quoted 2 lines
arch/x86/kernel/cpu/Makefile +0 -0
 obj-$(CONFIG_X86_MCE)	+= mcheck/
 obj-$(CONFIG_MTRR)	+= mtrr/

I don't see this defined anywhere. Where it is defined, it needs to depend on or select CONFIG_PCI, since the detection code you're proposing is using unguarded PCI references.

X86_RDC321X already exists in arch/x86/Kconfig. It should probably grow a 'depends on PCI' rline or so.

Ingo

#7 lore raw
Quoted 4 lines · Ingo Molnar

X86_RDC321X already exists in arch/x86/Kconfig. It should probably grow a 'depends on PCI' rline or so.

Sounds like it.

-hpa

#8 lore raw
Quoted 7 lines · H. Peter Anvin
Quoted 4 lines · Ingo Molnar

X86_RDC321X already exists in arch/x86/Kconfig. It should probably grow a 'depends on PCI' rline or so.

Sounds like it.

iirc the patch used early pci which is actually self contained in its header. The main problem was that it didn't use it correctly.

-Andi

Signature · 1 line
[email protected] -- Speaking for myself only.
#9 lore raw
Quoted 11 lines · Andi Kleen
Quoted 5 lines · H. Peter Anvin
Quoted 3 lines · Ingo Molnar

X86_RDC321X already exists in arch/x86/Kconfig. It should probably grow a 'depends on PCI' rline or so.

Sounds like it.

iirc the patch used early pci which is actually self contained in its header. The main problem was that it didn't use it correctly.

It isn't a matter of if compilation works, it is a matter of if we should even try to probe PCI if the user has explicitly disabled CONFIG_PCI. arch/x86/kernel/cpu/cyrix.c disables its PCI probing if CONFIG_PCI is off, even though it also uses <asm/pci-direct.h>.

Given that the benefit of this CPU detection patch is extremely small (all it does it get better information in /proc/cpuinfo) and that blind probing can have disastrous consequences, I would say it should not.

-hpa

#16 lore raw
In reply to Andi Kleen
Quoted 11 lines · Andi Kleen
Quoted 5 lines · H. Peter Anvin
Quoted 3 lines · Ingo Molnar

X86_RDC321X already exists in arch/x86/Kconfig. It should probably grow a 'depends on PCI' rline or so.

Sounds like it.

iirc the patch used early pci which is actually self contained in its header. The main problem was that it didn't use it correctly.

Just saw your other email. early_pci_allowed() is defined in arch/x86/pci/early.c which is only compiled (as is the whole arch/x86/pci directory) if CONFIG_PCI is enabled, so the compile-time guard is needed.

-hpa

#10 lore raw
In reply to H. Peter Anvin
Quoted 1 line

It isn't a matter of if compilation works, it is a matter of if we

I was actually wrong -- someone moved the functions out of line. So CONFIG_PCI is needed after all.

Quoted 3 lines

should even try to probe PCI if the user has explicitly disabled CONFIG_PCI. arch/x86/kernel/cpu/cyrix.c disables its PCI probing if CONFIG_PCI is off, even though it also uses <asm/pci-direct.h>.

Better would be if he used early_pci_allowed() then this could be set at runtime.

Quoted 3 lines

Given that the benefit of this CPU detection patch is extremely small (all it does it get better information in /proc/cpuinfo) and that blind probing can have disastrous consequences, I would say it should not.

I thought it was to prevent oopses for zero cpu according to the reporter?

But these oopses should be probably separately fixed anyways.

-Andi

Signature · 1 line
[email protected] -- Speaking for myself only.
#11 lore raw
Quoted 6 lines · Andi Kleen

I thought it was to prevent oopses for zero cpu according to the reporter?

But these oopses should be probably separately fixed anyways.

They should.

-hpa

author
#12 lore raw

PATCH v2 1/1 x86: CPU detection for RDC

Quoted 9 lines · H. Peter Anvin
Quoted 6 lines · Andi Kleen

I thought it was to prevent oopses for zero cpu according to the reporter?

But these oopses should be probably separately fixed anyways.

They should.

Perhaps, but they don't need to be. Unfortunately I was testing up to 2.6.30.5 (which gives the Oops), but someone must have changed the detection code for 486 in Linus' tree, because when I tried that (at Ingo's suggestion) I magically got a boot, and a correctly recognised 486 without my patch. This does rather remove my reason for the patch submission, but I will carry on if people think this is still worthwhile.

With the above in mind we can give up on detection without fear of a subsequent Oops, so I've simplified the code to not bother with the unrecognised variants (still gives a warning).

I've added the PCI config dependency, and the runtime check. I'll call this v2, please ignore all the previous patches. It's against 2.6.31-rc6-tip.

regards,
Mark.

Documentation/x86/rdc.txt new file +69 -0
new file mode 100644
index 0000000..f9591af
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to [email protected].
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
[email protected] 2009
+
arch/x86/Kconfig +1 -0
index 1655b77..5d2bcaa 100644
@@ -382,6 +382,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	select PCI
 	select M486
 	select X86_REBOOTFIXUPS
 	---help---
arch/x86/include/asm/processor.h +2 -1
index 2b03f70..75b96e9 100644
@@ -122,7 +122,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
arch/x86/kernel/cpu/Makefile +1 -0
index 3efcb2b..55ba09a 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_PERF_COUNTERS)		+= perf_counter.o
 
arch/x86/kernel/cpu/rdc.c new file +69 -0

69 lines not on this page · raw message

Acked-by on v2 1/1
#13 lore raw

Re: [patch, v2] x86: CPU detection for RDC

Hi Mark,

Le Monday 17 August 2009 09:13:58 Mark Kelly, vous avez écrit :

Quoted 16 lines · H. Peter Anvin
Quoted 7 lines · Andi Kleen
Quoted 4 lines

I thought it was to prevent oopses for zero cpu according to the reporter?

But these oopses should be probably separately fixed anyways.

They should.

Perhaps, but they don't need to be. Unfortunately I was testing up to 2.6.30.5 (which gives the Oops), but someone must have changed the detection code for 486 in Linus' tree, because when I tried that (at Ingo's suggestion) I magically got a boot, and a correctly recognised 486 without my patch. This does rather remove my reason for the patch submission, but I will carry on if people think this is still worthwhile.

Quoted 7 lines

With the above in mind we can give up on detection without fear of a subsequent Oops, so I've simplified the code to not bother with the unrecognised variants (still gives a warning).

I've added the PCI config dependency, and the runtime check. I'll call this v2, please ignore all the previous patches. It's against 2.6.31-rc6-tip.

Thanks for doing that.

Quoted 7 lines

regards,
Mark.

Quoted 188 lines
Documentation/x86/rdc.txt new file +69 -0
new file mode 100644
index 0000000..f9591af
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to [email protected].
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
[email protected] 2009
+
arch/x86/Kconfig +1 -0
index 1655b77..5d2bcaa 100644
@@ -382,6 +382,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	select PCI
 	select M486
 	select X86_REBOOTFIXUPS
 	---help---
(quoted diff) +0 -0

b/arch/x86/include/asm/processor.h index 2b03f70..75b96e9 100644

arch/x86/include/asm/processor.h +2 -1
@@ -122,7 +122,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
arch/x86/kernel/cpu/Makefile +1 -0
index 3efcb2b..55ba09a 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_PERF_COUNTERS)		+= perf_counter.o
 
arch/x86/kernel/cpu/rdc.c new file +54 -0
new file mode 100644
index 0000000..369a671
@@ -0,0 +1,69 @@
+/*
+ * See Documentation/x86/rdc.txt
+ *
+ * [email protected]
+ */
+
+#include <linux/pci.h>
+#include <asm/pci-direct.h>
+#include "cpu.h"
+
+
+static void __cpuinit rdc_identify(struct cpuinfo_x86 *c)
+{
+	u16 vendor, device;
+	u32 customer_id;
+
+	if (!early_pci_allowed())
+		return;
+
+	/* RDC CPU is SoC (system-on-chip), Northbridge is always present */
+	vendor = read_pci_config_16(0, 0, 0, PCI_VENDOR_ID);
+	device = read_pci_config_16(0, 0, 0, PCI_DEVICE_ID);
+
+	if (vendor != PCI_VENDOR_ID_RDC || device != PCI_DEVICE_ID_RDC_R6020)
+		return;  /* not RDC */
+	/*
+	 * NB: We could go on and check other devices, e.g. r6040 NIC, but
+	 * that's probably overkill
+	 */
+
+	customer_id = read_pci_config(0, 0, 0, 0x90);
+
+	switch (customer_id) {
+		/* id names are from RDC */
+	case 0x00321000:
+		strcpy(c->x86_model_id, "R3210/R3211");
+		break;
+	case 0x00321001:
+		strcpy(c->x86_model_id, "AMITRISC20000/20010");
+		break;
+	case 0x00321002:
+		strcpy(c->x86_model_id, "R3210X/Edimax");
+		break;
+	case 0x00321003:
+		strcpy(c->x86_model_id, "R3210/Kcodes");
+		break;
+	case 0x00321004:  /* tested */
+		strcpy(c->x86_model_id, "S3282/CodeTek");
+		break;
+	case 0x00321007:
+		strcpy(c->x86_model_id, "R8610");
+		break;
+	default:
+		pr_info("RDC CPU: Unrecognised Customer ID (0x%x) please report to

[email protected]\n", customer_id); + return;

arch/x86/kernel/cpu/rdc.c new file +14 -0
+	}
+
+	strcpy(c->x86_vendor_id, "RDC");
+	c->x86_vendor = X86_VENDOR_RDC;
+}
+
+static const struct cpu_dev __cpuinitconst rdc_cpu_dev = {
+	.c_vendor	= "RDC",
+	.c_ident	= { "RDC" },
+	.c_identify	= rdc_identify,
+	.c_x86_vendor	= X86_VENDOR_RDC,
+};
+
+cpu_dev_register(rdc_cpu_dev);
Signature · 5 lines
Best regards, Florian Fainelli
Email: [email protected]
Web: http://openwrt.org
IRC: [florian] on irc.freenode.net
-------------------------------
#14 lore raw

Re: [patch, v2] x86: CPU detection for RDC

In reply to Mark Kelly

arch/x86/Kconfig config X86_RDC321X · line 387

Quoted 9 lines · Mark Kelly
arch/x86/Kconfig +1 -0
@@ -382,6 +382,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	select PCI
 	select M486
 	select X86_REBOOTFIXUPS

PCI is a complex interactive Kconfig switch and we dont select it in x86 code. Please add a 'depends on PCI' line instead, as i suggested in my mail.

Ingo

author
#15 lore raw

Re: [patch, v3] x86: CPU detection for RDC

Quoted 3 lines · Ingo Molnar

PCI is a complex interactive Kconfig switch and we dont select it in x86 code. Please add a 'depends on PCI' line instead, as i suggested in my mail.

Here you go. That's the only change over v2.

Documentation/x86/rdc.txt new file +69 -0
new file mode 100644
index 0000000..f9591af
@@ -0,0 +1,69 @@
+
+Introduction
+============
+
+RDC (http://www.rdc.com.tw) have been manufacturing x86-compatible SoC
+(system-on-chips) for a number of years.  They are not the fastest of
+CPUs (clock speeds ranging from 133-150MHz) but 486SX compatibility
+coupled with very low power consumption[1] and low cost make them ideal
+for embedded applications.
+
+
+Where to find
+=============
+
+RDC chips show up in numerous embedded devices, but be careful since
+many of them will not run Linux 2.6 without significant expertise.
+
+There are several variants of what the linux kernel refers to generically
+as RDC321X:  R8610, R321x, S3282 and AMRISC20000.
+
+R321x: Found in various routers, see the OpenWrt project for details,
+   http://wiki.openwrt.org/oldwiki/rdcport
+
+R8610: Found on the RDC evaluation board
+   http://www.ivankuten.com/system-on-chip-soc/rdc-r8610/
+
+AMRISC20000: Found in the MGB-100 wireless hard disk
+   http://tintuc.no-ip.com/linux/tipps/mgb100/
+
+S3282: Found in various NAS devices, including the Bifferboard
+   http://www.bifferos.com
+
+
+Kernel Configuration
+====================
+
+Add support for this CPU with CONFIG_X86_RDC321X.  Ensure that maths
+emulation is included (CONFIG_MATH_EMULATION selected) and avoid MCE
+(CONFIG_X86_MCE not selected).
+
+
+CPU detection
+=============
+
+None of these chips support the cpuid instruction, so as with some
+other x86 compatible SoCs, we must check the north bridge and look
+for specific 'signature' PCI device config.
+
+The current detection code has been tested only on the Bifferboard
+(S3282 CPU), please send bug reports or success stories with
+other devices to [email protected].
+
+
+Credits
+=======
+
+Many thanks to RDC for providing the customer codes to allow
+detection of all known variants, without which this detection code
+would have been very hard to ascertain.
+
+
+References
+==========
+
+[1] S3282 in certain NAS solutions consumes less than 1W
+
+
[email protected] 2009
+
arch/x86/Kconfig +1 -0
index 1655b77..c4ebc76 100644
@@ -382,6 +382,7 @@ config X86_RDC321X
 	bool "RDC R-321x SoC"
 	depends on X86_32
 	depends on X86_EXTENDED_PLATFORM
+	depends on PCI
 	select M486
 	select X86_REBOOTFIXUPS
 	---help---
arch/x86/include/asm/processor.h +2 -1
index 2b03f70..75b96e9 100644
@@ -122,7 +122,8 @@ struct cpuinfo_x86 {
 #define X86_VENDOR_CENTAUR	5
 #define X86_VENDOR_TRANSMETA	7
 #define X86_VENDOR_NSC		8
-#define X86_VENDOR_NUM		9
+#define X86_VENDOR_RDC		9
+#define X86_VENDOR_NUM		10
 
 #define X86_VENDOR_UNKNOWN	0xff
 
arch/x86/kernel/cpu/Makefile +1 -0
index 3efcb2b..55ba09a 100644
@@ -22,6 +22,7 @@ obj-$(CONFIG_CPU_SUP_CYRIX_32)		+= cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)		+= centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32)	+= transmeta.o
 obj-$(CONFIG_CPU_SUP_UMC_32)		+= umc.o
+obj-$(CONFIG_X86_RDC321X)		+= rdc.o
 
 obj-$(CONFIG_PERF_COUNTERS)		+= perf_counter.o
 
arch/x86/kernel/cpu/rdc.c new file +69 -0

69 lines not on this page · raw message