Port to RT-Thread Smart DM PCI

Signed-off-by: GuEe-GUI <[email protected]>

libpci: Add Windows physmem support for PCIe ECAM access

It requires either access to NT Section \Device\PhysicalMemory (or
compatible) or to have available kernel32.dll VxDCall2 function or
w32skrn

libpci: Add Windows physmem support for PCIe ECAM access

It requires either access to NT Section \Device\PhysicalMemory (or
compatible) or to have available kernel32.dll VxDCall2 function or
w32skrnl.dll DPMI function.

show more ...

libpci: Add DJGPP physmem support for PCIe ECAM access

It requires either Device Mapping support on DPMI host or Physical Address
Mapping support together with support for changing DS descriptor lim

libpci: Add DJGPP physmem support for PCIe ECAM access

It requires either Device Mapping support on DPMI host or Physical Address
Mapping support together with support for changing DS descriptor limit to
maximal size 4 GB which enables address wrapping and so access to addresses
below the process base address.

show more ...

Haiku: fix build with DNS=yes.

libpci: Enable POSIX physmem also on Solaris, Haiku nad BeOS

Solaris can access physical memory via mmap() of /dev/xsvc device and
Haiku + BeOS of /dev/misc/mem device.

Since we already require C99, we can rely on <stdint.h>

AmigaOS: Construct version string automatically

New back-end for AmigaOS on PowerPC

i386-ports: Add support for OpenBSD

libpci: Add PCIe ECAM access method

This is a new direct hardware access method via PCIe ECAM (Enhanced
Configuration Access Mechanism). It is available on all PCIe-compliant
hardware. Requires root

libpci: Add PCIe ECAM access method

This is a new direct hardware access method via PCIe ECAM (Enhanced
Configuration Access Mechanism). It is available on all PCIe-compliant
hardware. Requires root privileges and access to physical memory.

ECAM mapping can be specified manually via a new ecam.addrs parameter or
can be read from ACPI MCFG table. ACPI MCFG table can be located in the
system or read from x86 BIOS memory.

show more ...

libpci: mmio-ports: Add configure note messages

libpci: Add new windows kldbgdrv.sys implementation

Microsoft Kernel Local Debugging Driver (kldbgdrv.sys) allow access for
userspace processes to the PCI config space. It supports access up to
6553

libpci: Add new windows kldbgdrv.sys implementation

Microsoft Kernel Local Debugging Driver (kldbgdrv.sys) allow access for
userspace processes to the PCI config space. It supports access up to
65536 domains and whole 4096 bytes long extended PCIe config space. Driver
is signed by Microsoft and is available for both 32-bit and 64-bit systems.

Driver is not part of Windows system and has to be installed via WinDbg
installation package. Standalone installers for WinDbg 6.12.2.633 version:
https://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools_amd64/dbg_amd64.msi
https://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi

This kldbgdrv.sys API is used by the !pci command of new WinDbg kernel
debugger for displaying PCI config space.

API of this driver is available only for processes with Debug privilege and
only if system was booted with Debugging option.

show more ...

Disable mmio-ports on platforms where it does not make much sense

Feel free to re-enable it if you find it useful.

libpci: Add Intel Type 1 implementation for memory mapped systems

Lot of non-x86 platforms also support Intel Type 1 mechanism. x86 IO ports
CF8 and CFC are on these platforms mapped into standard m

libpci: Add Intel Type 1 implementation for memory mapped systems

Lot of non-x86 platforms also support Intel Type 1 mechanism. x86 IO ports
CF8 and CFC are on these platforms mapped into standard memory space.
Address mapping itself is platform or board specific and there is no
default value.

Lot of ARM boards with multiple PCIe controllers are multi-domain and each
PCI domain has its own CF8/CFC (address/data) registers mapped into memory
space.

Add new mmio-conf1 backend which access CF8/CFC ports via MMIO and define
new config option mmio-conf1.addrs which specify list of address/data
register pairs in memory space for each PCI domain. Format of this option
is: 0xaddr1/0xdata1,0xaddr2/0xdata2,...

show more ...

libpci: Add support for building versioned shared Windows DLL library libpci3.dll

PE/COFF format, used by DLL libraries, does not support version symbols
like ELF format. Recommendation from Microso

libpci: Add support for building versioned shared Windows DLL library libpci3.dll

PE/COFF format, used by DLL libraries, does not support version symbols
like ELF format. Recommendation from Microsoft for DLL symbol versioning is
to use DLL API sets. But DLL API sets scheme requires for every API change
to generated a new slim forwarding DLL library, which is unsuitable for
distribution which wants just one DLL library with all version symbols.

So instead of Microsoft recommended scheme for DLL versioning, use new
different versioning scheme: Symbol is composed by function name, at (@)
character and version string (version is same as for ELF targets). Symbol
name without version information is added only into the DLL DEF file as
alias to symbol with higest version. So linker at application link time
resolves "unversioned" symbol to the versioned one via this alias and puts
"versioned" symbol into final executable. This works fine if GNU LD is
linking application via import library libpci3.dll.a generated from that
DLL DEF file libpci3.def. But does not work when linking directly to the
DLL library because library itself does not contain aliases. Note that GNU
LD does not support linking to DEF file (it is required to first generated
import library from DEF file).

Note that older GNU LD versions have bug which cause generation of
corrupted DLL files if some symbol contains dot (.) character. Hopefully
this bug was fixed in GNU LD 2.21.

At the end application lspci.exe requires library libpci3.dll with symbols
pci_alloc@LIBPCI_3.0, pci_init@LIBPCI_3.5, pci_fill_info@LIBPCI_3.8 and
therefore libpci3.dll stays backward compatible with future changes.

PE/COFF executables can reference symbols either via name or via its
ordinal number. Because DLL DEF files are generated from libpci version
script and generator ver2def.pl preserves order of symbols, it means that
ordinal numbers stay backward compatible unless order of lines in version
script is changed.

WARNINGS:

GCC an GNU LD for Windows target have some bugs which cause that
-fvisibility=hidden switch and __attribute__((visibility("default"))) does
not work. Seems that they are broken and ignored when building DLL library.
So instead use -Wl,--exclude-all-symbols switch with explicit DLL DEF file
for building DLL library, which seems to work. This switch is supported
since GNU LD 2.21.

GNU LD has also another bug which results in broken DLL library if input
DLL DEF file which describes symbols for exports, contains also symbol
aliases via == operator.

So do not specify symbol aliases in input DLL DEF file for building DLL
library. Instead construct separate DLL DEF file for building libpci3.dll
without symbol aliases and separate DLL DEF file libpci3.def with symbol
aliases for building import library libpci3.dll.a suitable for linking into
target applications. Note that operator == for symbol aliases is supported
since GNU dlltool 2.21.

Generate those two DLL DEF files via new script ver2def.pl from libpci.ver
version script. So exported functions and version symbols would be defined
only at one place in file libpci.ver.

Note that GNU LD for Windows targets has also broken support for version
scripts, it exports nonsense data and completely ignores version
information. So always use only DLL DEF files generated by ver2def.pl
script and never pass original version script to GNU LD.

Due to another bugs in GNU dlltool, ordinals for aliased symbols from DLL
DEF file are calculated incorrectly when building import library. So
calculate ordinals manually in ver2def.pl script and explicitly put then
into generated libpci3.def DLL DEF file for every symbol, including
aliases.

And because aliases are stored only in libpci3.def file (and in import
library libpci3.dll.a generated from that DEF file) and not in DLL library
libpci3.dll itself, it is required to link all libpci applications via
import library and not directly to libpci3.dll. This is limitation of
PE/COFF format used by DLL libraries.

So for building Windows DLL library libpci3.dll is needed to use GNU
binutils 2.21 or new.

show more ...

lib/configure: respect $PKG_CONFIG completely

Signed-off-by: Sam James <[email protected]>

lib/configure: drop usage of which

'which' is not required by POSIX and is an external command which may not be
available, and 'command -v' does the job just fine.

Debian and Gentoo at least are bo

lib/configure: drop usage of which

'which' is not required by POSIX and is an external command which may not be
available, and 'command -v' does the job just fine.

Debian and Gentoo at least are both making efforts to drop which from
their base system package list.

Signed-off-by: Sam James <[email protected]>

show more ...

Makefile: Split variable for output shared library and import linking library

Use new variable $(PCIIMPLIB) for storing name of the libpci import library
for linking with shared library $(PCILIB).

Makefile: Split variable for output shared library and import linking library

Use new variable $(PCIIMPLIB) for storing name of the libpci import library
for linking with shared library $(PCILIB).

This would allow compilation of lspci and setpci applications on systems
where linking needs to be done with import library.

show more ...

Makefile: Unify building of shared libpci library

Move Darwin and Linux/ELF platform link switches to new PCILIB_LDFLAGS
variable.

libpci: Add new windows NT sysdbg implementation

NT SysDbg interface allow access to the PCI config space. Only devices on
the first domain are available and only first 256 bytes of the PCI config
s

libpci: Add new windows NT sysdbg implementation

NT SysDbg interface allow access to the PCI config space. Only devices on
the first domain are available and only first 256 bytes of the PCI config
space can be accessed. Compared to intel-conf1 access, this API is race
free as NT kernel serialize access to PCI I/O ports. This NT SysDbg API is
used by the !pci command of 32-bit WinDbg kernel debugger for displaying
PCI config space. Debug privilege is required to use this NT interface.

show more ...

libpci: Compile windows i386-ports only for x86 CPU

There are already arm32 and arm64 port of MinGW-w64 toolchain.

libpci: Add windows cfgmgr32 implementation

Access via cfgmgr32.dll library allows to list PCI devices and retrieve
their basic properties and system resource configuration. Access is
available to a

libpci: Add windows cfgmgr32 implementation

Access via cfgmgr32.dll library allows to list PCI devices and retrieve
their basic properties and system resource configuration. Access is
available to all users and should not require special privileges, access
tokens, rights or permissions.

This cfgmgr32.dll library does not provide access to PCI config space.

show more ...

Install lspci to /usr/bin on Linux systems

On Linux, lspci is useful even for ordinary users, although only
a subset of features is available.

configure: Generate config files for PCI_OS_WINDOWS

This change adds support for using configure script for cross-compiling
pciutils on Linux for Windows platforms.

Following command can be used to

configure: Generate config files for PCI_OS_WINDOWS

This change adds support for using configure script for cross-compiling
pciutils on Linux for Windows platforms.

Following command can be used to compile pcitils for Windows platform:

make CROSS_COMPILE=i586-mingw32msvc- HOST=i386-windows ZLIB=no IDSDIR=.

PCI_OS_WINDOWS does not support BSD DNS functions, so do not automatically
enable DNS support.

Library ioperm is cygwin specific and is used only for PCI_OS_CYGWIN.

show more ...

Makefile: Append EXEEXT variable to executable filename rules

If x86_64-w64-mingw32-gcc compiler is called with -o filename option
without any file extension then compiler automatically appends suff

Makefile: Append EXEEXT variable to executable filename rules

If x86_64-w64-mingw32-gcc compiler is called with -o filename option
without any file extension then compiler automatically appends suffix
".exe" to output filename.

This behavior of x86_64-w64-mingw32-gcc compiler basically breaks pattern
rule of type '%: %.o' as x86_64-w64-mingw32-gcc compiler cannot generate
arbitrary output file via -o option just by stripping .o extension from
filename.

When generating executables by x86_64-w64-mingw32-gcc compiler it is
really the best option to specify .exe suffix in -o option.

So introduce a new makefile variable EXEEXT which will be automatically
appended to any executable filename. For Windows and DOS systems set it
to ".exe". For other systems set it just to empty string "".

GNU automake uses same makefile variable for same purpose.

show more ...