On Sunday, January 13, 2002, at 11:22 AM, Dean Reece wrote: Shawn, Your static "unsigned short code01[]" will be virtually contiguous (in the kernel task), but is not guaranteed to be physically contiguous.

From your comment "I have to DMA in chunks smaller then the whole firmware image" I'm a bit confused. It sounds like you don't really need a physically contiguous buffer.

Correct. I was just trying to understand if I would have to modify my current downloader code to handle physically non-contiguous firmware images. Also for some versions of the adapters I can DMA the whole firmware image at once others have DMA limitations that don't allow for that. An IOMemoryDescriptor is suitable for wrapping the static "unsigned short code01[]" directly, if you can handle the fact that it may not all be physically contiguous. In that case, getPhysicalSegment will walk you through the segments. You'll find that the segments are all multiples of 4K (page size), except the first and last which may be partial pages. Great, what I thought it would do. In any event, once the firmware is downloaded, you should be able to free up this image (and any copies). Reducing your steady-state wired memory footprint is much more important than trimming the peak footprint used during device initialization. Yup... I was mostly trying to reduce the memory copy overhead which is around 350 KB for each adapter installed in the system. Not sure it is worth it if I end up downloading firmware in page size chunks... I need to think about this a little more. Cheers, - Dean On Sunday, January 13, 2002, at 11:01 AM, Shawn Erickson wrote: I was in the process of doing some driver optimization... I can reduce the amount of kernel memory used and memory copy times iff it is safe to assume IOKit objects are allocated into contiguous physical memory segments. To better explain... I have a firmware driver object that contains a firmware image ( unsigned short code01[] = { ...image..}; ) that a secondary driver we get a pointer to and then download this firmware to my adapter (adapter DMAs the firmware from the physical address I pass it). Currently I have the secondary driver allocate a contiguous memory segment and copy the image into that segment. I would like to avoid this if possible. Is it safe to simply allocate an IOMemoryDescriptor with a pointer to the image and the images length then call getPhysicalSegment to get the start of next segment I want the adapter to download (I have to DMA in chunks smaller then the whole firmware image). I think I know the answer but I keep swapping between working on different OSes (Window NT/2000, Solaris, Mac OS, and Mac OS X) and it becomes hard to keep things straight :{ .... so I thought I better ask to make sure.