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