http://mail.nl.linux.org/kernelnewbies/2004-10/msg00089.html
> Memory Barrier. It enforced in-order execution of
> memory accesses
> either side of this function call - so you guarantee
> everything got
> done that you asked for. Intel people don't (I
> think, but I don't do
> Intel stuff very often) generally have to worry
> about this even on the
> latest cores because any instruction re-ordering is
> transparent to the
> programmer. On RISC based machines such as Sparc
> International (Sun)
> SPARC, AIM PowerPC, IBM POWER, and so on, we have to
> handle the fact
> that memory accesses may be re-ordered by both the
> compiler and/or the
> micro itself in order to streamline the processor
> instruction
> pipeline.
>
Thanks a lot for explaining this and for your
guidance.
> You'll have to provide a reference to the C source
> file where you saw
> these functions. Looks like a test to see what kind
> of memory is at a
> certain address - if you write data to a memory
> location then it will
> change unless it is ROM, but if it is then it will
> return the same
> value every time that you read it. If there is
> nothing at a particular
> address then you will read only random data
> according to whatever
> electical state the memory bus is in - apparently
> sometimes you can
> actually read a valid value back if your memory bus
> has some capacitve
> issue where it acts like a register itself (but
> that's rarely a
> problem these days - it is however enough for me/us
> to take special
> measures in our memory test routines at work).
>
The source code refers to the examples which comes
along Linux Device Drivers Book [ I downloaded from
site ] and file is skull_init.c.
if ((oldval^newval) == 0xff) { /* we re-read our
change: it's ram */
printk(KERN_INFO "%lx: RAM\n", add);
continue;
}
if ((oldval^newval) != 0) { /* random bits
changed:it's empty */
printk(KERN_INFO "%lx: empty\n", add);
continue;
}
I am getting what your are trying to say. As far as
ROM is concerned, we can never write on ROM, so how
can we detect that memory is a part of ROM.
unsigned char oldval, newval; /* values read from
memory */
unsigned long flags; /* used to hold system
flags */
unsigned long add, i;
void *base;
/* Use ioremap to get a handle on our region */
base = ioremap(ISA_REGION_BEGIN, ISA_REGION_END -
ISA_REGION_BEGIN);
base -= ISA_REGION_BEGIN; /* Do the offset once
*/
/* probe all the memory hole in 2KB steps */
for (add = ISA_REGION_BEGIN; add < ISA_REGION_END;
add += STEP) {
/*
* Check for an already allocated region.
*/
if (check_mem_region (add, 2048)) {
printk(KERN_INFO "%lx: Allocated\n", add);
continue;
}
/*
* Read and write the beginning of the region and see
what happens.
*/
save_flags(flags);
cli();
oldval = readb (base + add); /* Read a byte */
writeb (oldval^0xff, base + add);
mb();
newval = readb (base + add);
writeb (oldval, base + add);
restore_flags(flags);
if ((oldval^newval) == 0xff) { /* we re-read our
change: it's ram */
printk(KERN_INFO "%lx: RAM\n", add);
continue;
}
if ((oldval^newval) != 0) { /* random bits changed:
it's empty */
printk(KERN_INFO "%lx: empty\n", add);
continue;
}
}
I got the point, that If the old value and new value
are same, then oldval ^ newval will be epmty and hence
it is RAM.
if ((oldval^newval) == 0xff) { /* we re-read our
change: it's ram */
printk(KERN_INFO "%lx: RAM\n", add);
continue;
}
And if oldval ^ newval is not empty, then the random
bit has changed and hence it is epmty [ which has been
explained by you ].
if ((oldval^newval) != 0) { /* random bits changed:
it's empty */
printk(KERN_INFO "%lx: empty\n", add);
continue;
}
Jon, could you please suggest me a book on assembly
language as that will help me to play with bits and
bytes .
Regards
Dinesh
