Re: [patch] linux 2.4.5: Export mips_machtype

[Jun Sun <jsun@mvista.com>]

"Gleb O. Raiko" wrote:
> 
> "Maciej W. Rozycki" wrote:
> >  It sounds reasonable.  We may also check the Alpha port for solutions --
> > it supports multiple dissimilar systems as well.
> 
> Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at
> fixed location anyway.
> 
> In our case, almost every box has own location for kernel varying from
> 0x80000000 for brave people to 0x80100000 for people who doesn't care
> much about 1 MB :-). (Well, I clearly understand it's firmware
> requirements, not people's preferences. Almost.) Then, various binary
> formats of the kernel image...
> 
> I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP
> stuff.
> 
> However, I doubt whether we could support single kernel image for all
> MIPS boxes. MIPS is typical embedded platform, where standards are
> favourite because there are so many to choose from.
> 

No way to support all MIPS machines with a single kernel image - you have the
difference of BE and LE at least. :-)

Seriously, I found two cases where we do like to have one image supporting
multiple boards:

1) several CPU daughter boards plugging into one base baord - in the case we
really need to configure a kernel with multipe CPUs.

2) A reference design board is modified slightly and used in other products. 
- A typicaly change might be in interrupt routing, or some base address shift,
or removing some IOs.  In this case, we just need a slightly different board
setuo() function for each board.

I don't think it is fruitful trying to go to the extreme by having a single
image serving as many boxes as possible.

> BTW, I remember, Ralf tried to implement CPU type recognition at
> run-time, he dropped his efforts after he realized nobody could use this
> feature because boxes are so different.
>

CPU code is getting more crowded and uglier these days too, because more
vendors are adding their own CPUs.  Each CPU, in most cases, has its unique
hazards, which requires a separate low-level routines.  Even with the coming
MIPS32 and MIPS64 standard, we cannot count on vendors have totally conforming
CPUs.  I think it is about time to create a CPU abstraction which allows more
individualism.
 
Jun