From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Date: Sat, 31 May 2008 14:32:52 +0900
Subject: [U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*
In-Reply-To: <20080525153554.0C0B52402D@gemini.denx.de>
References: <20080525153554.0C0B52402D@gemini.denx.de>
Message-ID: <4840E304.7090702@ruby.dti.ne.jp>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.