public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_*
Date: Sat, 31 May 2008 14:32:52 +0900	[thread overview]
Message-ID: <4840E304.7090702@ruby.dti.ne.jp> (raw)
In-Reply-To: <20080525153554.0C0B52402D@gemini.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.

  reply	other threads:[~2008-05-31  5:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-24 13:43 [U-Boot-Users] [MIPS] Convert CPU type name into CONFIG_CPU_* Shinya Kuribayashi
2008-05-24 20:09 ` Wolfgang Denk
2008-05-25 15:15   ` Shinya Kuribayashi
2008-05-25 15:35     ` Wolfgang Denk
2008-05-31  5:32       ` Shinya Kuribayashi [this message]
2008-07-05 22:32         ` Wolfgang Denk
2008-07-06  3:17           ` Shinya Kuribayashi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4840E304.7090702@ruby.dti.ne.jp \
    --to=skuribay@ruby.dti.ne.jp \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox