Re: Query related with Book Linux Device Drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux