Memory mapping large files with uCLinux

Hi, I've done a fair bit of searching around for an answer to this question:

Is it possible to memorymap a large file (120MB) from a block-based flash filesystem?

The board i'm working with is the KwikByte KB9202B board which has

64MB SDRAM and a SD/MMC flash reader.

The application needs to be able to access a large amount of data which will be stored on the SD card in the reader. The application has been written with MMUs in mind and hence simply memory maps the large data file and accesses the data through the pointer returned.

I have read

formatting link
that it should be possible to memory map from a ROMFS filesystem with the READONLY flag set in mmap however this article also says that the flash device holding the ROMFS filesystem should be mapped into the processors address space.

Is anyone able to shed more light on this?

The other option is to rewrite the data-reading code to access the filesystem directly.

Regards,

Nick

Reply to
n.vaughan
Loading thread data ...

1) Whats stopping you from trying it out?

2) I mmap-ed 64 MB file on our target's NFS disk and /dev/mem, and I think it can mmap even bigger files.

Reply to
anon

Thanks for your response.

I have tried it and it failed. From my understanding, uCLinux will copy when mmap is called and return the pointer to the copied data. Therefore I believe that the attempt to copy 120MB into 64MB ram failed, returning 0xFFFFFFFF which i assume means that it couldn't allocate memory.

How did you accomplish this? How much RAM does your target have? Are you running uCLinux?

Reply to
n.vaughan

Sorry for confusion. I am not using uCLinux, but normal Linux

Are you using MAP_PRIVATE? That thing copies complete file to the memory. My call to mmap() is: mmapPtr = mmap( NULL, mmapSizeInBytes, PROT_READ | PROT_WRITE, MAP_FILE | MAP_SHARED, fd, mmapOffsetInBytes );

Might worth a try

Reply to
anon

That sounds very likely. A result -1 to an API call most often is an error message.

-Michael

Reply to
Michael Schnell

No problem and thanks for your response.

Ok, full linux has support for MMU, uCLinux has no MMU support so even though the board i'm using has an MMU it is disabled/unused by uCLinux.

I have been using PROT_READ as we only need read access to the data.

Reply to
n.vaughan

That one is not important. What do you use for mmap flags ("MAP_FILE | MAP_SHARED" in my case) ? As I said, MAP_PRIVATE copies whole file to memory

Reply to
anon

You are crazy.

The memory of the SD card is not mappable. Never. Look into a SD card datasheet!

So each and every driver regardless of the architecture has to copy the data from SD card into memory. All you can get with mmap() is maybe to avoid a needless copy between kernel and user space. Nothing more.

regards

Wolfgang

Reply to
Wolfgang Mües

Yes, sorry, we're using MAP_SHARED.

Reply to
n.vaughan

Yes, sometimes. If the flash device itself is mapped into the processor's address space.

In this case you can't, unless your MMC interface does it for you, which is very unlikely.

Depending on your hardware, you *may* be able to fake it, at a huge performance cost. The key would be to find an address range which can trigger an exception. You catch the exceptions and emulate a memory map.

Kind regards,

Iwo

Reply to
Iwo Mergler

Thanks! :)

That's what i thought was the case.

Looks like the application will have to be refactored to allow file- based I/O rather than mem mapping.

Reply to
n.vaughan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.