CONFIG_MIPS_UNCACHED

CONFIG_MIPS_UNCACHED

[Quinn Jensen]

Ralf,

On some machines with weird firmware (e.g. IDT 334 board)
the processor comes up with the cache already enabled for
kseg0.  In this case, the set_cp0_config() call in mips32.c
to turn off the cache (gated by CONFIG_MIPS_UNCACHED) should
probably come after the first call to flush_cache_all(),
which is safer but still not totally safe, I suppose.
Or am I totally hosed trying to turn the kseg0 cache off
after it was once on?

Quinn Jensen

Re: CONFIG_MIPS_UNCACHED

[Pete Popov]

Quinn Jensen wrote:
> 
> Ralf,
> 
> On some machines with weird firmware (e.g. IDT 334 board)
> the processor comes up with the cache already enabled for
> kseg0.  In this case, the set_cp0_config() call in mips32.c
> to turn off the cache (gated by CONFIG_MIPS_UNCACHED) should
> probably come after the first call to flush_cache_all(),
> which is safer but still not totally safe, I suppose.
> Or am I totally hosed trying to turn the kseg0 cache off
> after it was once on?

That's an issue not only when you're "turning off" the cache, but
whenever you muck with the kseg0 cache coherency attribute.  The Galileo
EV96100, running Galileo's pmon, comes up with kseg0 set to 3, which is
the default linux kseg0 cache coherency attribute. However, calling
set_cp0_config() without first flushing the cache destroys some data,
eventhough the same exact kseg0 attribute is set. 

I think a complete cache flush is in order before calling
set_cp0_config() and that's a change we should make for all cpus.

Pete

Re: CONFIG_MIPS_UNCACHED

[Jun Sun]

Pete Popov wrote:
> 
> Quinn Jensen wrote:
> >
> > Ralf,
> >
> > On some machines with weird firmware (e.g. IDT 334 board)
> > the processor comes up with the cache already enabled for
> > kseg0.  In this case, the set_cp0_config() call in mips32.c
> > to turn off the cache (gated by CONFIG_MIPS_UNCACHED) should
> > probably come after the first call to flush_cache_all(),
> > which is safer but still not totally safe, I suppose.
> > Or am I totally hosed trying to turn the kseg0 cache off
> > after it was once on?
> 
> That's an issue not only when you're "turning off" the cache, but
> whenever you muck with the kseg0 cache coherency attribute.  The Galileo
> EV96100, running Galileo's pmon, comes up with kseg0 set to 3, which is
> the default linux kseg0 cache coherency attribute. However, calling
> set_cp0_config() without first flushing the cache destroys some data,
> eventhough the same exact kseg0 attribute is set.
>

It is really surprising to know this.  It sounds like a CPU bug to me.  Can
some MIPS "gods" clarify if such a behaviour is a bug or allowed?

BTW, the CPU in EV96100 is QED RM7000, I believe.

Jun

Re: CONFIG_MIPS_UNCACHED

[Ralf Baechle]

On Wed, Jan 24, 2001 at 12:10:32PM -0800, Jun Sun wrote:

> It is really surprising to know this.  It sounds like a CPU bug to me.  Can
> some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> 
> BTW, the CPU in EV96100 is QED RM7000, I believe.

If you want to be strictly correct you have to execute the code that
disables caching of KSEG0 in uncached space like KSEG1, then flush the
caches before you can resume execution in KSEG0.  Otherwise you might
end up with dirty d-caches which when flushed will overwrite more
uptodate data in memory.  The window is very small but yet exists if
things are just right.

  Ralf

Re: CONFIG_MIPS_UNCACHED

[Pete Popov]

Ralf Baechle wrote:
> 
> On Wed, Jan 24, 2001 at 12:10:32PM -0800, Jun Sun wrote:
> 
> > It is really surprising to know this.  It sounds like a CPU bug to me.  Can
> > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> >
> > BTW, the CPU in EV96100 is QED RM7000, I believe.
> 
> If you want to be strictly correct you have to execute the code that
> disables caching of KSEG0 in uncached space like KSEG1, then flush the
> caches before you can resume execution in KSEG0.  Otherwise you might
> end up with dirty d-caches which when flushed will overwrite more
> uptodate data in memory.  The window is very small but yet exists if
> things are just right.

The EV96100 running Galileo's pmon exhibits exactly this symptom.  Pmon
apparently sets up kseg0 to cache coherency 3;  but eventhough the
kernel also sets it to 3, if I don't flush the caches first I end up
with overwritten data.  A different version of pmon that I have sets
kseg0 to 1 (writethrough). Changing that to 3 isn't a problem -- or at
least it doesn't seem to cause any problems.

Pete

Re: CONFIG_MIPS_UNCACHED

[Jun Sun]

Pete Popov wrote:
> 
> Ralf Baechle wrote:
> >
> > On Wed, Jan 24, 2001 at 12:10:32PM -0800, Jun Sun wrote:
> >
> > > It is really surprising to know this.  It sounds like a CPU bug to me.  Can
> > > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> > >
> > > BTW, the CPU in EV96100 is QED RM7000, I believe.
> >
> > If you want to be strictly correct you have to execute the code that
> > disables caching of KSEG0 in uncached space like KSEG1, then flush the
> > caches before you can resume execution in KSEG0.  Otherwise you might
> > end up with dirty d-caches which when flushed will overwrite more
> > uptodate data in memory.  The window is very small but yet exists if
> > things are just right.
> 
> The EV96100 running Galileo's pmon exhibits exactly this symptom.  Pmon
> apparently sets up kseg0 to cache coherency 3;  but eventhough the
> kernel also sets it to 3, if I don't flush the caches first I end up
> with overwritten data.  A different version of pmon that I have sets
> kseg0 to 1 (writethrough). Changing that to 3 isn't a problem -- or at
> least it doesn't seem to cause any problems.
> 

I don't think it is the same problem.

Here is the simplified view of the process, if I understand Pete correctly:

1. pmon sets kseg0 to 3 (cache enabled)
2. kernel starts in KSEG0 
3. kernel sets kseg0 to 3 again (essentially keeps the same config value)
4. kernel flushes cache
  ===> Q: data corruption or not?

I think the data should be consistent.  Otherwise it looks like a CPU bug to
me.

What ralf described is something like the following:

1. pmon sets kseg0 to 3 (KSEG0 cache enabled)
2. kernel starts in KSEG0 
3. kernel sets kseg0 to 2 (disable kseg0 cache)
4. kernel flushes cache
  ===> Q: data corruption or not?  YES, data can be corrupted!

Jun

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

>
> > It is really surprising to know this.  It sounds like a CPU bug to me.
Can
> > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> >
> > BTW, the CPU in EV96100 is QED RM7000, I believe.
>
> If you want to be strictly correct you have to execute the code that
> disables caching of KSEG0 in uncached space like KSEG1, then flush the
> caches before you can resume execution in KSEG0.  Otherwise you might
> end up with dirty d-caches which when flushed will overwrite more
> uptodate data in memory.  The window is very small but yet exists if
> things are just right.

That's one possible failure mode.   The other is that there
are dirty lines (those that were brought into the cache and
modified by stores, but never written back to memory) that
are rendered invisible by forcing KSEG0 to go uncached.
This will cause failure of any code that is expecting to see
the results of those stores if said code executes before
some other event causes the write-back - and if the
machine is running with cacheing completely disabled,
as it would be in the case under discussion, such an
event may never occur!

            Regards,

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

>
> > It is really surprising to know this.  It sounds like a CPU bug to me.
Can
> > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> >
> > BTW, the CPU in EV96100 is QED RM7000, I believe.
>
> If you want to be strictly correct you have to execute the code that
> disables caching of KSEG0 in uncached space like KSEG1, then flush the
> caches before you can resume execution in KSEG0.  Otherwise you might
> end up with dirty d-caches which when flushed will overwrite more
> uptodate data in memory.  The window is very small but yet exists if
> things are just right.

That's one possible failure mode.   The other is that there
are dirty lines (those that were brought into the cache and
modified by stores, but never written back to memory) that
are rendered invisible by forcing KSEG0 to go uncached.
This will cause failure of any code that is expecting to see
the results of those stores if said code executes before
some other event causes the write-back - and if the
machine is running with cacheing completely disabled,
as it would be in the case under discussion, such an
event may never occur!

            Regards,

            Kevin K.

CONFIG_MIPS_UNCACHED

[Jun Sun]

I looked at the code and it appears this config may not work properly.

My understanding is that if CPU has been running with cache enabled, and,
presummably, have many dirty cache entries, and if you suddenly change config
register to run kernel uncached, you *don't* get all the dirty cache lines
flushed into memory.  Therefore, you will be accessing stale data in memory.

Is this right?  If so, we need a better way to run CPU uncached.

In the past, I have been a private patch to do so.  It seems pretty difficult
to come up a generic, because we want to figure out the CPU type and disable
cache *before* kernel starts to modify any memory content.

BTW, this comes to me as I observe some weired behavior when I try to run
uncached.

Jun

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> I looked at the code and it appears this config may not work properly.
>
> My understanding is that if CPU has been running with cache enabled, and,
> presummably, have many dirty cache entries, and if you suddenly change
config
> register to run kernel uncached, you *don't* get all the dirty cache lines
> flushed into memory.  Therefore, you will be accessing stale data in
memory.
>
> Is this right?  If so, we need a better way to run CPU uncached.
>
> In the past, I have been a private patch to do so.  It seems pretty
difficult
> to come up a generic, because we want to figure out the CPU type and
disable
> cache *before* kernel starts to modify any memory content.

Since the kernel cache attribute is never initialized before
ld_mmu_{whatever} is invoked, and since that Config field
does not have a well-defined reset state on many MIPS
CPUs, it would appear that we are in effect trusting the
bootloader to have done something reasonable like
set kseg0 to be non-cachable or write-through, either
of which would be safe for the current code.  Strictly
speaking, if we do not wish to assume that the bootloader
has corectly initialized the caches, the kernel should begin
execution in kseg1and stay there until the caches have
been initialized and the kseg0 cache attribute has been
set to something sane.  And when I say "initialized", I
don't mean the writeback-invalidates used by the
blast_dcache routines, since those assume a sane
state of the tag ram, which cannot be guaranteed
at power-up.  One should write the tags directly to
a sane value on CPUs that support it  (on the R3000,
one apparently needs to write a byte to each cache
line to invalidate it.).

I would suggest either that we be explicit about the
assumptions about what the bootloader has done
to the cache, or we go whole-hog and assume that
the kernel has been branched to directly from the
reset vector.  Tinkering with measures in between
strikes me as a waste of time.

            Regards,

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> I looked at the code and it appears this config may not work properly.
>
> My understanding is that if CPU has been running with cache enabled, and,
> presummably, have many dirty cache entries, and if you suddenly change
config
> register to run kernel uncached, you *don't* get all the dirty cache lines
> flushed into memory.  Therefore, you will be accessing stale data in
memory.
>
> Is this right?  If so, we need a better way to run CPU uncached.
>
> In the past, I have been a private patch to do so.  It seems pretty
difficult
> to come up a generic, because we want to figure out the CPU type and
disable
> cache *before* kernel starts to modify any memory content.

Since the kernel cache attribute is never initialized before
ld_mmu_{whatever} is invoked, and since that Config field
does not have a well-defined reset state on many MIPS
CPUs, it would appear that we are in effect trusting the
bootloader to have done something reasonable like
set kseg0 to be non-cachable or write-through, either
of which would be safe for the current code.  Strictly
speaking, if we do not wish to assume that the bootloader
has corectly initialized the caches, the kernel should begin
execution in kseg1and stay there until the caches have
been initialized and the kseg0 cache attribute has been
set to something sane.  And when I say "initialized", I
don't mean the writeback-invalidates used by the
blast_dcache routines, since those assume a sane
state of the tag ram, which cannot be guaranteed
at power-up.  One should write the tags directly to
a sane value on CPUs that support it  (on the R3000,
one apparently needs to write a byte to each cache
line to invalidate it.).

I would suggest either that we be explicit about the
assumptions about what the bootloader has done
to the cache, or we go whole-hog and assume that
the kernel has been branched to directly from the
reset vector.  Tinkering with measures in between
strikes me as a waste of time.

            Regards,

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Jun Sun]

"Kevin D. Kissell" wrote:
> 
> > I looked at the code and it appears this config may not work properly.
> >
> > My understanding is that if CPU has been running with cache enabled, and,
> > presummably, have many dirty cache entries, and if you suddenly change
> config
> > register to run kernel uncached, you *don't* get all the dirty cache lines
> > flushed into memory.  Therefore, you will be accessing stale data in
> memory.
> >
> > Is this right?  If so, we need a better way to run CPU uncached.
> >
> > In the past, I have been a private patch to do so.  It seems pretty
> difficult
> > to come up a generic, because we want to figure out the CPU type and
> disable
> > cache *before* kernel starts to modify any memory content.
> 
> Since the kernel cache attribute is never initialized before
> ld_mmu_{whatever} is invoked, and since that Config field
> does not have a well-defined reset state on many MIPS
> CPUs, it would appear that we are in effect trusting the
> bootloader to have done something reasonable like
> set kseg0 to be non-cachable or write-through, either
> of which would be safe for the current code. 

I think you just proposed a fix: check current config register when we turn
off cache.  Thanks. :-)

Jun

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> > Since the kernel cache attribute is never initialized before
> > ld_mmu_{whatever} is invoked, and since that Config field
> > does not have a well-defined reset state on many MIPS
> > CPUs, it would appear that we are in effect trusting the
> > bootloader to have done something reasonable like
> > set kseg0 to be non-cachable or write-through, either
> > of which would be safe for the current code.
>
> I think you just proposed a fix: check current config register when we
turn
> off cache.  Thanks. :-)

That's a heuristic at best.  If the config register comes up random,
it can appear to be sane even though the cache is in fact uninitialized.

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> > Since the kernel cache attribute is never initialized before
> > ld_mmu_{whatever} is invoked, and since that Config field
> > does not have a well-defined reset state on many MIPS
> > CPUs, it would appear that we are in effect trusting the
> > bootloader to have done something reasonable like
> > set kseg0 to be non-cachable or write-through, either
> > of which would be safe for the current code.
>
> I think you just proposed a fix: check current config register when we
turn
> off cache.  Thanks. :-)

That's a heuristic at best.  If the config register comes up random,
it can appear to be sane even though the cache is in fact uninitialized.

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Jun Sun]

On Sat, Jun 23, 2001 at 10:15:49PM +0200, Kevin D. Kissell wrote:
> > > Since the kernel cache attribute is never initialized before
> > > ld_mmu_{whatever} is invoked, and since that Config field
> > > does not have a well-defined reset state on many MIPS
> > > CPUs, it would appear that we are in effect trusting the
> > > bootloader to have done something reasonable like
> > > set kseg0 to be non-cachable or write-through, either
> > > of which would be safe for the current code.
> >
> > I think you just proposed a fix: check current config register when we
> turn
> > off cache.  Thanks. :-)
> 
> That's a heuristic at best.  If the config register comes up random,
> it can appear to be sane even though the cache is in fact uninitialized.
> 

For any practical reasons, we can assume there is a loader for Linux,
and we can assume loader does not run with a random config register.

Jun

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> > > > Since the kernel cache attribute is never initialized before
> > > > ld_mmu_{whatever} is invoked, and since that Config field
> > > > does not have a well-defined reset state on many MIPS
> > > > CPUs, it would appear that we are in effect trusting the
> > > > bootloader to have done something reasonable like
> > > > set kseg0 to be non-cachable or write-through, either
> > > > of which would be safe for the current code.
> > >
> > > I think you just proposed a fix: check current config register
> > > when we turn off cache.  Thanks. :-)
> >
> > That's a heuristic at best.  If the config register comes up random,
> > it can appear to be sane even though the cache is in fact uninitialized.
> >
>
> For any practical reasons, we can assume there is a loader for Linux,
> and we can assume loader does not run with a random config register.

That's a position that would sound reasonable to someone working
on Linux for legacy DEC/SGI systems, but not one that I would
expect to satisfy someone working on embedded Linux.  It would
need to be governed by a config option, but I would think
that ultimately we need to have a Linux that can be ROMed
and branched to directly from the reset vector.  Why force
everyone doing an embedded MIPS/Linux widget to re-invent
the wheel?

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> > > > Since the kernel cache attribute is never initialized before
> > > > ld_mmu_{whatever} is invoked, and since that Config field
> > > > does not have a well-defined reset state on many MIPS
> > > > CPUs, it would appear that we are in effect trusting the
> > > > bootloader to have done something reasonable like
> > > > set kseg0 to be non-cachable or write-through, either
> > > > of which would be safe for the current code.
> > >
> > > I think you just proposed a fix: check current config register
> > > when we turn off cache.  Thanks. :-)
> >
> > That's a heuristic at best.  If the config register comes up random,
> > it can appear to be sane even though the cache is in fact uninitialized.
> >
>
> For any practical reasons, we can assume there is a loader for Linux,
> and we can assume loader does not run with a random config register.

That's a position that would sound reasonable to someone working
on Linux for legacy DEC/SGI systems, but not one that I would
expect to satisfy someone working on embedded Linux.  It would
need to be governed by a config option, but I would think
that ultimately we need to have a Linux that can be ROMed
and branched to directly from the reset vector.  Why force
everyone doing an embedded MIPS/Linux widget to re-invent
the wheel?

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Maciej W. Rozycki]

On Sat, 23 Jun 2001, Jun Sun wrote:

> I think you just proposed a fix: check current config register when we turn
> off cache.  Thanks. :-)

 Note that many MIPS CPUs do not have the config register that could be
used to turn the cache off.  That's not a problem for the userland as it's
controlled on a page-by-page basis, but the kernel runs unmapped (except
from modules) and user vs kernel memory coherency problems arise.  I have
a patch that makes the kernel run in the KSEG1 space (which is uncached by
default even on processors that have the config register).  It needs a
minor clean-up for exception handlers, though, as they start in KSEG0 with
no possibility to override.  So they should jump to KSEG1 ASAP --
hopefully two icache lines are OK; if cache in non-functional then we are
screwed as using bootstrap exception vectors is not an option, usually.
Cacheability of KSEG0 may be further disabled if possible. 

 I'll send the patch soon, when I clean it up.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CONFIG_MIPS_UNCACHED

[Jun Sun]

"Kevin D. Kissell" wrote:
> 
> > > > > Since the kernel cache attribute is never initialized before
> > > > > ld_mmu_{whatever} is invoked, and since that Config field
> > > > > does not have a well-defined reset state on many MIPS
> > > > > CPUs, it would appear that we are in effect trusting the
> > > > > bootloader to have done something reasonable like
> > > > > set kseg0 to be non-cachable or write-through, either
> > > > > of which would be safe for the current code.
> > > >
> > > > I think you just proposed a fix: check current config register
> > > > when we turn off cache.  Thanks. :-)
> > >
> > > That's a heuristic at best.  If the config register comes up random,
> > > it can appear to be sane even though the cache is in fact uninitialized.
> > >
> >
> > For any practical reasons, we can assume there is a loader for Linux,
> > and we can assume loader does not run with a random config register.
> 
> That's a position that would sound reasonable to someone working
> on Linux for legacy DEC/SGI systems, but not one that I would
> expect to satisfy someone working on embedded Linux.  It would
> need to be governed by a config option, but I would think
> that ultimately we need to have a Linux that can be ROMed
> and branched to directly from the reset vector.  Why force
> everyone doing an embedded MIPS/Linux widget to re-invent
> the wheel?
> 

The currenct common practice in embedded world is:

1. during development stage, using a loader to download kernel to target.

2. during productization stage, use a separate rom loader to cold-start the
board and load the kernel from flash to RAM, assuming the kernel is on flash.

There are a couple of other vairants, but generally you do have a first stage
loader that will set up the environment right for Linux kernel.

Cold-starting a board and loading a kernel is highly board and system
specific.  Does not seem to make sense to get included in the kernel
structure.

Jun

Re: CONFIG_MIPS_UNCACHED

[Justin Carlson]

On Sun, 24 Jun 2001, you wrote:

> That's a position that would sound reasonable to someone working
> on Linux for legacy DEC/SGI systems, but not one that I would
> expect to satisfy someone working on embedded Linux.  It would
> need to be governed by a config option, but I would think
> that ultimately we need to have a Linux that can be ROMed
> and branched to directly from the reset vector.  Why force
> everyone doing an embedded MIPS/Linux widget to re-invent
> the wheel?

Because there are very good reasons for having a firmware seperate from
the OS.  Otherwise, you're more or less proposing a new run-time-environment
that has to do all the hardware sanitizations and initializations before we
get to the bootstrap environment.  That's going to be so system-specific and
disparate from the kernel that it doesn't, IMHO, make any sense to put it
there.  This is especially true since *not* having it in the kernel gives you
the chance to exploit the same firmware environment for non-linux OS'es. 

-Justin

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> > That's a position that would sound reasonable to someone working
> > on Linux for legacy DEC/SGI systems, but not one that I would
> > expect to satisfy someone working on embedded Linux.  It would
> > need to be governed by a config option, but I would think
> > that ultimately we need to have a Linux that can be ROMed
> > and branched to directly from the reset vector.  Why force
> > everyone doing an embedded MIPS/Linux widget to re-invent
> > the wheel?
>
> Because there are very good reasons for having a firmware seperate from
> the OS.

Yes, and there are also very good reasons for minimizing
the size and functionality of that bootloader.  One could have
a minimalist but functional MIPS bootloader that runs in kseg1
and hasn't the faintest idea what a cache is.  As I said in
an earlier message on this thread, we should either be explicit
about what we assume the bootloader will have done for us, or
prepare to have the relevant CPU/cache intitialization done
by the kernel.

> Otherwise, you're more or less proposing a new run-time-environment
> that has to do all the hardware sanitizations and initializations before
we
> get to the bootstrap environment. That's going to be so system-specific
and
> disparate from the kernel that it doesn't, IMHO, make any sense to put it
> there.

Cache tag initialization is CPU-specific, not system specific.

>              This is especially true since *not* having it in the kernel
gives you
> the chance to exploit the same firmware environment for non-linux OS'es.

The systems I'm worried about don't *have* any non-Linux OSes.
I do not advocate unconditionally putting proper cache initialization
code into every MIPS/Linux kernel!  I wouldn't dream of preventing
some one else from putting their full faith in the perfectly understood
and well-documented bootloaders on their Indy or DECstation. ;-)
And people who have otherwise found it to be a reasonable design
trade off to build a cache-aware bootloader should not have to pay
the time or footprint to initialize the cache twice.

But so long as there are people who want to build new, specialized devices
running embedded Linux, it is in their interest that the MIPS/Linux kernel
distribution provide them with as much of the generic processor startup
functionality as possible, so that they can concentrate their energies
on making their products different and better instead of re-re-implementing
cache initialization code (and maybe getting it wrong).

But in any case, have no fear, I'm unlikely to be submitting
any such patch any time soon!

            Regards,

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Kevin D. Kissell]

> > That's a position that would sound reasonable to someone working
> > on Linux for legacy DEC/SGI systems, but not one that I would
> > expect to satisfy someone working on embedded Linux.  It would
> > need to be governed by a config option, but I would think
> > that ultimately we need to have a Linux that can be ROMed
> > and branched to directly from the reset vector.  Why force
> > everyone doing an embedded MIPS/Linux widget to re-invent
> > the wheel?
>
> Because there are very good reasons for having a firmware seperate from
> the OS.

Yes, and there are also very good reasons for minimizing
the size and functionality of that bootloader.  One could have
a minimalist but functional MIPS bootloader that runs in kseg1
and hasn't the faintest idea what a cache is.  As I said in
an earlier message on this thread, we should either be explicit
about what we assume the bootloader will have done for us, or
prepare to have the relevant CPU/cache intitialization done
by the kernel.

> Otherwise, you're more or less proposing a new run-time-environment
> that has to do all the hardware sanitizations and initializations before
we
> get to the bootstrap environment. That's going to be so system-specific
and
> disparate from the kernel that it doesn't, IMHO, make any sense to put it
> there.

Cache tag initialization is CPU-specific, not system specific.

>              This is especially true since *not* having it in the kernel
gives you
> the chance to exploit the same firmware environment for non-linux OS'es.

The systems I'm worried about don't *have* any non-Linux OSes.
I do not advocate unconditionally putting proper cache initialization
code into every MIPS/Linux kernel!  I wouldn't dream of preventing
some one else from putting their full faith in the perfectly understood
and well-documented bootloaders on their Indy or DECstation. ;-)
And people who have otherwise found it to be a reasonable design
trade off to build a cache-aware bootloader should not have to pay
the time or footprint to initialize the cache twice.

But so long as there are people who want to build new, specialized devices
running embedded Linux, it is in their interest that the MIPS/Linux kernel
distribution provide them with as much of the generic processor startup
functionality as possible, so that they can concentrate their energies
on making their products different and better instead of re-re-implementing
cache initialization code (and maybe getting it wrong).

But in any case, have no fear, I'm unlikely to be submitting
any such patch any time soon!

            Regards,

            Kevin K.

Re: CONFIG_MIPS_UNCACHED

[Maciej W. Rozycki]

On Tue, 26 Jun 2001, Kevin D. Kissell wrote:

> code into every MIPS/Linux kernel!  I wouldn't dream of preventing
> some one else from putting their full faith in the perfectly understood
> and well-documented bootloaders on their Indy or DECstation. ;-)

 With functions like malloc(), strlen(), strcpy(), printf(), getenv(),
etc. I wouldn't name the DECstation's firmware (the REX one) just a
bootloader.  It's more like a minimal libc with additional functionality
to interface to hw, it's very well documented indeed (as opposed to most
of DECstations' hw, sigh...) and it appears to present a kernel an
interface that conforms to published docs.

 Of course, I don't expect anyone to put a libc into their embedded
system's ROM.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +