Documentation For mmap_device_memory()

This is an opinion of mine WRT the above mentioned documentation. I’m guessing
that since this function is suggested for replacement of mmap() with the
MAP_PHYS flag, that the “uint64_t physical” parameter is where the physical
address of the memory I’d like to map in is placed, as opposed to the “void
*addr” parameter. However I think it would be nice of you to at least mention
the field and what it’s used for, to remove any doubts as to whether or not
that’s really what goes there. Also no explicit mention is made of what should
go in the addr field if MAP_FIXED isn’t specified. I would assume NULL would
be the correct choice, but if it really doesn’t matter at all then that should
probably be noted.

Yes, these are very minor details, but I think in general they will make this
documentation easier for people to understand when they read it for the first
time.

TIA,
-Warren

Oh yeah, and there’s zero mention of any requisite page alignment for any
parameter. Also these lines: “There are two parts to the flags parameter. The
first part must be MAP_TYPE.” are what I would consider less than clear, as
MAP_TYPE is a mask value. Again I’ll assume that what was meant was MAP_ANON,
or MAP_SHARED, but one really shouldn’t have to read documentation for other
functions then guess what parameters are correct for the one they’re after. An
example would go a long way, of course…

-Warren “picky picky picky” Peece


“Warren Peece” <warren@nospam.com> wrote in message
news:903v0q$afo$1@inn.qnx.com
| This is an opinion of mine WRT the above mentioned documentation. I’m
guessing
| that since this function is suggested for replacement of mmap() with the
| MAP_PHYS flag, that the “uint64_t physical” parameter is where the physical
| address of the memory I’d like to map in is placed, as opposed to the “void
| *addr” parameter. However I think it would be nice of you to at least
mention
| the field and what it’s used for, to remove any doubts as to whether or not
| that’s really what goes there. Also no explicit mention is made of what
should
| go in the addr field if MAP_FIXED isn’t specified. I would assume NULL would
| be the correct choice, but if it really doesn’t matter at all then that
should
| probably be noted.
|
| Yes, these are very minor details, but I think in general they will make this
| documentation easier for people to understand when they read it for the first
| time.
|
| TIA,
| -Warren
|
|

What I’d like to know is if you’re using mmap_device_memory to map in some
physical memory under 16M (on the ISA bus) instead of mmap - is MAP_BELOW16M
set in the underlying (I’m presuming that mmap_device_memory is a wrapper)
mmap call?

“Jim Atkins” <jamesa@tsd.serco.com> wrote in message
news:9054ph$2uf$1@inn.qnx.com

What I’d like to know is if you’re using mmap_device_memory to map in some
physical memory under 16M (on the ISA bus) instead of mmap - is
MAP_BELOW16M
set in the underlying (I’m presuming that mmap_device_memory is a wrapper)
mmap call?

I’m going to guess it’s not automatically set. What if you were mapping
something on the PCI bus (there’s no way for the function to know where that
memory is located), it would be needlessly stuffed below 16M. If you need
it, I’d OR the sucker in there and be sure.

-Warren

Again there is no mention of that flag in the mmap_device_memory()
documentation - its only mentioned in mmap and thats where my question came
from. So you reckon I can OR it with the mmap_device_memory flags? That
kinda comes back around to me asking if mmap_device_memory() is a wrapper
for mmap().

Jim

p.s. heres another one: I’m going to need to create in memory hole in my ISA
space for some sram on an in-house card. Unfortunately my BIOS front end
doesn’t give me the option to do that but after diggin about in the CPU
cards chipset docs I’ve found that I can create a hole using chipset
registers. Fine. The thing is where is best to do this - IPL? Is so where
can I find the IPL source?

Ok - I’ve been having a bit of a sniff about the IPL and startup stuff - how
about adding a couple of lines in startup-bios or an equivalent to include
in my image buildfile?

Jim Atkins <jamesa@tsd.serco.com> wrote:

What I’d like to know is if you’re using mmap_device_memory to map in some
physical memory under 16M (on the ISA bus) instead of mmap - is MAP_BELOW16M
set in the underlying (I’m presuming that mmap_device_memory is a wrapper)
mmap call?

MAP_BELOW16M is used for allocating memory for DMA. You don’t
need it with mmap_device_memory().

The docs here are being improved. Meanwhile here is the source
for mmap_device_memory() (it’s in our Drivers course so I guess
I can give it here).

void *mmap_device_memory(void *addr, size_t len, int prot, int flags,
uint64_t physical) {
return mmap64(addr, len, prot, (flags & ~MAP_TYPE) | MAP_PHYS|MAP_SHARED,
NOFD, physical);
}

Here’s the snippet that is going into the docs:

ptr = mmap_device_memory( 0, len, PROT_READ|PROT_WRITE, 0, 0xb8000 );
if ( ptr == MAP_FAILED ) {
perror( “mmap_device_memory for physical address 0xb8000 failed” );
exit( EXIT_FAILURE );
}

Jim Atkins <jamesa@tsd.serco.com> wrote:

What I’d like to know is if you’re using mmap_device_memory to map in some
physical memory under 16M (on the ISA bus) instead of mmap - is MAP_BELOW16M
set in the underlying (I’m presuming that mmap_device_memory is a wrapper)
mmap call?

You only need MAP_BELOW16M if you’re using the mmap() call to allocate
DMA safe memory for ISA DMA on an x86 box. If you are accessing a
memory mapped card, it isn’t needed, and probably shouldn’t be passed.

-David

Jim Atkins <jamesa@tsd.serco.com> wrote:

Again there is no mention of that flag in the mmap_device_memory()
documentation - its only mentioned in mmap and thats where my question came
from. So you reckon I can OR it with the mmap_device_memory flags? That
kinda comes back around to me asking if mmap_device_memory() is a wrapper
for mmap().

Don’t use it there. As I said before, it is for specifying that when
you ALLOCATE memory for DMA, that the memory be allocated below the 16M
physical address mark. It doesn’t make sense for mmap_device_memory()
which is for accessing dual-ported RAM or similar on I/O cards.

p.s. heres another one: I’m going to need to create in memory hole in my ISA
space for some sram on an in-house card. Unfortunately my BIOS front end
doesn’t give me the option to do that but after diggin about in the CPU
cards chipset docs I’ve found that I can create a hole using chipset
registers. Fine. The thing is where is best to do this - IPL? Is so where
can I find the IPL source?

Under /usr/nto/src/nto/ipl/…

-David

Under /usr/nto/src/nto/ipl/…

Hmmm - can’t find this stuff under the RTP - although I have it on my
metrowerks flavour installation. I’ve had a look in the repositories (CD and
web) and can’t find them either. Is it not available for RTP yet?

So I’ve coped the structure from /startup down and tried to run make with no
joy. If I want to generate a new version of startup-bios with my tweaks in
(in /startup/boards/bios/main.c) - how do I build it ? - it looks like there
are loads of recursive makefiles and I don’t know where to kick it from
from…

Cheers

Jim

“Jim Atkins” <jamesa@tsd.serco.com> wrote in message
news:9080ni$q2u$1@inn.qnx.com

Under /usr/nto/src/nto/ipl/…

That’s part of the purchased Neutrino developer’s package (for x86, MIPS,
PPC). It’s not part of the free release.

Hmmm - can’t find this stuff under the RTP - although I have it on my
metrowerks flavour installation. I’ve had a look in the repositories (CD
and
web) and can’t find them either. Is it not available for RTP yet?

So I’ve coped the structure from /startup down and tried to run make with
no
joy. If I want to generate a new version of startup-bios with my tweaks in
(in /startup/boards/bios/main.c) - how do I build it ? - it looks like
there
are loads of recursive makefiles and I don’t know where to kick it from
from…

Cheers

Jim

I don’t know what’s provided under RtP for the startup BIOS code. Perhaps
I’ll take a look.

-Warren

Okay now I’m confused. I don’t find anything such as
/startup/boards/bios/main.c in my RtP installation. So you’ve got the
Metrowerks developer’s thingie as opposed to the QNX4 developers thingie?

I would think that since you’re not going to wrestle control of the reset
vector away from the BIOS, that you would indeed want to make your changes in
the startup module, in main.c. If you’re having trouble compiling it, I don’t
know what to tell you because I’ve got the QNX4 based package. With the QNX4
system, you would just make a new directory under the “startup/boards”
directory, something like “mybios”, and copy everything from boards/bios in
there (except maybe startup-bios). Then edit your changes, and from that
directory you should be able to just type “make” and it’ll deal with it,
producing startup-mybios in that directory.


“Jim Atkins” <jamesa@tsd.serco.com> wrote in message
news:9080ni$q2u$1@inn.qnx.com
|
| >
| >Under /usr/nto/src/nto/ipl/…
| >
|
|
| Hmmm - can’t find this stuff under the RTP - although I have it on my
| metrowerks flavour installation. I’ve had a look in the repositories (CD and
| web) and can’t find them either. Is it not available for RTP yet?
|
| So I’ve coped the structure from /startup down and tried to run make with no
| joy. If I want to generate a new version of startup-bios with my tweaks in
| (in /startup/boards/bios/main.c) - how do I build it ? - it looks like there
| are loads of recursive makefiles and I don’t know where to kick it from
| from…
|
| Cheers
|
| Jim
|
|

Warren Peece <warren@nospam.com> wrote:

Oh yeah, and there’s zero mention of any requisite page alignment for any
parameter. Also these lines: “There are two parts to the flags parameter. The
first part must be MAP_TYPE.” are what I would consider less than clear, as
MAP_TYPE is a mask value. Again I’ll assume that what was meant was MAP_ANON,
or MAP_SHARED, but one really shouldn’t have to read documentation for other
functions then guess what parameters are correct for the one they’re after. An
example would go a long way, of course…

-Warren “picky picky picky” Peece

Hey thanks for being “picky” – it only makes our documentation better.
Steven and I have reformatted the function pages, and our questions
(as a result of the reformatting exercise and this thread) have been
posted to development. Steven’s examples have also been added.

-Donna




“Warren Peece” <> warren@nospam.com> > wrote in message
news:903v0q$afo$> 1@inn.qnx.com> …
| This is an opinion of mine WRT the above mentioned documentation. I’m
guessing
| that since this function is suggested for replacement of mmap() with the
| MAP_PHYS flag, that the “uint64_t physical” parameter is where the physical
| address of the memory I’d like to map in is placed, as opposed to the “void
| *addr” parameter. However I think it would be nice of you to at least
mention
| the field and what it’s used for, to remove any doubts as to whether or not
| that’s really what goes there. Also no explicit mention is made of what
should
| go in the addr field if MAP_FIXED isn’t specified. I would assume NULL would
| be the correct choice, but if it really doesn’t matter at all then that
should
| probably be noted.
|
| Yes, these are very minor details, but I think in general they will make this
| documentation easier for people to understand when they read it for the first
| time.
|
| TIA,
| -Warren
|
|

Howdy.
Yep - Well its a long story so I won’t bore you with it but yes I started
using the Metrowerks thingy but it since Motorola took over Metrowerks
everything has ground to a halt and I’ve swapped over to using the RTP for
development (bought licences for it) as I have customers and timescales to
consider and RTP seems to be kept more up to date than the Metrowerks
flavour Neutrino installation I had.

Um - yes anyway - thats what I was confused about - none of the IPL/
startup code appears to be available under the RTP release or on the
repository. Luckily I still have the metrowerks flavour installation
(temporarily) so I’ve nabbed the directory tree from there.

I’m happy enough about where I want to make my changes but when I try to run
make from my directory ( I’ve done exactly what you said about doing - i.e.
copying /boards/bios/* ) it moans about : no route to target common.mk. I
think its just a path thing where I’ve copied the startup directory over
from my metrowerks installation which is fair enough but as you look up the
tree in /startup or /startup/boards there are also makefiles - I just wasn’t
sure which one to kick off to build the startup code… Unless someone has
had a go with this and knows which make to run then I’ll just have to have a
stab at it. From what you say it sounds like you just kick off make from the
bottom level (which just includes …/common.mk where common.mk includes
something else etcetc). I just hope that I (personally - not the PC) don’t
run out of stack space :slight_smile:

Ladida

Jim

Just to clarify, Jim, nothing is available under RtP (yet…) as far as the
Neutrino development package goes. Your choices are the QNX4 hosted
environment, and the semi-defunct CodeWarrior environment. I Doubt that the
CodeWarrior stuff will work if just copied over to RtP, and I know that the
QNX4 stuff won’t work as I tried it with the Startup directory. It won’t
even get past “qconfig.mk” for some reason beyond my curiosity/timeframe
window. Perhaps you can coerce the CodeWarrior stuff into playing nicely
under RtP, but if you’re in a hurry I suggest you install QNX 4.25 and
download the 2.11 Neutrino beta from QUICS. This will give you the most
recent stuff in an environment that works. You can then test under RtP and
do your actual application development under RtP (this is extraordinarily
handy for testing), however your IPL and Startup and F3S development will
still have to be under QNX4. Until an official RtP hosted release is made,
this appears to be the best solution.

-Warren


“Jim Atkins” <jamesa@tsd.serco.com> wrote in message
news:90fmsd$e62$1@inn.qnx.com

Howdy.
Yep - Well its a long story so I won’t bore you with it but yes I started
using the Metrowerks thingy but it since Motorola took over Metrowerks
everything has ground to a halt and I’ve swapped over to using the RTP for
development (bought licences for it) as I have customers and timescales to
consider and RTP seems to be kept more up to date than the Metrowerks
flavour Neutrino installation I had.

Um - yes anyway - thats what I was confused about - none of the IPL/
startup code appears to be available under the RTP release or on the
repository. Luckily I still have the metrowerks flavour installation
(temporarily) so I’ve nabbed the directory tree from there.

I’m happy enough about where I want to make my changes but when I try to
run
make from my directory ( I’ve done exactly what you said about doing -
i.e.
copying /boards/bios/* ) it moans about : no route to target common.mk. I
think its just a path thing where I’ve copied the startup directory over
from my metrowerks installation which is fair enough but as you look up
the
tree in /startup or /startup/boards there are also makefiles - I just
wasn’t
sure which one to kick off to build the startup code… Unless someone has
had a go with this and knows which make to run then I’ll just have to have
a
stab at it. From what you say it sounds like you just kick off make from
the
bottom level (which just includes …/common.mk where common.mk includes
something else etcetc). I just hope that I (personally - not the PC) don’t
run out of stack space > :slight_smile:

Ladida

Jim

Thanks Warren

I’ve got support looking at it right now. I’m sure we’ll come up with
something…

I think I’ll try another posting to stir things up from the RTP point of
view though (at least to try and get an idea of when this stuff may be
released).

Cheers

Jim