Convert CPU type name into CONFIG_CPU_*
Adjust to the current Linux way.
---
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(-)
include/configs/dbau1x00.h +1 -1
@@ -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 */
include/configs/gth2.h +1 -1
@@ -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 */
include/configs/incaip.h +1 -1
@@ -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
include/configs/pb1x00.h +1 -1
@@ -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 */
include/configs/purple.h +1 -1
@@ -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 */
include/configs/qemu-mips.h +1 -1
@@ -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
include/configs/tb0229.h +1 -1
@@ -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
Quoted 3 lines · In message <[email protected]> you wrote:
Adjust to the current Linux way.
Signed-off-by Shinya Kuribayashi <[email protected]>
...
Review
Quoted 2 lines
(quoted diff) +1
-1-#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
Signature · 5 lines
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.
Quoted 11 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
Adjust to the current Linux way.
Signed-off-by Shinya Kuribayashi <[email protected]>...
Review
Quoted 2 lines
(quoted diff) +1
-1-#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.]
Quoted 2 lines
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
Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 10 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:
Adjust to the current Linux way.
Signed-off-by Shinya Kuribayashi <[email protected]>...
Review
Quoted 2 lines
(quoted diff) +1
-1-#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.
Quoted 4 lines
Quoted 1 line
We're adding a lot of fine ganularity here
First of all, current
CONFIG_MIPS32defines are useless. We can even remove them. What is fine granularity for, huh?
Why are these useless?
Quoted 1 line
[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?
Quoted 2 lines
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.
Quoted 2 lines
And why I use
CONFIG_CPU_MIPS32_R1, instead ofCONFIG_CPU_MIPS32, is due to avoiding #ifdef mess.CONFIG_CPU_MIPS32is 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?
Quoted 1 line
We need
_R1or_R2. Linux is doing well with the help ofKconfig.
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.
Quoted 4 lines
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
Signature · 4 lines
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?
Quoted 4 lines · Wolfgang Denk
Quoted 2 lines
First of all, current
CONFIG_MIPS32defines 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.
Quoted 4 lines
Quoted 1 line
[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.
Quoted 5 lines
Quoted 2 lines
And why I use
CONFIG_CPU_MIPS32_R1, instead ofCONFIG_CPU_MIPS32, is due to avoiding #ifdef mess.CONFIG_CPU_MIPS32is 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.
Quoted 2 lines
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.
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 5 lines
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.
Quoted 10 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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".
Quoted 7 lines
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.mkfiles, but then the term "_board_ config file" is wrong.
Sorry for confusion. I see all the aboves.
Quoted 5 lines
Quoted 2 lines
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