Access PCI memory space from DOS real mode
William Zhang
For some reason, my original post did not show up in this newsgroup.
I am posting again.
Hi All,
I am working on an DOS network driver for a PCI Express NIC device.
The device does not have I/O space but only memory bar. The issue is
my driver is running under 16 bit real mode and how can the driver
access 32 bit PCI memory space. I was doing some searching including
this newsgroup and got several different possible solutions like
switching to protected mode or big real mode for different situation
like PCI Option ROM, BIOS code.
But as driver running under DOS system, which mode is the way to go
without possibly messing up the DOS OS? There are DOS/BIOS interrupt,
all kind of other device drivers, TSR and other extended memory stuff.
Can the mode switching cause any problem to OS?
I am fairly new to this system level programming, if anybody know if
there is any code for the mode switching/restoring, please also let
me know. Thanks a lot!
Regards,
William
Rod Pemberton
"William Zhang" <esp...@MUNGED.microcosmotalk.com> wrote in message
news:4af1f845$0$5669$9a6e...@unlimited.newshosting.com...
>
> I am working on an DOS network driver for a PCI Express NIC device.
> The device does not have I/O space but only memory bar. The issue is
> my driver is running under 16 bit real mode and how can the driver
> access 32 bit PCI memory space. I was doing some searching including
> this newsgroup
... this newsgroup ... ?
> and got several different possible solutions like
> switching to protected mode or big real mode for different situation
> like PCI Option ROM, BIOS code.
>
> But as driver running under DOS system, which mode is the way to go
> without possibly messing up the DOS OS?
Either will (or should) work. "Big real mode", aka "unreal mode", requires
a switch to protected mode to setup. But, once you've done so, you
shouldn't need to enter protected mode again. This method is undocumented
but commonly used. Various examples exist on the Internet. Put the
following, or something similar, into Yahoo (or Google):
+"unreal mode" +cr0
If necessary, I can attempt to locate links for you. But, I think that
should pull up a few code examples. Also, alt.os.development might be of
use, once you've got some code to switch modes. A number of regulars have
written code for their own OSes to switch modes.
> without possibly messing up the DOS OS?
This question might be answered better on comp.os.msdos.programmer.
If your driver isn't using DOS and you aren't randomly modifying memory
below 1MB, I believe you should be fine. If you're using memory below 1MB
not within your driver, make sure you use DOS memory calls to allocate this
memory. If your driver is using DOS calls (like memory), you'll need to do
all that DOS reentrancy stuff - InDOS flag (clear), Critical Error flag
(clear), and int 28h (DOS IDLE is called), or saving/restoring entire DOS
SDA (Swappable Data Area) context with undocumented int 21h, ax=5d06h or
ax=5d0b calls depending on DOS version. You might want to review the Ralf
Brown interrupt list (RBIL), for more information and post to
comp.os.msdos.programmer.
There are a few places to find RBIL in different formats:
http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html
http://www.ctyme.com/rbrown.htm
http://www.delorie.com/djgpp/doc/rbinter/
> Can the mode switching cause any problem to OS?
I don't think so, but I don't know for sure. You probably want to locate an
author of a DOS DPMI host. The DPMI host does the real mode to protected
mode switching (and back) for DPMI applications in DOS. DPMI hosts probably
do more mode switching than any other code. Charles Sandmann, who wrote one
of DJGPP's DPMI hosts, posts to comp.msdos.djggp, occasionally. You might
also try posting to openwatcom.users.c_cpp. IIRC, two DPMI authors post
there: Charles Devore of the Causeway DPMI host and Japheth author of HDPMI.
Posting to openwatcom.users.c_cpp can be a problem. It's recommend that you
connect directly to their server instead of posting through other NNTP
services. e.g., enter this NNTP link into your browser:
news://news.openwatcom.org
HTH,
Rod Pemberton
Rod Pemberton
"William Zhang" <esp...@MUNGED.microcosmotalk.com> wrote in message
news:4af1f845$0$5669$9a6e...@unlimited.newshosting.com...
>
This is an (out of order) correction to my previous post to Zhang:
> ... comp.msdos.djggp ...
comp.os.msdos.djgpp
Sorry,
Rod Pemberton
William Zhang
Thanks Rod for your detail reply. I'll try to locate some sample code
for mode switching and see how it goes.
On Nov 4, 5:51=A0pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "William Zhang" <esp...@MUNGED.microcosmotalk.com> wrote in message
>
> news:4af1f845$0$5669$9a6e...@unlimited.newshosting.com...
>
>
>
> > I am working on an DOS network driver for a PCI Express NIC device.
> > The device does not have I/O space but only memory bar. =A0The issue is
> > my driver is running under 16 bit real mode and how can the driver
> > access 32 bit PCI memory space. =A0 I was doing some searching includin=
g
> > this newsgroup
>
> ... this newsgroup ... ?
>
> > and =A0got several different possible solutions like
> > switching to protected mode or big real mode for different situation
> > like PCI Option ROM, BIOS code.
>
> > But as driver running under DOS system, =A0which mode is the way to go
> > without possibly messing up the DOS OS?
>
> Either will (or should) work. =A0"Big real mode", aka "unreal mode", requ=
ires
> a switch to protected mode to setup. =A0But, once you've done so, you
> shouldn't need to enter protected mode again. =A0This method is undocumen=
ted
> but commonly used. =A0Various examples exist on the Internet. =A0Put the
> following, or something similar, into Yahoo (or Google):
>
> +"unreal mode" +cr0
>
> If necessary, I can attempt to locate links for you. =A0But, I think that
> should pull up a few code examples. =A0Also, alt.os.development might be =
of
> use, once you've got some code to switch modes. =A0A number of regulars h=
ave
> written code for their own OSes to switch modes.
>
> > without possibly messing up the DOS OS?
>
> This question might be answered better on comp.os.msdos.programmer.
>
> If your driver isn't using DOS and you aren't randomly modifying memory
> below 1MB, I believe you should be fine. =A0If you're using memory below =
1MB
> not within your driver, make sure you use DOS memory calls to allocate th=
is
> memory. =A0If your driver is using DOS calls (like memory), you'll need t=
o do
> all that DOS reentrancy stuff - InDOS flag (clear), Critical Error flag
> (clear), and int 28h (DOS IDLE is called), or saving/restoring entire DOS
> SDA (Swappable Data Area) context with undocumented int 21h, ax=3D5d06h o=
r
> ax=3D5d0b calls depending on DOS version. =A0You might want to review the=
Ralf
> Brown interrupt list (RBIL), for more information and post to
> comp.os.msdos.programmer.
>
> There are a few places to find RBIL in different formats:
>
> http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.htmlhttp://www.ctyme=
.com/rbrown.htmhttp://www.delorie.com/djgpp/doc/rbinter/
>
> > Can the mode switching cause any problem to OS?
>
> I don't think so, but I don't know for sure. =A0You probably want to loca=
te an
> author of a DOS DPMI host. =A0The DPMI host does the real mode to protect=
ed
> mode switching (and back) for DPMI applications in DOS. =A0DPMI hosts pro=
bably
> do more mode switching than any other code. =A0Charles Sandmann, who wrot=
e one
> of DJGPP's DPMI hosts, posts to comp.msdos.djggp, occasionally. =A0You mi=
ght
> also try posting to openwatcom.users.c_cpp. =A0IIRC, two DPMI authors pos=
t
> there: Charles Devore of the Causeway DPMI host and Japheth author of HDP=
MI.
> Posting to openwatcom.users.c_cpp can be a problem. =A0It's recommend tha=
t you
> connect directly to their server instead of posting through other NNTP
> services. =A0e.g., enter this NNTP link into your browser:
Michael Tippach
William Zhang wrote:
> I am working on an DOS network driver for a PCI Express NIC device.
> The device does not have I/O space but only memory bar.
In that case you are SOL.
Forget about all the suggestions regarding flat real mode, etc. that are
likely to be made! This is a complete waste of time, for whatever you
will come up with will fall apart in one or the other customer setup -
V86 with no VCPI/DPMI, etc.
Get your hardware designer to retrofit an additional I/O BAR! If
politics, etc. does not permit you to do that, base your driver on the
NIC PXE code (use UNDI for that) and then complain that their (not your)
stuff falls apart once e.g. EMM386 is loaded. This way you'll get your
I/O BAR.
wolfgang kern
Michael Tippach suggested:
> William Zhang wrote:
Perhaps a good advice as long you find enough space in the 64KB I/O-range.
Looking at my current hardware, I got several Megabyte memory mapped I/O.
__
wolfgang
Robert Redelmeier
wolfgang kern <now...@never.at> wrote in part:
I don't know about PCIe, but I thought PCI _had_ to have
a standard config port in IO space for enumeration, etc.
It has been awhile, but I remember accessing PCI command / data
ports without any trouble from MS-DOS (but there was a trick lock
that a 32 bit access prefix was required with the high bit on ) .
I would expect a high-performance ethercard to do busmastering (DMA)
and _not_ have visible local memory. Just set the packet address
in IO space, then the etherchip drops/lifts the data from there.
Zero-copy.
-- Robert
wolfgang kern
Robert Redelmeier wrote:
...
>>> Get your hardware designer to retrofit an additional I/O BAR! If
>>> politics, etc. does not permit you to do that, base your driver on the
>>> NIC PXE code (use UNDI for that) and then complain that their (not your)
>>> stuff falls apart once e.g. EMM386 is loaded. This way you'll get your
>>> I/O BAR.
>> Perhaps a good advice as long you find enough space in the 64KB
I/O-range.
>> Looking at my current hardware, I got several Megabyte memory mapped I/O.
> I don't know about PCIe, but I thought PCI _had_ to have
> a standard config port in IO space for enumeration, etc.
> It has been awhile, but I remember accessing PCI command / data
> ports without any trouble from MS-DOS (but there was a trick lock
> that a 32 bit access prefix was required with the high bit on ) .
Yes, the PCI-config is an I/O port index/data-pair, and it is still
this way (set bit31 to access config-space), but not many PCI-devices
can be driven by just write to CMD/DATA in the config-field.
> I would expect a high-performance ethercard to do busmastering (DMA)
> and _not_ have visible local memory. Just set the packet address
> in IO space, then the etherchip drops/lifts the data from there.
> Zero-copy.
I didn't mean the buffers in the above MegaBytes, just all my
implemented USB-hostcontrollers take more than 100 KB, even only
256 byte/HC were used for registers, it seems they need to be at
least 4KB apart.
Latest graphic-controllers got already 64KB and more registerspace
and 'a few' index/data pairs in addition.
__
wolfgang
Tim Roberts
Robert Redelmeier <red...@ev1.net.invalid> wrote:
>
>I don't know about PCIe, but I thought PCI _had_ to have
>a standard config port in IO space for enumeration, etc.
The root controller does, but individual PCI cards do not.
>It has been awhile, but I remember accessing PCI command / data
>ports without any trouble from MS-DOS (but there was a trick lock
>that a 32 bit access prefix was required with the high bit on ) .
Sure, if you can get them mapped. If you have DPMI available, this is not
hard. If not, well, then it's hard...
>I would expect a high-performance ethercard to do busmastering (DMA)
>and _not_ have visible local memory. Just set the packet address
>in IO space, then the etherchip drops/lifts the data from there.
High-performance devices of any kind never use I/O ports. It takes a
microsecond or more to do a single I/O port cycle on PCI. In your example,
you set the packet addresses in a small memory space, then trigger DMA.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
da...@nowhere.net
Your memory is wrong. The bus controller has accessible ports to read
and write the PCI/PCI-X/PCIe configuration space. There are NO
requirements that one of those devices have registers accessible via
'in' or 'out'. I know our chips are accessible via memory mapped I/O
only except for the configuration and extended configuration space.
On 07 Nov 2009 19:06:46 GMT, Robert Redelmeier
William Zhang
HI Michael,
This was exactly my feeling about this project. I understand it is OK
to flip around real mode, flat mode before the OS boots because either
the BIOS code or PXE code(in network device case) is running alone.
But as for DOS driver, there are so many other things like you
mentioned are running at the same time so it is likely to cause
problem. I would really appreciate it if you could provide some
links or theory that show this mode switching will fail for a driver
under DOS so I can show it to the hardware people. Thanks a lot!
William
On Nov 6, 4:57=A0pm, Michael Tippach <mich...@MUNGED.microcosmotalk.com>
wrote:
Michael Tippach
William Zhang wrote:
> I would really appreciate it if you could provide some
> links or theory that show this mode switching will fail for a driver
> under DOS so I can show it to the hardware people. Thanks a lot!
Ask them if they could come up with _another_ reasons why there _are_
I/O BARs in the spec., to begin with!
That, or IDP (Index Data Pair PCI config access). The latter was the
route they went with AHCI, though it took several iterations for <big
company starting with "I"> to get that one right.
So, yeah, as a software guy, you are cannon fodder.
Michael Tippach
wolfgang kern wrote:
> Michael Tippach suggested:
>
> Perhaps a good advice as long you find enough space in the 64KB I/O-range.
> Looking at my current hardware, I got several Megabyte memory mapped I/O.
The point is that an I/O BAR is not an optional "nice to have" feature
here. How else would you go ahead and access MMIO in a - random and
otherwise unspecified - V86 environment?
Or use IDP, but MMIO is _never_ going to work for a production driver in
this scenario.
H. Peter Anvin
On 11/07/2009 03:23 AM, wolfgang kern wrote:
>
> Perhaps a good advice as long you find enough space in the 64KB I/O-range.
> Looking at my current hardware, I got several Megabyte memory mapped I/O.
>
That's why you use a paged window. Keep in mind that the actual control
register accesses should be relatively far between.
-hpa
Rod Pemberton
>
> I would really appreciate it if you could provide some
> links or theory that show this mode switching will fail for a driver
> under DOS so I can show it to the hardware people.
I only have experience with DPMI. These are the expanded/extended memory
providers for DOS: XMS (e.g., HIMEM.sys) , EMS (e.g., EMM386.exe), VCPI,
DPMI. There are specifications available for all of them. For DPMI, one
uses the methods of cpu mode switching or memory mapping that it provides.
I'd assume the same is true for the others.
Mr. Tippach seems to be saying certain combinations will deny your driver
the needed access to it's memory region. I think he's saying this is
especially true one loses or fails to establish full control of V86 mode:
a) "... will fall apart in one or the other customer setup - V86 with no
VCPI/DPMI, ..."
E.g., an application switched to V86 mode. The application controls the
only method to exit V86 mode, i.e., PM monitor. This being the case, your
driver has no method to setup "unreal" mode, do RM to PM switching, do
memory mapping, etc.
b) " ... complain that their (not your) stuff falls apart once e.g. EMM386
is loaded ... "
EMM386 switches the cpu to V86 mode. I'm not familiar with EMM, but I'd
suspect there are functions to allow cpu switching or memory mapping via
EMM.
Maybe he can explain in more detail. I'm interested.
comp.os.msdos.programmer might be a place to ask also.
Rod Pemberton
Michael Tippach
Rod Pemberton wrote:
> I only have experience with DPMI. These are the expanded/extended memory
> providers for DOS: XMS (e.g., HIMEM.sys) , EMS (e.g., EMM386.exe), VCPI,
> DPMI. There are specifications available for all of them. For DPMI, one
> uses the methods of cpu mode switching or memory mapping that it provides.
> I'd assume the same is true for the others.
While there may be a way in many cases, a simple /NOVCPI closes EMM386
shut entirely, for instance. Few DPMI hosts allow more than one client,
etc...
Apart from that you have to consider that this memory copying / mode
switching must also work in the context of the NIC hardware interrupt
handler. Reentrantly so! Plus, you have to check the current operating
environment each and every time the driver gets control (including
inside its IRQ handler, each and every time an IRQ is triggered)
Did I mention A20 management? + Access alignment requirements (there is
no guarantee that e.g. DWORD reads/writes will be atomic) ...
This is why one needs to poke the hardware designers with a big stick
until they realize the errors of their ways.
I remember of a similar incident, where some clever guy thought that
mapping their MMIO below 1MB (at e.g. D0000h) was going to fix this. Had
to educate the chap about PCI-PCI bridges.
There is only so and so much about poor hardware design that can be
fixed in software.