Hello,
The attached inf is used to install a driver for a PCIe FPGA.
The driver allocates contiguous physical buffer for DMA.
The routine** AllocateContinuousPhysicalMemory** in **Init.c ** is used to allocate the buffer.
If the buffer size is 0x4GB-PAGE_SIZE, the allocation fails.
As you can see in the inf file, StartType = 0.
In the device manage I got error 31 which means lack of resources.
I have 16GB of RAM.
Can you please tell what is wrong in my inf ?
Thank you,
Zvika
Because even with 16GB of RAM, the size of non-paged pool is limited. It is ridiculous to try to reserve 4GB of contiguous memory. If you need that much memory for DMA, then your hardware must do scatter/gather. Who’s PCIe IP are you using?
Hi Tim,
In this project the firmware does not support scatter\gather.
We are using PCIe IP from ALTERA.
Thank you,
Zvika
Quite apart from Mr. Roberts’ entirely correct observation about the lack of SG… Think about what you’re asking.
First, it should be clear to you that this problem has nothing to do with your INF. Your driver gets loaded and starts running, right? So please explain to me how this could be an INF related problem.
Next, please think a little more: As an engineer, do you really think it’s reasonable to expect to reliably allocate 25% of the system’s memory, in one physically contiguous chunk?
To verify that it is the amount of memory you are requesting. and not something else, you can try reducing the amount of memory you attempt to allocate. Smaller amount work, I bet. Larger amounts do not. What conclusions can you draw from this?
Peter
Hi Peter, All,
2GB works fine.
I thought that if windows loads the driver at the earliest possible stage (SERVICE_BOOT_START), it will found one physically contiguous chunk.
According to:
https://support.microsoft.com/en-us/windows/windows-10-system-requirements-6d4e9a79-66bf-7950-467c-795cf0386715
Windows 10(x64) needs 2GB RAM. So why it can’t find a 4GB contiguous chunk at rest of 14GB ?
Thank you,
Zvika
The minimum amount of physical memory supported by Windows has nothing at all to do with the physical memory footprint of an arbitrary machine at the time it is booted.
Are you assuming that the operating system loads stuff using contiguous physical pages… you know, starting at PA 0 and then using successive pages?
Because, again if you think for a minute or two, you’ll realize things are more complicated than that. We’re not loading a custom-built, tailored, embedded system image. We’re loading a complex, general purpose, operating system that configures itself dynamically as it boots. Consider the fact that, even during system startup, things start, run, and exit. Shared memory (DLLs) get loaded. There are “holes” in physical memory for memory mapped device registers.
So, yes… Starting at boot start – and as early as possible during boot start – is the best way to increase your chances that you’ll be able to allocate as big a chunk as possible. And it’s not entirely out of the realm of possibility that you COULD (sometimes? On some system configurations??) get 4GB out of 16GB. But if you really need an enormous chunk of physical memory on a special-purpose system, you’re going to have to do something more clever. If you’re trying to do this on a general purpose system, forget it.
Peter
To do this reliably, you should use a system with ‘enough’ memory so that your call ‘should’ get satisfied. The basic rule of thumb is 1-2 orders of magnitude greater resource availability versus demand. So if you need 4 GB, the system needs at least 40 GB and maybe 400 GB of RAM
In this project the firmware does not support scatter\gather.
We are using PCIe IP from ALTERA.
I don’t believe that. As far as I know, ALL of Altera’s PCIe blocks support descriptors. Which chip and which IP block?