We have 2MB of battery backed up RAM, which is not a part of the system RAM.
We want to put a filesystem on this and use it as persistent memory (like
Flash filesystem but on RAM). My options (?):
-
use devf-ram. In this case we would have to buy the Flash TDK 
-
use devb-ram. Iām not sure if this possible. A quick look at the
documentation didnāt reveal me how to give the address space (i.e. no
parameters for that).
-
Use the RAM file-system driver in Robert Krtenās book āThe QNX cookbookā.
Do people use this in real life applications? I suppose Iād have to do at
least some adaptation here. I already bought the book.
Any other Ideas? In case of battery buffered RAM, should the filesystem be
āpower fail safeā, like flash filesystems normally are?
I would really appreciate any help. Our board is an embedded SBC with
renesas sh7760 processor and we are using QNX 6.3 with SP1.
Regards,
Martin
Martin Nylund wrote:
- use devb-ram. Iām not sure if this possible. A quick look at the
documentation didnāt reveal me how to give the address space (i.e. no
parameters for that).
There is a (undocumented) āram address=ā option; you give a physical address
which the driver will mmap_device_memory(). Presumably youād have to modify
your startup or similar to inform the system of the existence of this
memory but make it unusable for normal kernel allocations.
āJohn Garveyā <jgarvey@qnx.com> schrieb im Newsbeitrag
news:daeejg$buu$1@inn.qnx.comā¦
Martin Nylund wrote:
2. use devb-ram. Iām not sure if this possible. A quick look at the
documentation didnāt reveal me how to give the address space (i.e. no
parameters for that).
There is a (undocumented) āram address=ā option; you give a physical
address
which the driver will mmap_device_memory(). Presumably youād have to
modify
your startup or similar to inform the system of the existence of this
memory but make it unusable for normal kernel allocations.
Thanks John, That solves the issue with devb-ram. I wonder why the parameter
is undocumentedā¦