Re: question in ldd.

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

 



On Fri, Oct 22, 2004 at 08:41:17AM +0200, Alessandro Rubini wrote:
> 
> Hello
Hello again,
> 
> > skull code of rubini's book --
> > http://www.xml.com/ldd/chapter/book/ch08.html#t4 -- usbsection
> > Probing for ISA Memory (listed at end of this mail) -- probe all ISA
> > memory range. It can reach:
> >
> > 1- Memory allocated. 
> > 2- RAM memory.
> > 3- empty memory.
> > (or 4-ROM yet, but i think we can ignore this fact here)
> 
> Yes.
>  
> > But i think one possibility is missing: if is there  a ISA hardware whose
> > driver wasn't loaded yet? Since the driver wasn't uploaded yet, code
> > does not reach a Memory allocated region.
> 
> Since the probing code accesses hardware directly, it doesn't matter
> whether the driver has been loaded or not. 
> 

hmm, ok, but if the module was loaded before running your book's code, 
the code will get (1) for that region (if the module did
request_mem_region()) . Let me try to be clearer: 

if we supress continue command in Memorry allocated statement, what 
should we get for an existing device? Does it look  like RAM or empty
space? (I did this test but i have no other ISA hardware than the one i
am looking for).

I have an old ISA device and its old driver code (for kernel 2.2). I am
trying to bring this code to kernels 2.4 and 2.6,  but i have no
documentation about the hardware other than code. The driver code used
direct access to 0xd2000 base physical address. Then I modified the code to
use address returned by ioremap() (something like 0xc00d2000)in readb 
and writeb, but I always get 0xff reading this region of memory,
whatever I write there (i.e., it looks like an empty region) and this is
not wanted (i think it should looks like an RAM region, although it is
not a RAM region). Then i am trying to probe (with your code) all ISA
mermory region, looking for an RAM like region, but I can reach a real
RAM region (or not?). Any idea?

Thanks,
-Riba


> > I think such region is nor a RAM region
> > neither an empty region (because there is a hardware there)...
> 
> The code only reports how the area looks like, by writing and reading
> back, so it either RAM-like (you read back what you write) or empty (you
> read rubbish whatever you write) or whatever. Irrespective of
> what drivers are doing.
> 
> Well, sure if device memory  appears differently after initialization,
> then there is some relationship between having loaded its driver and
> running skull, but it's not interesting here.
> 
> I used skull-like code to select a 64k area where to map memory
> of an ISA frame grabber card, for example. To this aim you only
> need to check how the memory area looks like, so select an empty slot.
> 
> Hope this helps
> /alessandro

--
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