gary

All

Kinda new at this but I am having an issue with mmap.


In an application I want to use mmap and use "/dev/mem" to do the same
thing. In using mmap I pass in the physical address I used in hw_init.
I do get a valid vm address back but it does not seem to be pointing
at the same location of the flash as the first 32 bytes are incorrect.

If I open the driver directly "/dev/am29lv256m.0" and print out the
first 32 byts of the file it is correct.

What am I missing?

Gary

seibert@seibertland.spambites.org (greg

Well, I don't know if they've added /dev/mem file mapping to LynxOS,
but I did a special case where you could shm_open("/dev/mem",...)
and get what you're looking for with mmap().

I know file mapping was in the works when I left. It's been a while
though.

Just make sure it's the physical address not PHYSBASE +.
--
-
--Greg

kno

Gary,

the first LynxOS release supporting mapping of "/dev/mem" was 3.1.0. To
obtain the file handle, it doesn't matter if you use open() or
shm_open() .

Then, you should use the true processor-physical address as the
"offset" argument with mmap(). Greg is quite right: do not use PHYSBASE
addressing (which is a kernel-level linear mapping of the system RAM).

CAVEAT: When applying lseek() to "/dev/mem" the offsets refer to
virtual addresses while the mmap() offsets refer to true physical
addresses. Funny!

Ludwig Knoblauch
Sysgo Real-Time Solutions AG.

gary

All

Ok, really confused now.. here is hw_iobase_map output for the flash ..

ea: BFC00000 RPN: FC000000 ERPN: 00000001

The regs map the flash at FC0 for the ibm440gx
EBC0_B0CR = 0xFC0DE000
EBC0_B0AP = 0x04D01440

When the flash registers in kernel space it is using the BFC00000
address. I can increment that in the flash_install and
see the data is matching what I have flashed.

For the mmap call how can I use for the offset 0x1 FC00 0000 when in
the user app the most I can get is 0xFC00 0000 ?
Isnt 0x1 FC000000 the true processor address ? The user app is using
32bits ?

Example I am using..

strcpy((char*)data,"/dev/mem");
offset = 0xFC000000; /* FPGA phy address .. how do we get the 0x1
ERPN value in this address 0x1 FC00 0000 */

fd = open((char*)data,O_RDWR);

if (!fd)
{
printf("failed to open dev mem\n");
return 0;
}
pa = mmap(0x0, 32, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);

if (pa < 0)
{
printf("Failed mmap\n");
return 0;
}

printf("Physical addr 0x%08X\n",offset);
printf("Virtual addr 0x%08X \n",pa);
memLoc = (char*)pa;

printf("Value of location 0x");
for(x=0; x < 32; x++)
{
printf("%02X ",*memLoc);
memLoc++;
}
printf("\n");


munmap(addr,count);

close(fd);

printf("FPGA Test done!\n");


Gary

steve@watt.com (steve

Well, not quite. LynxOS 2.4 had a "/dev/mem" shared memory segment that
you could pass to mmap(). I think Greg actually wrote that code for a
UK telecom company, and we included it in the POSIX.1b stuff in 2.4.


Yep. Using open()/lseek()/read()/write() on /dev/mem gets you (at least
until 3.1.0, which is the last version I worked on) what everyone else
calls /dev/kmem. If you want something that's addressible via PHYSBASE,
you can do it that way.

Using shm_open()/mmap() on /dev/mem gets you physical memory access.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...

steve@watt.com (steve

Hmm. OK, that's a bit of data you hadn't shared, so let's ask:
Processor? LynxOS version?

I'll guess the processor is a 440GX, based on your comment, and I'll
assume LynxOS is something newer than 3.1.0a, which is the last version
that I directly contributed code to.


I believe off_t is 64 bits wide; that was done somewhere around 3.0.1.

The user app should be using off_t for file pointers, which is most
likely a long long.


off_t offset = 0x1FC000000ULL;


You might also try shm_open("/dev/mem", O_RDWR, 0);

The value you are looking for is MAP_FAILED, by the way. pa could be
negative, in a twos-complement sense, but still be a valid pointer.

Minor nit: If you've declared pa to be a void * (like mmap returns),
you won't need the cast.

If you don't need the performance of direct pointer access, you can
also do this via seek_n_read/seek_n_write (err, old names...) and use
the kernel effective address (0xbfc00000).

Steve
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...

gary

for the

off_t offset = 0x1FC000000ULL;

the compiler give a warning about overflow in implicit constant
conversion.

and still same invalid data..


Gary WB0OMR

gary

sys/types.h

defines off_t as a long that blows the 0x1FC000000ULL usage :-(

Gary WB0OMR

kno

Sorry, this seems to be really bad. I didn't realize that the device
has got a 64 bit hardware address. Up to the LynxOS releases known to
me (4.0.0) neither lseek() nor mmap() do support "long long" offset
types. Also, with LynxOS I don't know about extra long long versions of
these functions (like llseek() with Linux).

Obviously, your device is currently installed to a 64 bit address, so
mmap() cannot reach it. As Steve pointed out, you could access the
device through read() and write() by using the kernel-virtual address
0xbfc00000 for offset with lseek().

If direct access is important, you should talk to hardware folks and/or
to somebody being familiar with the deeper LynxOS kernel layers (DRM).
Maybe the device could
be installed to a 32-bit address which then would be accessible to
mmap().

Eventually, if the hardware address cannot be made 32-bit then a
non-standard mapping procedure could be added to a kernel-level driver.

to the driver. We used to go this way in desperate situations ...
requires a bit know-how about kernel internals.

Ludwig Knoblauch
Sysgo Real-Time Solutions AG.

gary

Hmmm, well for the Flash I can open the /dev/flash_driver and access
the data that way. I'll have to see if the ramdisk will work for it.

The really major issue is the PCI memory. We want to communicate with
a DSP via that. We are coming from vxWorks where we
could directly access that area but now this 64 bit address seems to
put a stop to that.

Any suggestions?

Gary