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

[Wolfgang Denk]

In message <4839829C.9040000 at ruby.dti.ne.jp> you wrote:
> Wolfgang Denk wrote:
> > In message <48381B6C.5000901 at ruby.dti.ne.jp> you wrote:
> >> Adjust to the current Linux way.
> >>
> >> Signed-off-by: Shinya Kuribayashi <skuribay at 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?