Add support for 4KS cpu.

This patch adds support for both 4ksc and 4ksd cpus. These cpu are mainly used in embedded system such as smartcard or point of sell devices as they provide some extra security features.

Signed-off-by Franck <[email protected]>

Quoted 3 lines · Franck

This patch adds support for both 4ksc and 4ksd cpus. These cpu are mainly used in embedded system such as smartcard or point of sell devices as they provide some extra security features.

Please send patches inline.

Apart from the change to "arch/mips/kernel/cpu-probe.c", which is useful,
what's the benefit of the changes? Specifically how is selecting e.g. "CPU_4KSC" meant to be different from "CPU_MIPS32_R2"? Do you want to make GCC tune your code according to a specific's CPU pipeline description? If so, then it should probably be done a bit differently and there is actually no need to differentiate between specific members of the 4K family.

Quoted 1 line

Signed-off-by Franck <[email protected]>

You should rather use your real name here. [Hmm, why am I responding to
an anonym in the first place?...]

Maciej

FWIW, the 4KSc is a strict superset of the 4Kc (anticipating *some* of the Release 2 features, but not requiring them to be used) and the 4KSd is a strict superset of the 4KE. I would not recommend configuring CPU_MIPS32_R2 for the 4KSc.

They also have some physical security and cryptography accelleration features, some of which use extended CPU state that would require some kernel context management support if anyone wanted to actually use them in Linux applications. The real point of having a CPU_4KSC config flag would be to enable building-in such support.

Quoted 4 lines · Kevin D. Kissell

FWIW, the 4KSc is a strict superset of the 4Kc (anticipating *some* of the Release 2 features, but not requiring them to be used) and the 4KSd is a strict superset of the 4KE. I would not recommend configuring CPU_MIPS32_R2 for the 4KSc.

Well, the patch asked GCC to use the instruction set of the "4kec" CPU
for both (and also the "mips32r2" ISA, but that's overridden by the former), so it must have been incorrect in the first place

Quoted 3 lines

Well, the patch asked GCC to use the instruction set of the "4kec" CPU
for both (and also the "mips32r2" ISA, but that's overridden by the former), so it must have been incorrect in the first place

Which was sort-of why I replied. In particular, the MIPS32R2 bitfield instructions will probably cause a reserved instruction fault on a 4KSc.

should I pass these options to GCC for 4KSc ?

cflags-$(CONFIG_CPU_4KSC)      += \
                       $(call set_gccflags,4kc,mips32r1,r4600,mips3,mips2) \
                       -msmartmips -Wa,--trap

Quoted 6 lines

should I pass these options to GCC for 4KSc ?

cflags-$(CONFIG_CPU_4KSC)      += \
                       $(call set_gccflags,4kc,mips32r1,r4600,mips3,mips2) \
                       -msmartmips -Wa,--trap

s/mips32r1/mips32/, otherwise OK.

But since you seem to use SDE, you may as well just use "4ksc" (and
possibly skip "-msmartmips" as it's implied); similarly for "4ksd". Unfortunately documentation on what CPU types are accepted seems to be incomplete -- use `gcc -v --help' to see which ones are actually available.

Quoted 6 lines

But since you seem to use SDE, you may as well just use "4ksc" (and
possibly skip "-msmartmips" as it's implied); similarly for "4ksd". Unfortunately documentation on what CPU types are accepted seems to be incomplete -- use `gcc -v --help' to see which ones are actually available.

maybe something like these are better (I removed last parameter since it's no more used) ?

cflags-$(CONFIG_CPU_4KSC)       += \
                        $(call set_gccflags,4ksc,mips32,4kc,mips32) \
                        -Wa,--trap

cflags-$(CONFIG_CPU_4KSD)       += \
                        $(call set_gccflags,4ksd,mips32r2,4kec,mips32r2) \
                        -Wa,--trap

Actually it would be better to let smartmips options in case we use fallback options:

Quoted 3 lines

Actually it would be better to let smartmips options in case we use fallback options:

In which case the toolchain is not going to support the "-msmartmips"
option anyway...

They also have some physical security and cryptography accelleration features, some of which use extended CPU state that would require some kernel context management support if anyone wanted to actually use them in Linux applications. The real point of having a CPU_4KSC config flag would be to enable building-in such support.

I'm being a teeny bit vague about this, because I'm not 100% certain that all the details of "SmartMIPS" have been published.

2005/10/4, Kevin D. Kissell <[email protected]>:

Quoted 7 lines

They also have some physical security and cryptography accelleration features, some of which use extended CPU state that would require some kernel context management support if anyone wanted to actually use them in Linux applications. The real point of having a CPU_4KSC config flag would be to enable building-in such support.

what is extended CPU state that you're talking about ?

Quoted 3 lines

I'm being a teeny bit vague about this, because I'm not 100% certain that all the details of "SmartMIPS" have been published.

hmm, does that mean that smart mips extension couldn't be supported in Linux in case that this extension have not been published ?

I'm personally not a big believer in security-through-obscurity, but there are those, both inside and outside MIPS, who felt that the security of SmartMIPS cores would be enhanced if we didn't give away all of the details. As a consequence, we put off publishing the nitty-gritty details of SmartMIPS for quite a while. I note that we now have the programmers' manual on-line at www.mips.com, so I guess I'm implicitly cleared to discuss it in at least that level of detail.

A key element of SmartMIPS that allows for a ~2x speedup for crypto codes that rely on extended precision math (RSA, ECC) is the combination of an extension to the Hi/Lo accumulator (called "ACX") with a special extract-and-reduce instruction ("MFLHXU"). If one wants to use that in Linux - or at least, if one wants to allow more than one thread to be able to use it at a time - one needs to save/restore ACX on the kernel stackframe, along with Hi and Lo.

Quoted 4 lines

This patch adds support for both 4ksc and 4ksd cpus. These cpu are mainly used in embedded system such as smartcard or point of sell devices as they provide some extra security features.

Please send patches inline.

Apart from the change to "arch/mips/kernel/cpu-probe.c", which is useful,
what's the benefit of the changes? Specifically how is selecting e.g. "CPU_4KSC" meant to be different from "CPU_MIPS32_R2"? Do you want to make GCC tune your code according to a specific's CPU pipeline description? If so, then it should probably be done a bit differently and there is actually no need to differentiate between specific members of the 4K family.

Quoted 1 line

Signed-off-by Franck <[email protected]>

Quoted 1 line

Please send patches inline.

I can see it inlined...what email viewer are you using ?

True, but we may have some differences in future. For example, they both implements smart mips instructions. See options passed to GCC in mips Makefile, they're different from CPU_MIPS32_R2 ones. They also have a couple of instructions very useful for cryptographic

algorithms. And have some extra bits in TLB to protect pages from being execute for example. These are the main differences that I can

remember. Big fat warning: I sent all support I have done for these cpu, _not_ more, _not_ less. I agree it's almost nothing but it's a start...

See my other comment in this thread. As to the SmartMIPS/crypto
instructions -- unless they are going to be emitted by GCC for the kernel build (which I seriously doubt), there is no point in enabling them.

Quoted 2 lines

algorithms. And have some extra bits in TLB to protect pages from being execute for example. These are the main differences that I can

Now that may be of potential interest of the kernel, but again, that's in
principle probably not specific to these processors,

Quoted 3 lines

remember. Big fat warning: I sent all support I have done for these cpu, _not_ more, _not_ less. I agree it's almost nothing but it's a start...

Well, it's probably a bit too early for inclusion, but it's certainly not
for a review. By sending changes here for discussion early you may avoid a lot of hassle later when you may discover a major update is required for them to be accepted. Good luck!

Quoted 3 lines

See my other comment in this thread. As to the SmartMIPS/crypto
instructions -- unless they are going to be emitted by GCC for the kernel build (which I seriously doubt), there is no point in enabling them.

some assembly code could...

hmm, I'm not an expert in MIPS cpu as you guys, so can you give me an example of others processors that have such TLB features ?

Quoted 5 lines

Quoted 3 lines

This patch adds support for both 4ksc and 4ksd cpus. These cpu are mainly used in embedded system such as smartcard or point of sell devices as they provide some extra security features.

Please send patches inline.

I can see it inlined...what email viewer are you using ?

This patch adds support for both 4ksc and 4ksd cpus. These cpu are mainly used in embedded system such as smartcard or point of sell devices as they provide some extra security features.