[U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*
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
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
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@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@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
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
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.
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
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
participants (2)
-
Shinya Kuribayashi -
Wolfgang Denk