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/
