[Top] [All Lists]

Re: [patch] linux 2.4.5: Export mips_machtype

To: "Gleb O. Raiko" <>
Subject: Re: [patch] linux 2.4.5: Export mips_machtype
From: Jun Sun <>
Date: Fri, 24 Aug 2001 10:23:34 -0700
Cc: "Maciej W. Rozycki" <>,,
References: <> <>
"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

<Prev in Thread] Current Thread [Next in Thread>