slram on mapped ram areas
Hi,
It seems that slram was made for access parts of memory not used by the system, or not mapped (right terminology?). I wanted to use it on memory which is mapped or memory that can be used by the system. The problem I have is that the system I work on places a filesystem image in memory someplace, and send the physical address and size of the area as boot parameters. The memory where the images ends up is not special memory.
I made the following changes to your driver (somewhat condensed),
1) Added memblock_reserve() on the memory region
2) Added an insert_resource() call to the memory
3) Altered the driver to not use ioremap, instead use __va() conditionally.
This worked. I was able to access the memory via the typical mtd userspace interface.
So is this something acceptable to add to the slram driver?
Should it go someplace else?
Does the functionality to do this exists someplace already ?
I just wanted to send out feelers before I send any patches..
Daniel
Quoted 8 lines · On Thu, Oct 9, 2014 at 9:17 AM, <[email protected]> wrote:
Hi,
It seems that slram was made for access parts of memory not used by the system, or not mapped (right terminology?). I wanted to use it on memory which is mapped or memory that can be used by the system. The problem I have is that the system I work on places a filesystem image in memory someplace, and send the physical address and size of the area as boot parameters. The memory where the images ends up is not special memory.
I honestly don't know much about the slram.c driver. I doubt it has many serious users these days.
It also seems like you're really trying to use this driver in a way it was not designed. Do you really need to access specific kernel memory? Or do you just want a RAM-backed MTD? There are other drivers for this already (mtdram?).
Quoted 5 lines
I made the following changes to your driver (somewhat condensed),
1) Added
memblock_reserve()on the memory region
2) Added aninsert_resource()call to the memory
3) Altered the driver to not use ioremap, instead use__va()conditionally.
I see this comment next to the __va() definition for ARM:
/*
* Drivers should NOT use these either.
*/
Quoted 10 lines
This worked. I was able to access the memory via the typical mtd userspace interface.
So is this something acceptable to add to the slram driver?
Should it go someplace else?
Does the functionality to do this exists someplace already ?
I just wanted to send out feelers before I send any patches..
Brian
Quoted 10 lines · Brian Norris
Quoted 8 lines · On Thu, Oct 9, 2014 at 9:17 AM, <[email protected]> wrote:
Hi,
It seems that slram was made for access parts of memory not used by the system, or not mapped (right terminology?). I wanted to use it on memory which is mapped or memory that can be used by the system. The problem I have is that the system I work on places a filesystem image in memory someplace, and send the physical address and size of the area as boot parameters. The memory where the images ends up is not special memory.
Quoted 2 lines
I honestly don't know much about the
slram.cdriver. I doubt it has many serious users these days.
Seems that way since both people I emailed have dead addresses.
Quoted 4 lines
It also seems like you're really trying to use this driver in a way it was not designed. Do you really need to access specific kernel memory? Or do you just want a RAM-backed MTD? There are other drivers for this already (mtdram?).
It's not very different from how it's currently used. The only difference is the memory I want to use could be used by the kernel at the time I want to use it.
I need to access a specific memory area, no random area will do. I looked at drivers/block/brd.c for example it doesn't allow a specific area to be used.
Quoted 11 lines
Quoted 5 lines
I made the following changes to your driver (somewhat condensed),
1) Added
memblock_reserve()on the memory region
2) Added aninsert_resource()call to the memory
3) Altered the driver to not use ioremap, instead use__va()conditionally.I see this comment next to the
__va()definition for ARM:/*
* Drivers should NOT use these either.
*/
That's interesting, there must be an alternative.. I just need a way to convert the address from physical to virtual.
Daniel