lkml.org 
[lkml]   [1999]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Perform minimal RAM test at boot
On Tue, 2 Nov 1999, Jamie Lokier wrote:

> Richard B. Johnson wrote:
> > o The case of memory-mapped devices:
> > It's RAM. Until it is allocated for a driver it can be used
> > for RAM. It may be slow RAM, but it's RAM.
>
> Not "memory-mapped devices" in general: the accesses have side effects.
> But for things like framebuffers you are right.
>
> > o Scattered writes/reads, i.e., a page appart should go
> > to the physical RAM. I have never seen it do differently.
>
> This depends on the number of "ways" of the cache, and how it is mapped.
> E.g. in most if not all x86s, accesses a page appart do map to the same
> cache line address, so there is potential for one access to flush the
> cached contents of another. However, as there are 2 or more ways (4 on
> P5MMX for example), the cache can hold data for several lines at the
> same line address, and the flush is not guaranteed.
>
> AFAIK you cannot rely on this for any kind of write-allocating cache
> unless you know the structure of the cache.
>
> The behaviour of writes depends on the cache's write policy. Most
> modern x86 processors use write-allocate unless told otherwise, which
> means that even isolated writes will cause the entire cache line to be
> read in and then modified locally.
>
> On processors that do write-back, your read-modify-write instruction
> causes the line to be read in anyway at first, and then modified
> locally.
>
> It is only write-through caches such as the 486s (I think; my memory is
> not strong on this), where the writes will always go outside the
> memory. The read test later still fetches from the local cache though.
>
> To finish, the L2 cache is often a write-back/write-allocate cache even
> if the processor cache is not. So still physical memory is not tested.
>
> > If it didn't, you would not be able to use memory-mapped
> > I/O because the CPU would read its cache instead of physical
> > RAM.
>
> Memory-mapped I/O works because:
>
> - ioremap() maps the memory and marks the pages uncacheable.
> E.g. on an x86, the PCD (page cache disable) bit is set.
>
> - For some processors, the CPU bus protocols allow the processor to
> be informed of memory locations it should not cache.
>
> This does not help with memory detection though, because a specific
> address range may be hardwired as "memory -- cache permitted", and
> the physical memory may be a subrange of that.
>

Don't lose sight of the fact that you are only trying to find the extent
of physical RAM. And you are trying to do this before you set up your
page tables. ioremap() is very much after the fact. Note that, as I
explained, you must set DS to point to a data selector that does
1:1 flat addressing with no limit, and marked present. You can set the
base address to 1 megabyte if you want to exclude the usual ROMs and the
screen regen buffer, etc.

At one time I was concerned about cache-effects so I wrote a unique word
to every possible page in RAM (4GB), then attempted to read them all back.
The problem is that many/most/all? PCs don't properly decode 4GB so I was
trashing code and stack. The solution was to do as stated. Just ignore the
cache. It works. If you were to read/write every byte/word/whatever in
memory sequentially, it would not work. Only the cache data would be
modified and you would subsequentally read from the cache. Just try it.

Another thing to consider is that offsets in ix86-land are signed!
Using [EBX] will address 4GB, but [buffer + EBX] will not. If EBX =
0xffffffff, (-1) it points to 1 byte below 'buffer'. This is something
to remember if you are trying to write 'cute' code. This is also something
to remember if you are relying on 'C' to compute the address. I strongly
suggest you find the RAM in assembly, not 'C'.


Cheers,
Dick Johnson

Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.042 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site