Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


About READ_PORT_UCHAR and READ_PORT_ULONG

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Dear all,
I am coding a driver that should access IO port. I have some question on
IO port access,
anyone can help me?
1: Can READ_PORT_ULONG read from non DWORD aligned boundary? If we can, is
the value right?
2: If use READ_PORT_UCHAR four times and combined the four BYTEs into a
DWORD value, and then
I use READ_PORT_ULONG at the same address, are these two values same?
Thanks.
BR
Volition2k

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 1: Can READ_PORT_ULONG read from non DWORD aligned boundary? If we can, is
    >the value right?
    > 2: If use READ_PORT_UCHAR four times and combined the four BYTEs into a
    >DWORD value, and then
    > I use READ_PORT_ULONG at the same address, are these two values same?
    > Thanks.

    I'll give the famous driver writer's answer, it depends.

    At least some I/O buses (like PCI) can't do a 32-bit transfer on an
    unaligned address. Such a transfer will get broken into multiple transfer
    cycles with appropriate byte enables set. The DWORD transfer may still
    happen in a single burst (with multiple data phases).

    There is no guarantee that four READ_PORT_UCHAR will happen on back to back
    bus cycles. You might get the first one, and then a big bus master
    transfer, and then the following three, all in different bursts You'de have
    to look at the bus spec to decided if an unaligned DWORD request is
    guaranteed to be executed in a single burst. My guess is, it's
    implementation (chipset) dependent. An aligned read DWORD read may or may
    not be guaranteed to be a single burst. Again, I'd have to look at the bus
    spec to decide who controls the byte enables, the master or target or both.

    One difference between a single DWORD read and 4 BYTE reads is the timing
    and how the signals influence the hardware. For example, on a PCI bus, if
    you do a single DWORD reads, the hardware may be designed to change state
    when an address is read. Four byte reads will address the same address four
    times, but with different byte enables set, so may interact with the
    hardware different that a single DWORD read.

    I think the point I'm trying to make here is to REALLY determine what
    happens at a bus level when you execute a variety of processor
    instructions, you need a bus analyzer. And even then, behavior may vary
    based in things like chipset. The device hardware specs will often say what
    size of transfers are required, and any alignment requirements.

    Seems like I remember some hardware that would act badly (as in lockup the
    bus) if you didn't do transfers on DWORD size and aligned on a DWORD. Part
    of the issue was generation of correct PCI bus parity.

    Transfer alignment can also have a huge impact on performance. For example,
    I worked on one PCI bus master network device that was unable to
    efficiently rotate the data between it's internal buffers, and the buffers
    in main memory. This was really ugly, as some of the network headers were
    not exactly nice even sizes. The goal was to look at the packet header, and
    then arrange for the bus master transfer of the data body into some
    buffers. Unfortunately, the alignment of these buffers did not match the
    alignment of the data internally in the network card. The end result was a
    LOT more bus cycles were required to transfer the data than expected (like
    4 bytes transfers, which made a PCI bus only do 33 MBytes/sec).

    - Jan
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online