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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users