I have Neutrino running on a PC 104 based system. There’s dual-port memory at physical addresses 0x120 - 0x128 and I’ve used mmap to map that space into my process. I think the hardware is correctly accessing that physical memory but my code does not see any changes in the mapped copy of the memory. I’m reasonably certain that my code works because I changed the offset and length in the mmap() call to point to video RAM and that allowed me to write all over the screen by referencing the address space returned from mmap().
Perhaps I need to do something different when accessing dual-port memory? I dunno. Am I correct in assuming that Neutrino keeps the mapped memory refreshed so I can read/write it in real time?
try to use PROT_NOCACHE flag in mmap function.
Description from help:
PROT_NOCACHE – disable caching of the region (e.g. so it can be used to access dual-ported memory).
Address 0x120-0x128 doesn’t sound like memory address range but rather a IO address range. Try using in/out instruction to access these ports instead. Don’t use mmap but mmap_device_io instead.
Usage of in/out function requires the proper privilige which must by setup with call to ThreadCtl() (check documentation).
No, it’s definitely RAM space. The system is PC 104 based, not a traditional Personal Computer and we are using dual-port RAM instead of I/O ports.
The I/O card maps to address 120 through jumper settings.
If it says I/O card that usually mean it’s IO based not memory based.
I find this very hard hard to beleive for the following reason. 120-128 gives you an 8 byte window, that means to access the dual ram (unless there is only 8 byte of dual ram) you need to control some sort of hardware windows or deal with some sort of protocol to get access to the data. That’s common with PC hardware on ISA (because of the lack of avaiable adress range) and that’s usually done through IO not memory.
PC/104 is just a form factor, it is a PC and behaves just like a standard PC. both logical and electricaly. The PC/104 connector is an ISA bus (with a couple of extra line for power).
Expect conflict because at that address range there’s real RAM. RAM that the BIOS may use and that QNX WILL use. If that is the case you need to tell Proc not to use that address range.
So I implented the port read logic: inb(0x120), etc., (I don’t have the code in front of me or I’d post it) and when the process executed it just hung up on the inb(). I could Ctrl-C out of it but otherwise it just sat there , perhaps blocked on the port operation, I wildly speculate?
I know I called the function give myself permission to access the port and function to map the port into my address space before I called inb(). I ran the process as root. It just hangs.
Hmm… The only way I can see that happening is at the hardware level - inb() is not a blocking call. It is acting like the you are blocked on bus contention or something.
I would look into the hardware setup for the board you have and see if you have it set up right.
Bus contention that freezes a single instruction would freeze the whole cpu so that’s not your problem. I would be looking for non-terminating loops in your code.