Skip to contentSkip to conversation

Enable AT_PLATFORM for Loongson 2F CPU

PATCH In review Robert Millan 5 participants 18 messages Nov 4, 2010 – Nov 22, 2010

Subsystems (2)
MIPS exec and binfmt
lore
Share & tools
lore

Robert Millan

author
#0 lore raw

PATCH 1/1 Enable AT_PLATFORM for Loongson 2F CPU

Please consider this patch, it enables AT_PLATFORM for Loongson 2F CPU.

Enable AT_PLATFORM for Loongson 2F CPU.

Signed-off-by Robert Millan <[email protected]>
arch/mips/kernel/cpu-probe.c +2 -0
index 71620e1..504f3b1 100644
@@ -614,6 +614,8 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
 		__cpu_name[cpu] = "ICT Loongson-2";
+		if (cpu == 0)
+			__elf_platform = "loongson-2f";
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |
#1 lore raw
Quoted 4 lines · Robert Millan

Please consider this patch, it enables AT_PLATFORM for Loongson 2F CPU.

[...]

arch/mips/kernel/cpu-probe.c static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu) · line 621

Quoted 13 lines
arch/mips/kernel/cpu-probe.c +2 -0
index 71620e1..504f3b1 100644
@@ -614,6 +614,8 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
 		__cpu_name[cpu] = "ICT Loongson-2";
+		if (cpu == 0)
+			__elf_platform = "loongson-2f";
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |

This doesn't look right to me.

You are claiming that all loongson2 are loongson-2f. Is that really true? Or are there other types of loongson2 that are not loongson-2f?

You need to be very careful here. This is part of the userspace ABI, so if you get it wrong, you are stuck with it forever.

One question you didn't address is why userspace would care that it is running on exactly "loongson-2f" instead of just mips4.

The __elf_platform gets converted to a directory name by ld.so, so you may want to choose a value without '-' in it.

My suggestion would be to set "loongson2" for the generic CPU_LOONGSON2, and if there is a good reason for it, "loongson2f" for the 'f' variant.

David Daney

#2 lore raw
Quoted 27 lines · David Daney
Quoted 3 lines · Robert Millan

Please consider this patch, it enables AT_PLATFORM for Loongson 2F CPU.

[...]

arch/mips/kernel/cpu-probe.c static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu) · line 621

Quoted 13 lines
arch/mips/kernel/cpu-probe.c +2 -0
index 71620e1..504f3b1 100644
@@ -614,6 +614,8 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
 		__cpu_name[cpu] = "ICT Loongson-2";
+		if (cpu == 0)
+			__elf_platform = "loongson-2f";
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |

This doesn't look right to me.

You are claiming that all loongson2 are loongson-2f. Is that really true? Or are there other types of loongson2 that are not loongson-2f?

You need to be very careful here. This is part of the userspace ABI, so if you get it wrong, you are stuck with it forever.

Quoted 9 lines

One question you didn't address is why userspace would care that it is running on exactly "loongson-2f" instead of just mips4.

The __elf_platform gets converted to a directory name by ld.so, so you may want to choose a value without '-' in it.

My suggestion would be to set "loongson2" for the generic CPU_LOONGSON2, and if there is a good reason for it, "loongson2f" for the 'f' variant.

You should definitely define here loongson-2e and loongson-2f separately. They have the same instruction set, but different opcodes for the loongson specific instructions, hence they are not compatible.

Signature · 2 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
author
#3 lore raw

Hi!

Quoted 5 lines · David Daney

You are claiming that all loongson2 are loongson-2f.  Is that really true?  Or are there other types of loongson2 that are not loongson-2f?

You need to be very careful here.  This is part of the userspace ABI, so if you get it wrong, you are stuck with it forever.

I'll figure out how to distinguish them and send a new patch.

Quoted 2 lines

One question you didn't address is why userspace would care that it is running on exactly "loongson-2f" instead of just mips4.

I think Aurelien answered this.

Quoted 2 lines

The __elf_platform gets converted to a directory name by ld.so, so you may want to choose a value without '-' in it.

Well I appreciate consistency with GCC flag names, so I'd rather keep the dash, but then again it's not my decision to make. In any case, whoever commits this can adjust the name to his/her liking.

Signature · 1 line
Robert Millan
#4 lore raw
Quoted 14 lines · Robert Millan

Hi!

Quoted 5 lines · David Daney

You are claiming that all loongson2 are loongson-2f. Is that really true? Or are there other types of loongson2 that are not loongson-2f?

You need to be very careful here. This is part of the userspace ABI, so if you get it wrong, you are stuck with it forever.

I'll figure out how to distinguish them and send a new patch.

Quoted 2 lines

One question you didn't address is why userspace would care that it is running on exactly "loongson-2f" instead of just mips4.

Quoted 8 lines

I think Aurelien answered this.

Quoted 2 lines

The __elf_platform gets converted to a directory name by ld.so, so you may want to choose a value without '-' in it.

Well I appreciate consistency with GCC flag names, so I'd rather keep the dash, but then again it's not my decision to make. In any case, whoever commits this can adjust the name to his/her liking.

I don't like to put words into Ralf's mouth, but it is easier to work with patches that have been tested and are ready to go, rather than having to re-write everything.

Some of the strings in use are "i686", "x86_64", "octeon", "octeon2", "PARISC", "PARISC32", tilegx-m32", "v4l", "v3l", "v4b", and "v3b", these last for for ARM and they don't match the GCC -mcpu= values.

So I guess what ever you want.

David Daney

#5 lore raw
Quoted 7 lines · David Daney
Quoted 3 lines

Well I appreciate consistency with GCC flag names, so I'd rather keep the dash, but then again it's not my decision to make. In any case, whoever commits this can adjust the name to his/her liking.

I don't like to put words into Ralf's mouth, but it is easier to work with patches that have been tested and are ready to go, rather than having to re-write everything.

Indeed. I modify lots of patches that I can't test on my hardware collection so any change I have to do also increases of me adding bugs. Heck, I do most of my builds on fairly modest dual core machines so I can't even afford test builds which is how occasionally the most stupid errors end up getting committed.

Which is why I'm increasingly asking people to do trivial changes to patches, not because I'm lazy.

Quoted 6 lines

Some of the strings in use are "i686", "x86_64", "octeon", "octeon2", "PARISC", "PARISC32", tilegx-m32", "v4l", "v3l", "v4b", and "v3b", these last for for ARM and they don't match the GCC -mcpu= values.

So I guess what ever you want.

It's probably reasonable if the names don't diverge too far from each other. Then again with the number of cpu type synonyms accepted by gcc that may just be wishful thinking.

Ralf

author
#6 lore raw
In reply to Robert Millan

El 04/11/10 19:43:08, en/na Robert Millan va escriure:

Quoted 6 lines
Quoted 3 lines · David Daney

You are claiming that all loongson2 are loongson-2f.  Is that really true?  Or are there other types of loongson2 that are not loongson-2f?

I'll figure out how to distinguish them and send a new patch.

I looked at details about CPU identification, and this seems to be broken.

See the the notes about PRId in pages 72 and 66, respectively:
http://dev.lemote.com/files/resource/documents/Loongson/ls2f/Loongson2FUserGuide.pdf

In both 2E and 2F, the implementation field is the same (0x63).

Revision field is the same too, according to docs, and it can't be used anyway (no garantee of consistency).

I'm sending a new patch that uses machtype instead. Yes, I know it's a bit of a kludge, but it really seems to be the only way.

Quoted 1 line

Well I appreciate consistency with GCC flag names,

Actually, I missread GCC flag (it's dashless). I'm using "loongson2f" as David requested.

Enable AT_PLATFORM for Loongson 2F CPU.

Signed-off-by Robert Millan <[email protected]>
arch/mips/kernel/cpu-probe.c +26 -1
index 71620e1..69905d2 100644
@@ -5,6 +5,7 @@
  * Copyright (C) 1994 - 2006 Ralf Baechle
  * Copyright (C) 2003, 2004  Maciej W. Rozycki
  * Copyright (C) 2001, 2004  MIPS Inc.
+ * Copyright (C) 2010  Robert Millan
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License

@@ -18,6 +19,7 @@
 #include <linux/stddef.h>
 #include <linux/module.h>
 
+#include <asm/bootinfo.h>
 #include <asm/bugs.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>

@@ -613,7 +615,30 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 		break;
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
-		__cpu_name[cpu] = "ICT Loongson-2";
+		/*
+		 * On Loongson 2, PRID doesn't specify sub-class reliably.
+		 * We use machtype info passed by bootloader, when available,
+		 * or otherwise fallback to generic "ICT Loongson-2".
+		 */
+		switch (mips_machtype) {
+		case MACH_LEMOTE_FL2E:
+			__cpu_name[cpu] = "ICT Loongson-2E";
+			if (cpu == 0)
+				__elf_platform = "loongson2e";
+			break;
+		case MACH_LEMOTE_FL2F:
+		case MACH_LEMOTE_ML2F7:
+		case MACH_LEMOTE_YL2F89:
+		case MACH_DEXXON_GDIUM2F10:
+		case MACH_LEMOTE_NAS:
+		case MACH_LEMOTE_LL2F:
+			__cpu_name[cpu] = "ICT Loongson-2F";
+			if (cpu == 0)
+				__elf_platform = "loongson2f";
+			break;
+		default:
+			__cpu_name[cpu] = "ICT Loongson-2";
+		}
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |
arch/mips/kernel/setup.c +8 -0
index acd3f2c..74b8c16 100644
@@ -551,6 +551,14 @@ void __init setup_arch(char **cmdline_p)
 {
 	cpu_probe();
 	prom_init();
+#ifdef CONFIG_MACH_LOONGSON
+	/*
+	 * On Loongson 2, CPU detection is defective. machtype
+	 * heuristics are used instead, but they only work after
+	 * prom_init().
+	 */
+	cpu_probe();
+#endif
 
 #ifdef CONFIG_EARLY_PRINTK
 	setup_early_printk();
#7 lore raw
Quoted 11 lines · Robert Millan

El 04/11/10 19:43:08, en/na Robert Millan va escriure:

Quoted 6 lines
Quoted 3 lines · David Daney

You are claiming that all loongson2 are loongson-2f. Is that really true? Or are there other types of loongson2 that are not loongson-2f?

I'll figure out how to distinguish them and send a new patch.

I looked at details about CPU identification, and this seems to be broken.

Quoted 7 lines

See the the notes about PRId in pages 72 and 66, respectively:
http://dev.lemote.com/files/resource/documents/Loongson/ls2f/Loongson2FUserGuide.pdf

In both 2E and 2F, the implementation field is the same (0x63).

Revision field is the same too, according to docs, and it can't be used anyway (no garantee of consistency).

I seems weird to me that you cannot get this information from the PRId register. Perhaps the documentation is defective.

The Chinese version of the Loongson2E user guide seems to say something about the two lower nibbles of the PRId, but being a non-chinese reader, I have no idea if it would be relevant.

I would think that the low order bits of the register can reliably differentiate these two parts.

David Daney

Quoted 9 lines

I'm sending a new patch that uses machtype instead. Yes, I know it's a bit of a kludge, but it really seems to be the only way.

Quoted 1 line

Well I appreciate consistency with GCC flag names,

Actually, I missread GCC flag (it's dashless). I'm using "loongson2f" as David requested.

author
#8 lore raw

2010/11/8 David Daney <[email protected]>:

Quoted 2 lines

I seems weird to me that you cannot get this information from the PRId register.  Perhaps the documentation is defective.

Yes, I agree it's really shortsighted of them, but I don't see any way around it.

Quoted 6 lines

The Chinese version of the Loongson2E user guide seems to say something about the two lower nibbles of the PRId, but being a non-chinese reader, I have no idea if it would be relevant.

I would think that the low order bits of the register can reliably differentiate these two parts.

There are English versions for both 2E and 2F. See page 66 of the Loongson 2F document:

http://dev.lemote.com/files/resource/documents/Loongson/ls2f/Loongson2FUserGuide.pdf

<quote>
The revision number can distinguish some chip revisions, however there is no guarantee
that changes to the chip will necessarily be reflected in the PRId register, or that changes to
the revision number necessarily reflect real chip changes. For this reason, software should
not rely on the revision number in the PRId register to characterize the chip. </quote>

Page 72 of the Loongson 2E document
(http://www.lemote.com/upfiles/godson2e-user-manual-V0.6.pdf) has the same text.

In both documents, the lower byte is defined as "Revision number", and its value is 0x02 (for both 2E and 2F).

If you'd rather not assume the docs are correct, I can test if my Yeeloong (Loongson 2F) has 0x02, but then in case it's something higher, would you be willing to assume:

rev <= 0x02 --> 2E
rev > 0x02 --> 2F

or similar logic? This seems risky if we take into account that there's no guarantee from the vendor.

Signature · 1 line
Robert Millan
#9 lore raw
Quoted 36 lines · Robert Millan

2010/11/8 David Daney<[email protected]>:

Quoted 2 lines

I seems weird to me that you cannot get this information from the PRId register. Perhaps the documentation is defective.

Yes, I agree it's really shortsighted of them, but I don't see any way around it.

Quoted 6 lines

The Chinese version of the Loongson2E user guide seems to say something about the two lower nibbles of the PRId, but being a non-chinese reader, I have no idea if it would be relevant.

I would think that the low order bits of the register can reliably differentiate these two parts.

There are English versions for both 2E and 2F. See page 66 of the Loongson 2F document:

http://dev.lemote.com/files/resource/documents/Loongson/ls2f/Loongson2FUserGuide.pdf

<quote>
The revision number can distinguish some chip revisions, however there is no guarantee
that changes to the chip will necessarily be reflected in the PRId register, or that changes to
the revision number necessarily reflect real chip changes. For this reason, software should
not rely on the revision number in the PRId register to characterize the chip. </quote>

Page 72 of the Loongson 2E document
(http://www.lemote.com/upfiles/godson2e-user-manual-V0.6.pdf) has the same text.

In both documents, the lower byte is defined as "Revision number", and its value is 0x02 (for both 2E and 2F).

Quoted 7 lines

If you'd rather not assume the docs are correct, I can test if my Yeeloong (Loongson 2F) has 0x02, but then in case it's something higher, would you be willing to assume:

   rev<= 0x02  -->   2E
   rev>  0x02  -->  2F

No, I refuse to assume that.

Look at the description of the register in this document:

http://dev.lemote.com/files/resource/documents/Loongson/ls2e/godson2e.user.manual.pdf

On page 49, it says that bits 0-3 contain the minor version number and bits 4-7 are the major version number (according to a workmate that reads Chinese).

I don't know for certain, but it seems plausible that the 2E and 2F will differ in bits 4-7, and bits 0-3 can be ignored.

Quoted 3 lines

or similar logic? This seems risky if we take into account that there's no guarantee from the vendor.

author
#10 lore raw

2010/11/8 David Daney <[email protected]>:

Quoted 10 lines

Look at the description of the register in this document:

http://dev.lemote.com/files/resource/documents/Loongson/ls2e/godson2e.user.manual.pdf

On page 49, it says that bits 0-3 contain the minor version number and bits 4-7 are the major version number (according to a workmate that reads Chinese).

I don't know for certain, but it seems plausible that the 2E and 2F will differ in bits 4-7, and bits 0-3 can be ignored.

Thanks for investigating, but ignoring bits 0-3 doesn't really change anything. Our problem was that bits 0-7 are the same on 2E and 2F (0x02). If we ignore bits 0-3, then our problem is that bits 4-7 are the same on 2E and 2F (0x2).

Signature · 1 line
Robert Millan
#11 lore raw

Hi, Robert

Quoted 9 lines · Robert Millan

2010/11/8 David Daney <[email protected]>:

Quoted 8 lines

Look at the description of the register in this document:

http://dev.lemote.com/files/resource/documents/Loongson/ls2e/godson2e.user.manual.pdf

On page 49, it says that bits 0-3 contain the minor version number and bits 4-7 are the major version number (according to a workmate that reads Chinese).

Quoted 8 lines
Quoted 2 lines

I don't know for certain, but it seems plausible that the 2E and 2F will differ in bits 4-7, and bits 0-3 can be ignored.

Thanks for investigating, but ignoring bits 0-3 doesn't really change anything.  Our problem was that bits 0-7 are the same on 2E and 2F (0x02).  If we ignore bits 0-3, then our problem is that bits 4-7 are the same on 2E and 2F (0x2).

Just rechecked this with a friend from Lemote, in reality, the revision id of Loongson-2F is 0x3, so, my old code should be a reference for you:

arch/mips/loongson/common/platform.c

PRID_REV_LOONGSON2F and PRID_REV_LOONGSON2E has already been defined in arch/mips/include/asm/cpu.h

So, the manual is buggy, perhaps the editors of the manuals did copy and paste for I have found the title of the 2F manual is the same as the 2E manual ;-)

Best Regards,
Wu Zhangjin

author
#12 lore raw

El 09/11/10 10:48:34, en/na wu zhangjin va escriure:

Quoted 4 lines

Just rechecked this with a friend from Lemote, in reality, the revision id of Loongson-2F is 0x3, so, my old code should be a reference for you:

Quoted 8 lines

arch/mips/loongson/common/platform.c

PRID_REV_LOONGSON2F and PRID_REV_LOONGSON2E has already been defined in arch/mips/include/asm/cpu.h

So, the manual is buggy, perhaps the editors of the manuals did copy and paste for I have found the title of the 2F manual is the same as the 2E manual ;-)

Thank you! Then I suppose this will do it.

Signed-off-by Robert Millan <[email protected]>
arch/mips/kernel/cpu-probe.c +14 -1
index 71620e1..4341950 100644
@@ -613,7 +613,20 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 		break;
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
-		__cpu_name[cpu] = "ICT Loongson-2";
+		switch (c->processor_id & PRID_REV_MASK) {
+		case PRID_REV_LOONGSON2E:
+			__cpu_name[cpu] = "ICT Loongson-2E";
+			if (cpu == 0)
+				__elf_platform = "loongson2e";
+			break;
+		case PRID_REV_LOONGSON2F:
+			__cpu_name[cpu] = "ICT Loongson-2F";
+			if (cpu == 0)
+				__elf_platform = "loongson2f";
+			break;
+		default:
+			__cpu_name[cpu] = "ICT Loongson-2";
+		}
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |
#13 lore raw
Quoted 7 lines · Robert Millan

El 09/11/10 10:48:34, en/na wu zhangjin va escriure:

Quoted 6 lines

Just rechecked this with a friend from Lemote, in reality, the revision id of Loongson-2F is 0x3, so, my old code should be a reference for you:

arch/mips/loongson/common/platform.c

Quoted 8 lines
Quoted 6 lines

PRID_REV_LOONGSON2F and PRID_REV_LOONGSON2E has already been defined in arch/mips/include/asm/cpu.h

So, the manual is buggy, perhaps the editors of the manuals did copy and paste for I have found the title of the 2F manual is the same as the 2E manual ;-)

Thank you! Then I suppose this will do it.

Looks technically ok; I just have a more stylistic problem with the patch:

arch/mips/kernel/cpu-probe.c static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu) · line 620

Quoted 2 lines
arch/mips/kernel/cpu-probe.c +2 -0
+			if (cpu == 0)
+				__elf_platform = "loongson2e";

Cavium introduced this idion first. Now your patch is repeating it and I'm
sure other SMP platforms will soon use it. I don't want a thousand
if (cpu == 0) in that file, so can you cook a patch that introduces a helper, something like

static void set_elf_platform(const char *plat)

{
	if (cpu == 0)
		__elf_platform = plat;
}

Then use that for all assignments to __elf_platform? Thanks.

Ralf

author
#14 lore raw

El 09/11/10 16:40:55, en/na Ralf Baechle va escriure:

Quoted 6 lines

Cavium introduced this idion first. Now your patch is repeating it and I'm
sure other SMP platforms will soon use it. I don't want a thousand
if (cpu == 0) in that file, so can you cook a patch that introduces a helper, something like

Quoted 7 lines

static void set_elf_platform(const char *plat)

{
	if (cpu == 0)
		__elf_platform = plat;
}

Then use that for all assignments to __elf_platform? Thanks.

Here.

Signed-off-by Robert Millan <[email protected]>
arch/mips/include/asm/elf.h +6 -0
index fd1d39e..58844f6 100644
@@ -344,6 +344,12 @@ extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *);
 #define ELF_PLATFORM  __elf_platform
 extern const char *__elf_platform;
 
+static inline void set_elf_platform(int cpu, const char *plat)
+{
+	if (cpu == 0)
+		__elf_platform = plat;
+}
+
 /*
  * See comments in asm-alpha/elf.h, this is the same thing
  * on the MIPS.
arch/mips/kernel/cpu-probe.c +14 -5
index 71620e1..7e547ca 100644
@@ -613,7 +613,18 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 		break;
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
-		__cpu_name[cpu] = "ICT Loongson-2";
+		switch (c->processor_id & PRID_REV_MASK) {
+		case PRID_REV_LOONGSON2E:
+			__cpu_name[cpu] = "ICT Loongson-2E";
+			set_elf_platform(cpu, "loongson2e");
+			break;
+		case PRID_REV_LOONGSON2F:
+			__cpu_name[cpu] = "ICT Loongson-2F";
+			set_elf_platform(cpu, "loongson2f");
+			break;
+		default:
+			__cpu_name[cpu] = "ICT Loongson-2";
+		}
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |

@@ -957,14 +968,12 @@ static inline void cpu_probe_cavium(struct cpuinfo_mips *c, unsigned int cpu)
 		c->cputype = CPU_CAVIUM_OCTEON_PLUS;
 		__cpu_name[cpu] = "Cavium Octeon+";
 platform:
-		if (cpu == 0)
-			__elf_platform = "octeon";
+		set_elf_platform(cpu, "octeon");
 		break;
 	case PRID_IMP_CAVIUM_CN63XX:
 		c->cputype = CPU_CAVIUM_OCTEON2;
 		__cpu_name[cpu] = "Cavium Octeon II";
-		if (cpu == 0)
-			__elf_platform = "octeon2";
+		set_elf_platform(cpu, "octeon2");
 		break;
 	default:
 		printk(KERN_INFO "Unknown Octeon chip!\n");
author
#15 lore raw

El 11/11/10 15:47:35, en/na Robert Millan va escriure:

Review

Quoted 4 lines
(quoted diff) +3 -1
-		__cpu_name[cpu] = "ICT Loongson-2";
+		switch (c->processor_id & PRID_REV_MASK) {
+		case PRID_REV_LOONGSON2E:
+			__cpu_name[cpu] = "ICT Loongson-2E";

Actually, the V0.2 / V0.3 that follows in cpuinfo output already indicates revision. And I noticed that appending the 'E' or 'F' breaks GCC's -march=native option (which works by parsing /proc/cpuinfo).

Please use this patch instead.

Signed-off-by Robert Millan <[email protected]>
arch/mips/include/asm/elf.h +6 -0
index fd1d39e..58844f6 100644
@@ -344,6 +344,12 @@ extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *);
 #define ELF_PLATFORM  __elf_platform
 extern const char *__elf_platform;
 
+static inline void set_elf_platform(int cpu, const char *plat)
+{
+	if (cpu == 0)
+		__elf_platform = plat;
+}
+
 /*
  * See comments in asm-alpha/elf.h, this is the same thing
  * on the MIPS.
arch/mips/kernel/cpu-probe.c +10 -4
index 71620e1..accde65 100644
@@ -614,6 +614,14 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
 	case PRID_IMP_LOONGSON2:
 		c->cputype = CPU_LOONGSON2;
 		__cpu_name[cpu] = "ICT Loongson-2";
+		switch (c->processor_id & PRID_REV_MASK) {
+		case PRID_REV_LOONGSON2E:
+			set_elf_platform(cpu, "loongson2e");
+			break;
+		case PRID_REV_LOONGSON2F:
+			set_elf_platform(cpu, "loongson2f");
+			break;
+		}
 		c->isa_level = MIPS_CPU_ISA_III;
 		c->options = R4K_OPTS |
 			     MIPS_CPU_FPU | MIPS_CPU_LLSC |

@@ -957,14 +965,12 @@ static inline void cpu_probe_cavium(struct cpuinfo_mips *c, unsigned int cpu)
 		c->cputype = CPU_CAVIUM_OCTEON_PLUS;
 		__cpu_name[cpu] = "Cavium Octeon+";
 platform:
-		if (cpu == 0)
-			__elf_platform = "octeon";
+		set_elf_platform(cpu, "octeon");
 		break;
 	case PRID_IMP_CAVIUM_CN63XX:
 		c->cputype = CPU_CAVIUM_OCTEON2;
 		__cpu_name[cpu] = "Cavium Octeon II";
-		if (cpu == 0)
-			__elf_platform = "octeon2";
+		set_elf_platform(cpu, "octeon2");
 		break;
 	default:
 		printk(KERN_INFO "Unknown Octeon chip!\n");
Acked-by
#16 lore raw
Quoted 10 lines · Robert Millan

El 11/11/10 15:47:35, en/na Robert Millan va escriure:

Quoted 4 lines
Quoted 4 lines

- __cpu_name[cpu] = "ICT Loongson-2";
+ switch (c->processor_id& PRID_REV_MASK) {
+ case PRID_REV_LOONGSON2E:
+ __cpu_name[cpu] = "ICT Loongson-2E";

Actually, the V0.2 / V0.3 that follows in cpuinfo output already indicates revision. And I noticed that appending the 'E' or 'F' breaks GCC's -march=native option (which works by parsing /proc/cpuinfo).

Good catch, this is true, __cpu_name for better or worse is part of the kernel/user ABI. GCC parses this in gcc/config/mips/driver-native.c

Quoted 10 lines

Please use this patch instead.

loongson2f.diff

Signed-off-by Robert Millan<[email protected]>
Acked-by David Daney <[email protected]>
Quoted 54 lines
arch/mips/include/asm/elf.h +6 -0
index fd1d39e..58844f6 100644
@@ -344,6 +344,12 @@ extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *);
  #define ELF_PLATFORM  __elf_platform
  extern const char *__elf_platform;
 
+static inline void set_elf_platform(int cpu, const char *plat)
+{
+	if (cpu == 0)
+		__elf_platform = plat;
+}
+
  /*
   * See comments in asm-alpha/elf.h, this is the same thing
   * on the MIPS.
arch/mips/kernel/cpu-probe.c +10 -4
index 71620e1..accde65 100644
@@ -614,6 +614,14 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips *c, unsigned int cpu)
  	case PRID_IMP_LOONGSON2:
  		c->cputype = CPU_LOONGSON2;
  		__cpu_name[cpu] = "ICT Loongson-2";
+		switch (c->processor_id&  PRID_REV_MASK) {
+		case PRID_REV_LOONGSON2E:
+			set_elf_platform(cpu, "loongson2e");
+			break;
+		case PRID_REV_LOONGSON2F:
+			set_elf_platform(cpu, "loongson2f");
+			break;
+		}
  		c->isa_level = MIPS_CPU_ISA_III;
  		c->options = R4K_OPTS |
  			     MIPS_CPU_FPU | MIPS_CPU_LLSC |

@@ -957,14 +965,12 @@ static inline void cpu_probe_cavium(struct cpuinfo_mips *c, unsigned int cpu)
  		c->cputype = CPU_CAVIUM_OCTEON_PLUS;
  		__cpu_name[cpu] = "Cavium Octeon+";
  platform:
-		if (cpu == 0)
-			__elf_platform = "octeon";
+		set_elf_platform(cpu, "octeon");
  		break;
  	case PRID_IMP_CAVIUM_CN63XX:
  		c->cputype = CPU_CAVIUM_OCTEON2;
  		__cpu_name[cpu] = "Cavium Octeon II";
-		if (cpu == 0)
-			__elf_platform = "octeon2";
+		set_elf_platform(cpu, "octeon2");
  		break;
  	default:
  		printk(KERN_INFO "Unknown Octeon chip!\n");