[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Shinya Kuribayashi]

Adjust to the current Linux way.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
---

 include/configs/dbau1x00.h  |    2 +-
 include/configs/gth2.h      |    2 +-
 include/configs/incaip.h    |    2 +-
 include/configs/pb1x00.h    |    2 +-
 include/configs/purple.h    |    2 +-
 include/configs/qemu-mips.h |    2 +-
 include/configs/tb0229.h    |    2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)


diff --git a/include/configs/dbau1x00.h b/include/configs/dbau1x00.h
index b2f606f..ddb98ac 100644
--- a/include/configs/dbau1x00.h
+++ b/include/configs/dbau1x00.h
@@ -28,7 +28,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
+#define CONFIG_CPU_MIPS32_R1	1  /* MIPS32 CPU core	*/
 #define CONFIG_DBAU1X00		1
 #define CONFIG_AU1X00		1  /* alchemy series cpu */
 
diff --git a/include/configs/gth2.h b/include/configs/gth2.h
index c2a50c1..50487fa 100644
--- a/include/configs/gth2.h
+++ b/include/configs/gth2.h
@@ -28,7 +28,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
+#define CONFIG_CPU_MIPS32_R1	1  /* MIPS32 CPU core	*/
 #define CONFIG_GTH2		1
 #define CONFIG_AU1X00		1  /* alchemy series cpu */
 
diff --git a/include/configs/incaip.h b/include/configs/incaip.h
index 5ca00b3..430626d 100644
--- a/include/configs/incaip.h
+++ b/include/configs/incaip.h
@@ -28,7 +28,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1	/* MIPS 4Kc CPU core	*/
+#define CONFIG_CPU_MIPS32_R1	1	/* MIPS 4Kc CPU core	*/
 #define CONFIG_INCA_IP		1	/* on a INCA-IP Board	*/
 
 #ifndef	CPU_CLOCK_RATE
diff --git a/include/configs/pb1x00.h b/include/configs/pb1x00.h
index 810e0f0..899959a 100644
--- a/include/configs/pb1x00.h
+++ b/include/configs/pb1x00.h
@@ -28,7 +28,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
+#define CONFIG_CPU_MIPS32_R1	1  /* MIPS32 CPU core	*/
 #define CONFIG_PB1X00		1
 #define CONFIG_AU1X00		1  /* alchemy series cpu */
 
diff --git a/include/configs/purple.h b/include/configs/purple.h
index 1be4e05..f867efd 100644
--- a/include/configs/purple.h
+++ b/include/configs/purple.h
@@ -28,7 +28,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1	/* MIPS 5Kc CPU core	*/
+#define CONFIG_CPU_MIPS32_R1	1	/* MIPS 5Kc CPU core	*/
 #define CONFIG_PURPLE		1	/* on a PURPLE Board	*/
 
 #define CPU_CLOCK_RATE	125000000   /* 125 MHz clock for the MIPS core */
diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index d6bcc8e..98a07a6 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -28,7 +28,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1	/* MIPS32 CPU core */
+#define CONFIG_CPU_MIPS32_R1	1	/* MIPS32 CPU core */
 #define CONFIG_QEMU_MIPS	1
 #define CONFIG_MISC_INIT_R
 
diff --git a/include/configs/tb0229.h b/include/configs/tb0229.h
index dadf5d3..841f92d 100644
--- a/include/configs/tb0229.h
+++ b/include/configs/tb0229.h
@@ -25,7 +25,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1	/* MIPS 4Kc CPU core	*/
+#define CONFIG_CPU_VR41XX	1	/* MIPS VR4131 CPU core	*/
 #define CONFIG_TB0229		1	/* on a TB0229 Board	*/
 
 #ifndef CPU_CLOCK_RATE

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Wolfgang Denk]

In message <48381B6C.5000901@ruby.dti.ne.jp> you wrote:
> Adjust to the current Linux way.
> 
> Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
...
> -#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
> +#define CONFIG_CPU_MIPS32_R1	1  /* MIPS32 CPU core	*/

I have to admit that I don't like this changes.

We're adding a lot of fine ganularity here, and we pay for this with
added memory footprint - but I fail to see any significant benefits
from this.

What exactly is the reason for all these changes? Which problem are
you trying to fix?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What the gods would destroy they first submit to  an  IEEE  standards
committee.

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Shinya Kuribayashi]

Wolfgang Denk wrote:
> In message <48381B6C.5000901@ruby.dti.ne.jp> you wrote:
>> Adjust to the current Linux way.
>>
>> Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
> ...
>> -#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
>> +#define CONFIG_CPU_MIPS32_R1	1  /* MIPS32 CPU core	*/
> 
> I have to admit that I don't like this changes.
> 
> We're adding a lot of fine ganularity here

First of all, current CONFIG_MIPS32 defines are useless. We can even
remove them. What is fine granularity for, huh?

skuribay at debian:~/devel/u-boot.git$ grep -r CONFIG_MIPS32 .
./include/configs/qemu-mips.h:#define CONFIG_MIPS32             1       /* MIPS32 CPU core */
./include/configs/dbau1x00.h:#define CONFIG_MIPS32              1  /* MIPS32 CPU core   */
./include/configs/gth2.h:#define CONFIG_MIPS32          1  /* MIPS32 CPU core   */
./include/configs/purple.h:#define CONFIG_MIPS32                1       /* MIPS 5Kc CPU core    */
./include/configs/tb0229.h:#define CONFIG_MIPS32                1       /* MIPS 4Kc CPU core    */
./include/configs/pb1x00.h:#define CONFIG_MIPS32                1  /* MIPS32 CPU core   */
./include/configs/incaip.h:#define CONFIG_MIPS32                1       /* MIPS 4Kc CPU core    */
skuribay at debian:~/devel/u-boot.git$ 

[btw tb0229 is not MIPS32 at all. it's VR4131 based machine.]

> What exactly is the reason for all these changes? Which problem are
> you trying to fix?

It'll be good we could have CPU type specifier so that we can utilize as
a compiler/assembler optimization.

And why I use CONFIG_CPU_MIPS32_R1, instead of CONFIG_CPU_MIPS32, is due
to avoiding #ifdef mess. CONFIG_CPU_MIPS32 is inadequate for this use.
We need _R1 or _R2. Linux is doing well with the help of Kconfig.

Probably I should have fold this patch and `[MIPS] CPU-dependent
compiler/assembler options for optimization' patch into one.

Thought?


 Shinya

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Wolfgang Denk]

In message <4839829C.9040000@ruby.dti.ne.jp> you wrote:
> Wolfgang Denk wrote:
> > In message <48381B6C.5000901@ruby.dti.ne.jp> you wrote:
> >> Adjust to the current Linux way.
> >>
> >> Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
> > ...
> >> -#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
> >> +#define CONFIG_CPU_MIPS32_R1	1  /* MIPS32 CPU core	*/
> > 
> > I have to admit that I don't like this changes.
> > 
> > We're adding a lot of fine ganularity here
> 
> First of all, current CONFIG_MIPS32 defines are useless. We can even
> remove them. What is fine granularity for, huh?

Why are these useless?

> [btw tb0229 is not MIPS32 at all. it's VR4131 based machine.]

Please excuse my ignorance - but I thought the VR4131 was a 32 bit
MIPS based processor. Is this understanding incorrect?

> It'll be good we could have CPU type specifier so that we can utilize as
> a compiler/assembler optimization.

Hm.. if this is the opnly purpose, that I'd rather see  this  in  the
board specific config.mk files instead of the board config file.

> And why I use CONFIG_CPU_MIPS32_R1, instead of CONFIG_CPU_MIPS32, is due
> to avoiding #ifdef mess. CONFIG_CPU_MIPS32 is inadequate for this use.

Where is such #ifdef mess supposed to happen? Do you refer to existing
code, or anything you are going to add?

> We need _R1 or _R2. Linux is doing well with the help of Kconfig.

The Linux kernel has quite a list  of  different  requirements.  It's
targeted  for  high abstraction layers, images that can run on sevral
different boards, etc. We pay a price for this, for example in  terms
of  memory footprint, both for the Linux kernel image and for the RAM
memory footprint. This is even OK for an operating system.

U-Boot has other priorities. Please re-read
http://www.denx.de/wiki/UBoot/DesignPrinciples  and
http://www.denx.de/wiki/UBoot/DesignRequirements  to make sure we have
the same understanding.

> Probably I should have fold this patch and `[MIPS] CPU-dependent
> compiler/assembler options for optimization' patch into one.
> 
> Thought?

Well, yes - if it's for compiler/assembler options only, then the
board config file is not the correct place for this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How can you tell when sour cream goes bad?

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Shinya Kuribayashi]

Wolfgang Denk wrote:
>> First of all, current CONFIG_MIPS32 defines are useless. We can even
>> remove them. What is fine granularity for, huh?
> 
> Why are these useless?

There is no user of this config, we can even remove these all.

>> [btw tb0229 is not MIPS32 at all. it's VR4131 based machine.]
> 
> Please excuse my ignorance - but I thought the VR4131 was a 32 bit
> MIPS based processor. Is this understanding incorrect?

All VR41XX processors are 32/64-bit capable. In this case it just runs
in 32-bit mode. What's important is that VR41XX is MIPS III ISA [1].

And in cases where saying MIPS32, it usually means MIPS32 ISA. It's
MIPS32(R) Arhchitecture [2].

[1] http://www.linux-mips.org/wiki/NEC_VR4100
[2] http://www.mips.com/products/processors/architectures/mips32/

See also
[3] http://www.linux-mips.org/wiki/Instruction_Set_Architecture

The binaries compiled for MIPS32 might work on VR41XX machines (I'm not
sure. usually we don't do that.), but that's not my point.

>> And why I use CONFIG_CPU_MIPS32_R1, instead of CONFIG_CPU_MIPS32, is due
>> to avoiding #ifdef mess. CONFIG_CPU_MIPS32 is inadequate for this use.
> 
> Where is such #ifdef mess supposed to happen? Do you refer to existing
> code, or anything you are going to add?

The latter.

> Well, yes - if it's for compiler/assembler options only, then the
> board config file is not the correct place for this.

I don't think so because 1) CPU type is not board-dependent, and 2) the
board config file is not board-specific file, but system config file.
CPU type is reasonably one of system configuration, IMO.

And these CPU type specifiers are not only used for compiler/assembler
optimization, but also is useful when categorizing processor specific
routines. For example, Linux is doing like this:

[arch/mips/mm/Makefile]
  obj-$(CONFIG_CPU_MIPS32) += c-r4k.o cex-gen.o tlb-r4k.o
  obj-$(CONFIG_CPU_TX39XX) += c-tx39.o tlb-r3k.o

In accordance with above, we can do like this:

[cpu/mips/Makefile]
  SOBJS-$(CONFIG_CPU_MIPS32) += cache-mips32.o
  SOBJS-$(CONFIG_CPU_VR41XX) += cache-vr41xx.o

Unfortunately current cache routines doesn't work for all NEC VR-series
processors at all. I'll fix in the future.

At last I have to mention about CPU type specifiers. These specifiers
are neigher MIPS Processor ID (PRId) nor gcc -march option alternatives.
These are virtual options designed for organizing various MIPS options,
routines, and object selections of Makefile. They're defined in Kconfig.

I think these are exactly good granularity, and like to see them in
U-Boot system configuration, too.


  Shinya

P.S. I decided to defer this patch due to some reason. That's another
     story and will inform the list later.

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Wolfgang Denk]

In message <4840E304.7090702@ruby.dti.ne.jp> you wrote:
>
> > Well, yes - if it's for compiler/assembler options only, then the
> > board config file is not the correct place for this.
> 
> I don't think so because 1) CPU type is not board-dependent, and 2) the
> board config file is not board-specific file, but system config file.
> CPU type is reasonably one of system configuration, IMO.

I cannot follow you here. Especially I have no idea what you mean by
"system config file".

To make sure we use the same terms: THe "board config file" is the
board specific header file "include/configs/<boardname>.h". This file
is definitely NOT the correct place to tweak compiler and/or assembler
options (not to mention that I don't see how this would be done).

I _guess_ you might be referring to the cpu/*/config.mk files, but
then the term "_board_ config file" is wrong.

> P.S. I decided to defer this patch due to some reason. That's another
>      story and will inform the list later.

Since I haven't heard again about this I assume this is for the next
merge window (or even later). Is this assumption correct, or should
this still go into the current release?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Dear Lord: I just want *one* one-armed manager so  I  never  have  to
hear "On the other hand", again.

[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*

[Shinya Kuribayashi]

Wolfgang Denk wrote:
> In message <4840E304.7090702@ruby.dti.ne.jp> you wrote:
>>> Well, yes - if it's for compiler/assembler options only, then the
>>> board config file is not the correct place for this.
>> I don't think so because 1) CPU type is not board-dependent, and 2) the
>> board config file is not board-specific file, but system config file.
>> CPU type is reasonably one of system configuration, IMO.
> 
> I cannot follow you here. Especially I have no idea what you mean by
> "system config file".
> 
> To make sure we use the same terms: THe "board config file" is the
> board specific header file "include/configs/<boardname>.h". This file
> is definitely NOT the correct place to tweak compiler and/or assembler
> options (not to mention that I don't see how this would be done).
> 
> I _guess_ you might be referring to the cpu/*/config.mk files, but
> then the term "_board_ config file" is wrong.

Sorry for confusion. I see all the aboves.

>> P.S. I decided to defer this patch due to some reason. That's another
>>      story and will inform the list later.
> 
> Since I haven't heard again about this I assume this is for the next
> merge window (or even later). Is this assumption correct,

Correct.


  Shinya