My error should be commented out in the following code. I have tried mixing things around in many Wais, but whatever I do the "EnumOutputs" function won't work when I try force it to use use my GeForce GTX 765M card. And as far as I know I need that pdxgiOutput to later make of my GetDisplayModeList1();
Hope this will be information enough to see what the problem is.
std::vector <IDXGIAdapter1*> availableAdapters;
while (m_pIDXGIFactory->EnumAdapters1(m_adapterIndex, &pdxgiAdapter) != DXGI_ERROR_NOT_FOUND)
{
availableAdapters.push_back(pdxgiAdapter);
++m_adapterIndex;
}
pdxgiAdapter = availableAdapters[1]; // NVIDIA GeForce GTX 765M
//pdxgiAdapter = availableAdapters[0]; // Intel(R) HD Graphics 4600
pdxgiAdapter->EnumOutputs(0, &pdxgiOutput); // !!**Failure when use NVIDIA Gefore 765M!**
Debug Assertion failed: C:\ProgramFiles\Microsoft Visual Studio
12.0\VC\include\vector Line: 1201
Expression: vector subscript out of range
The assert you're getting sounds like it's coming from your use of the subscript operator on the "availableAdapters" vector, not from EnumOutputs.
Have you tried printing out the .size() of the vector prior to accessing the 2nd element to check there's actually two things in it? Is it not possible that your laptop (?) has two GPUs but only one is enumerable at any given time and are switched on/off in the BIOS (or by some other means)?
Im a beginner to this, but could try set it up another way:
std::vector <IDXGIAdapter1*> availableAdapters;
while (m_pIDXGIFactory->EnumAdapters1(m_adapterIndex, &pdxgiAdapter) != DXGI_ERROR_NOT_FOUND)
{
availableAdapters.push_back(pdxgiAdapter);
++m_adapterIndex;
}
pdxgiAdapter = availableAdapters[1]; // NVIDIA GeForce GTX 765M
//pdxgiAdapter = availableAdapters[0]; // Intel(R) HD Graphics 4600
pdxgiAdapter->GetDesc1(&AdapterDesc);
if (AdapterDesc.DedicatedVideoMemory)
{
m_videoCardMemory = AdapterDesc.DedicatedVideoMemory;
}
else
{
m_videoCardMemory = AdapterDesc.SharedSystemMemory;
}
pdxgiAdapter->EnumOutputs(m_outputIndex, &pdxgiOutput));
And when I try With bouth availableAdapters[1] or [0] the GetDesc find bouth the Intel and GeForce - card. But fails in the EnumOutpts With the Geforce, Leaves pdxgiOutput = 0x00000000000000
Related
In an external kernel module, using DMA Engine, when calling dma_request_chan() returns an error pointer of value -19, i.e. ENODEV or "No such device".
Now, in the active device tree, I do find a dma-names entry with what I'm trying to get a channel for, so my suspicion is that something else deeper in the forest is already not found.
How do I find out what's wrong?
Background:
I have a Zynq MP Ultrascale+ board here, with an FPGA design which uses AXI VDMA block to provide one channel of data to be received on the Cortex A's Linux, where the data is written to DDR4 by the FPGA and to be read from Linux.
I found that there is a Xilinx DMA driver included in the kernel, in the Xilinx source repo anyway, currently kernel version 5.6.0.
And that that driver has no user space interface, such that an intermediate kernel driver is needed.
This is depicted, and they have an example here: Section "4 DMA Proxy Design". I modified the code in the dma-proxy.c of the zip file linked there such that it uses only the RX channel, i.e. also only tries to request it.
The code for that is here, to not make this post huge:
Modified dma-proxy.c at onlinegdb.com
Line 407 has the function create_channel(), which used to use dma_request_slave_channel() which ditches the error code of the function it wraps, so to see the error, I am using that one instead: dma_request_chan().
The function create_channel() is called in function dma_proxy_probe() # line 470 (the occurences before that are deactivated by compile switch).
So by way of this call, dma_request_chan() will be called with the parameters:
create_channel(pdev, &channels[RX_CHANNEL], "dma_proxy_rx", DMA_DEV_TO_MEM);
The Device Tree for my board has an added node for dma-proxy driver as is shown at the top of the dma-proxy.c
dma_proxy {
compatible ="xlnx,dma_proxy";
dmas = <&axi_dma_0 0>;
dma-names = "dma_proxy_rx";
};
The name "axi_dma_0" matches with the name in the axi DMA device tree node:
axi_dma_0: dma#a0000000 {
#dma-cells = <0x1>;
clock-names = "s_axi_lite_aclk", "m_axi_s2mm_aclk";
clocks = <0x3 0x47 0x3 0x47>;
compatible = "xlnx,axi-dma-7.1", "xlnx,axi-dma-1.00.a";
interrupt-names = "s2mm_introut";
interrupt-parent = <0x1d>;
interrupts = <0x0 0x2>;
reg = <0x0 0xa0000000 0x0 0x1000>;
xlnx,addrwidth = <0x28>;
xlnx,sg-length-width = <0x1a>;
phandle = <0x1e>;
dma-channel#a0000030 {
compatible = "xlnx,axi-dma-s2mm-channel";
dma-channels = <0x1>;
interrupts = <0x0 0x2>;
xlnx,datawidth = <0x40>;
xlnx,device-id = <0x0>;
};
If I now look here:
% cat /proc/device-tree/dma_proxy/dma-names
dma_proxy_rx
Looks like my dma_proxy_rx, that I'm trying to request the channel for, is in there.
Edit:
In the boot log, I see this:
xilinx-vdma a0000000.dma: Please ensure that IP supports buffer length > 23 bits
irq: no irq domain found for interrupt-controller#a0010000 !
xilinx-vdma a0000000.dma: unable to request IRQ 0
xilinx-vdma a0000000.dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use
xilinx-vdma a0000000.dma: Xilinx AXI DMA Engine Driver Probed!!
There are warnings - but in the end, the Xilinx AXI DMA Engine got "probed", meaning the lowest level driver loaded and is ready, right?
So it looks to me like there should be my device, but the kernel disagrees.
I've got the same problem with similar configuration. After digging a lot of kernel source code (especially drivers/dma/xilinx/xilinx_dma.c) I've solved this problem by changing channel number in dmas parameter from 0 to 1 in dma-proxy device tree entry like this:
dma_proxy {
compatible ="xlnx,dma_proxy";
dmas = <&axi_dma_0 1>;
dma-names = "dma_proxy_rx";
};
It seems that dma-proxy example is written for AXI DMA block with both mm2s (channel #0) and s2mm (channel #1) channels. And if we remove mm2s channel from AXI DMA block, the s2mm channel stays #1.
I want to know if it is possible to connect multiple RC522 to one Raspberry PI, if yes how do we do it? I read in some articles that with CS(chip select) pin we can control Readers, but the CS pin is not present on RC522 I have.
Can you please help me?
Chip Select (CS) is referred to as SS or NSS in some of the RFC522 documentation, is that the issue? If so, connect your CS0 to NSS on one module, CS1 to the NSS on the other, and you can use both modules on the same SPI bus.
If you need more devices than that, you could switch to the I2C interface. In I2C mode, a number of the pins on the chip become address selects, so you can put a whole bunch of them on the same I2C bus. The data sheet for the chip is always helpful with this sort of information. Section 8.1, "Digital interfaces" may be particularly helpful.
In I2C mode, you have 5 bits of addressing, so you can put up to 32 devices on the bus.
Posted this answer before on the raspberry pi stackexchange.
I'll just repost it here for visibility.
You can use the RST Pins to select the reader you want to use. Connect all the other pins in parallel (see schematic below). Just set all the RST pins to low, except the one on the pin you want to use. Set that one to high. Then initialize SPI, read/write, and close SPI again.
I wrote a more detailed explanation here.
This is the schematics and code I made:
Schematic for 2 readers
Schematic for 4 readers
Code to run it all (using pimylifeup's MFRC522-Python Library):
import RPi.GPIO as GPIO
from mfrc522 import SimpleMFRC522
import spidev
class NFC():
def __init__(self, bus=0, device=0, spd=1000000):
self.reader = SimpleMFRC522()
self.close()
self.bus
self.boards = {}
self.bus = bus
self.device = device
self.spd = spd
def reinit(self):
self.reader.READER.spi = spidev.SpiDev()
self.reader.READER.spi.open(self.bus, self.device)
self.reader.READER.spi.max_speed_hz = self.spd
self.reader.READER.MFRC522_Init()
def close(self):
self.reader.READER.spi.close()
def addBoard(self, rid, pin):
self.boards[rid] = pin
def selectBoard(self, rid):
if not rid in self.boards:
print("readerid " + rid + " not found")
return False
for loop_id in self.boards:
GPIO.output(self.boards[loop_id], loop_id == rid)
return True
def read(self, rid):
if not self.selectBoard(rid):
return None
self.reinit()
cid, val = self.reader.read_no_block()
self.close()
return val
def write(self, rid, value):
if not self.selectBoard(rid):
return False
self.reinit()
self.reader.write_no_block(value)
self.close()
return True
if __name__ == "__main__":
nfc = NFC()
nfc.addBoard("reader1",5)
nfc.addBoard("reader2",6)
data = nfc.read("reader1")
nfc.write("reader2",data)
In my QEMU-based project (system emulation) I analyse various kernel structures of the guest Linux. To read the guest virtual memory I use cpu_memory_rw_debug() function.
In particular, I search struct module linked list in the kernel memory using some kind of heuristics.
Lest assume that the relevant part of an element in this list looks like this:
--------------------- ---------------------
| prev = 0xc1231234 | | prev = 0xc5675678 |
--------------------- ---------------------
| next = 0xc1122334 | | next = 0xc5566778 |
--------------------- ---------------------
| etc. | | etc. |
--------------------- ---------------------
When QEMU emulates x86 or ARM, prev/next pointers can be accessed by cpu_memory_rw_debug() and they actually point to previous/next list elements.
However, when QEMU emulates MIPS, I observe the following strange behavior: while prev/next pointers look like a valid kernel pointers in every element in the list, I cannot access their pointees by means of cpu_memory_rw_debug(), because finding the corresponding physical address fails: the access permissions are ok, the virtual CPU is in kernel mode, but tlb->map_address() fails.
Since I can't walk through the linked list, I tried to find the elements one by one - just to see what their prev/next pointers look like - and I actually found all the elements, but all of them reside at 0xAxxxxxxx addresses, not 0xCxxxxxxx, as prev/next imply.
The function r4k_map_address(), which performs physical address lookup looks like this (only the relevant excerpt):
#define KSEG0_BASE 0x80000000UL
#define KSEG1_BASE 0xA0000000UL
#define KSEG2_BASE 0xC0000000UL
#define KSEG3_BASE 0xE0000000UL
//..............
if (address < (int32_t)KSEG1_BASE) {
/* kseg0 */
if (kernel_mode) {
*physical = address - (int32_t)KSEG0_BASE;
*prot = PAGE_READ | PAGE_WRITE;
} else {
ret = TLBRET_BADADDR;
}
} else if (address < (int32_t)KSEG2_BASE) {
/* kseg1 */
if (kernel_mode) {
*physical = address - (int32_t)KSEG1_BASE;
*prot = PAGE_READ | PAGE_WRITE;
} else {
ret = TLBRET_BADADDR;
}
} else if (address < (int32_t)KSEG3_BASE) {
/* sseg (kseg2) */
if (supervisor_mode || kernel_mode) {
ret = env->tlb->map_address(env, physical, prot, real_address, rw, access_type);
} else {
ret = TLBRET_BADADDR;
}
That is, on MIPS 0xC0000000...0xE0000000 range is mapped differently from lower kernel ranges.
If I replace the TLB access with *physical = address - (int32_t)KSEG1_BASE direct mapping, I get the things working, but certainly that's not the solution.
Does it look like QEMU-related issue or a MIPS-related one? I'd appreciate any idea or debugging direction.
The bottom line is that cpu_memory_rw_debug() doesn't work reliably in qemu-system-mips.
The reason is that QEMU emulates MIPS software-managed TLB. With this approach, whenever virtual->physical address mapping does not exist in the TLB cache, QEMU emulates "TLB-miss" exception, which should be handled by the OS. It is OS responsibility to walk through the page directory and fill the TLB -- QEMU (just like real MIPS) won't do that.
While this approach works for the guest code, it results in inability
to read guest virtual memory using cpu_memory_rw_debug() - it
doesn't work reliably for mapped segments.
As for the question why kernel structs that actually reside in KSEG2 where observed in KSEG1 - that's just because some virtual ranges of KSEG1 and KSEG2 correspond to the same physical pages.
Nvidia does not allow the access to the generated LLVM IR in the compilation flow of a GPU kernel written in CUDA C/C++. I would like to know if this is possible if I use Alea GPU? In other words, does Alea GPU compilation procedure allows keeping the generated optimized/unoptimized LLVM IR code?
Yes, you are right, Nvidia doesnot show you the LLVM IR, you can only get the PTX code. While Alea GPU allows you to access LLVM IR in several ways:
Method 1
You use the workflow-based method to code a GPU module as a template, then you compile the template into an LLVM IR module, then you link the LLVM IRModule, optionally with some other IR modules, into a PTX module. Finally, you load the PTX module into the GPU worker. While you get the LLVM IRModule, you can call its method Dump() to print the IR code to console. Or you can get the bitcode as byte[].
I suggest you read more details here:
Workflow-Based GPU Coding
Workflows in Detail
The F# would be something like this:
let template = cuda {
// define your kernel functions or other gpu moudle stuff
let! kernel = <# fun .... #> |> Compiler.DefineKernel
// return an entry pointer for this module, something like the
// main() function for a C program
return Entry(fun program ->
let worker = program.Worker
let kernel = program.Apply kernel
let main() = ....
main ) }
let irModule = Compiler.Compile(template).IRModule
irModule.Dump() // dump the IR code
let ptxModule = Compiler.Link(irModule).PTXModule
ptxModule.Dump()
use program = worker.LoadProgram(ptxModule)
program.Run(...)
Method 2
If you are using Method-based or Instance-based way to code GPU module, you can add event handler for LLVM IR code generated and PTX generated though Alea.CUDA.Events. The code in F# will look like:
let desktopFolder = Environment.GetFolderPath(Environment.SpecialFolder.Desktop)
let (##) a b = Path.Combine(a, b)
Events.Instance.IRCode.Add(fun ircode ->
File.WriteAllBytes(desktopFolder ## "module.ir", ircode))
Events.Instance.PTXCode.Add(fun ptxcode ->
File.WriteAllBytes(desktopFolder ## "module.ptx", ptxcode))
Extend GPU function by using LLVM code
Finally, there is an undocumented way, to let you directly operate on LLVM IR code to construct the functions. It is done by attribute that implemented some IR building interface. Here is a simple example, that accept the parameter, and print it (in compile-time), and return it back:
[<AttributeUsage(AttributeTargets.Method, AllowMultiple = false)>]
type IdentityAttribute() =
inherit Attribute()
interface ICustomCallBuilder with
member this.Build(ctx, irObject, info, irParams) =
match irObject, irParams with
| None, irParam :: [] ->
// the irParam is of type IRValue, which you
// can get the LLVM native handle, by irParam.LLVM
// Also, you can get the type by irParam.Type, which
// is of type IRType, again, you can get LLVMTypeRef
// handle by irParam.Type.LLVM
// You can optionally construct LLVM instructions here.
printfn "irParam: %A" irParam
Some irParam
| _ -> None
[<Identity>]
let identity(x:'T) : 'T = failwith "this is device function, better not call it from host"
I am moving my first steps into Linux Kernel Device Driver development.
I learnt that for pci-e cards I have to call pci_register_driver providing information via an object of type pci_driver ( below an example ).
When I load my module ( via insmod ) If the information passed via .id_table is found than the .probe function is called.
As I am now I cannot see my .probe function called at all ( I added some logging via printk ) so I must assume that the information contained in pci_device_id must be wrong, right?
Is there any way to retrieve this information directly from the hardware itself?
Once I plug my PCI-E card on my Linux box, where I can find all information about it?
Maybe reading BIOS or some file in sys?
Any help is appreciated.
AFG
static struct pci_driver my_driver = {
// other here
.id_table = pci_datatable,
.probe = driver_add
//
};
static struct pci_device_id pci_datatable[] __devinitdata =
{
{ VendorID, PciExp_0041, PCI_ANY_ID, PCI_ANY_ID },
{ 0 },
};
int __devinit DmaDriverAdd(
struct pci_dev * pPciDev,
const struct pci_device_id * pPciEntry
)
{
// my stuff!
}
While the accepted answer does indeed answer the question, I want to elaborate a bit about the probe function not being called.
According to the Documentation/PCI/pci.txt (How To Write Linux PCI Drivers) the probing function is called for all existing PCI devices that are not owned by the other drivers yet. So, even if you have the correct vendor and device IDs you will not see the function being called if the device is owned by another driver.
To see which drivers own which devices run:
lspci -knn
If you temporarily change both vendor ID and device ID to PCI_ANY_ID your probe function will be called for every available (i.e. not owned) device.
The command you want is lspci.
With no arguments it will give you a list of all PCI devices, eg:
$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
...
Then to get the ids, use:
$ lspci -v -n -s 03:00.0
03:00.0 0280: 8086:0085 (rev 34)
Subsystem: 8086:1311
Flags: bus master, fast devsel, latency 0, IRQ 52
You can also find the same information in /sys:
$ cd /sys/bus/pci/devices/0000:03:00.0
$ cat vendor device
0x8086
0x0085
$ cat subsystem_vendor subsystem_device
0x8086
0x1311