Very Computer

>     int memFile;

> >     int memFile;

> Don't use mixed case variable names.  The compiler might be confused
> thinking it's java or some other devilry.

> --
> M?ns Rullg?rd

>>     int memFile;

> Don't use mixed case variable names.  The compiler might be confused
> thinking it's java or some other devilry.

> I'm writing an user space device driver for an ISA device (for i386)
> that is visible at the physical address 0xd8000000 after writing to the
> proper I/O port, and writing a 1 to this address. Then I should see some
> values in the following memory. But I can't read nor write anything to
> it. So I have written two testing programs.

> First for DOS:

> void main(void)
> {
>     unsigned char far* mem = (unsigned char far*)0xd8000000UL;
>     int i;
>     outp(0x300, 0xc1); // reset board
>     outp(0x300, 0xc2); // stop reset, visible in memory
>     mem[0] = 1;
>     for(i = 0; i < 512; i++)
>         printf("%02x ", mem[i]);
> }

> which works quite well (also the complete driver works).

> Then for Linux:

> int main(void)
> {
>     int memFile;
>     volatile unsigned char* mem;

>     ioperm(0x300,1,1);
>     ioperm(0x80,1,1); // For the outb_p() command

>     outb_p(0xc1, 0x300);
>     outb_p(0xc2, 0x300);
>     memFile = open("/dev/mem", O_RDWR);
>     mem = (unsigned char*)mmap(NULL, 1024, PROT_READ|PROT_WRITE,
> MAP_SHARED, memFile, 0xd8000000);
>     // some error checking is here
>     mem[0] = 1;
>     for(i = 0; i < 512; i++)
>         printf("%02x ", mem[i]);
>     close(memFile);
> }

> This one only returns lots of FFs, meaning there is nothing. I'm pretty
> sure that the I/O-port  operations succeed, since LEDs on the device
> display that it should be visible in memory. I think he mmapping also
> works, I successfully mmapped parts of the BIOS, or the memory of a
> PCI-SCSI-controller, and something from 0 to 3MB (the kernel?). This was
> with kernel 2.2.20 on a Pentium 90. There I also tried kernel 2.0.35 or
> something.
> More things that I tried:

> the mmap()-sequence from vga.c in the svgalib source. It consists of
> mmapping /proc/self/mem and two other mmaps. The only difference was:
> instead of getting all zeros when reading from existent memory, I
> received an error when trying to mmap() /proc/self/mem.

> opening  /dev/mem and lseek to the right address to write() the one. But
> nothing changed in memory.

> One thing finally worked: I ran the DOS program, rebooted the system
> with Linux, and ran the Linux program without the reset sequnce. Then I
> could see some patterns. So reading seems to work.

> If nobody can help me, I will have to try to write a kernel module, that
> doesn't need interrupts and serves only one application. I've never
> written a driver module before, so this is going to make even more
> trouble (I guess).

> Thanks in advance
>     Fabian Herb

>     I'm guessing the ioperm()s might be the most suspect. There's a
> comment in the Linux version about some error checking but it doesn't
> say what was checked. The ioperm() will return a -1 on an error.
>     Does the error checking include the result of the open()?
>     Anything in /var/log/messages as a result of running the program?
>     Obvious thing: running as root?

> > int main(void)
> > {
> >     int memFile;
> >     volatile unsigned char* mem;

> >     ioperm(0x300,1,1);
> >     ioperm(0x80,1,1); // For the outb_p() command

> >     outb_p(0xc1, 0x300);
> >     outb_p(0xc2, 0x300);
> >     memFile = open("/dev/mem", O_RDWR);
> >     mem = (unsigned char*)mmap(NULL, 1024, PROT_READ|PROT_WRITE,
> > MAP_SHARED, memFile, 0xd8000000);
> >     // some error checking is here
> >     mem[0] = 1;
> >     for(i = 0; i < 512; i++)
> >         printf("%02x ", mem[i]);
> >     close(memFile);
> > }

> > >     int memFile;

> > Don't use mixed case variable names.  The compiler might be confused
> > thinking it's java or some other devilry.

> I've been using mixed case variable names, function names and whatever for
> years, and I never ever heard of a compiler that would wrongly assume code
> to be java or something just because of mixed case variable names, even
> under really weird circumstances (whatever that may be :-).