This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

cramfs in embedded systems

Guru 20755 points
Hello, cramfs is recommended here to be used as root file system for optimization of boot time, But there is problem with cramfs, that during application life time there are access to the flash (reading and writing). It is not recommended for real-time application to make such access to flash. It is worth Noting that this is right not only to cramfs but to any demand paging filesystem (ubifs, cramfs etc). Using root file system in RAM seems as better idea in terms of flash access, maybe with combination of ubifs section in flash in order to be able to read write from flash. I would like to know what your idea about this issue and the suggested sollution. Regards, Ran
  • Ran,

    My advise would be to use a file system in RAM which will give you faster access. In addition I would add a mount point on flash memory for saving information which you may need next time your system boots and this information can be changed during runtime. 

    Yair

  • Ran,

    If your concern is about boot time, then placing the filesystem in RAM also not going to help. Basically you've to read and uncompress the filesystem in RAM, which will take a considerable time. The better way is to use flash file systems like UBIFS.

    May I know which is the exact platform that you are going to try this?

  • Hi Renjith, Thank for the reply. It seems more important to access the RAM during execuation instead of reading from flash. If there will be only root file system in flash like ubifs, then here will be many read access to pages in flash. What do you think ? Regards, Ran
  • Ran,

    When you run an application, it the executable will be loaded to RAM and it will be running from there. Even if you are using RAM disk, it will again be loaded to the program memory. The RAM disk will be treated as a separate disk itself. Only advantage of running from RAM disk is that the load time of the application will be faster, but while running it doesn't make any difference. 

    What is the target boot time that you are planning to achieve? Which is the platform that you are going to use?

  • Hi Renjith , I am using DM8168. If I use ubifs as root file system without mounting any other file system, as I underastand the application is loaded first to RAM when executed, as you said, and because CONFIG_SWAP=n all the application pages will stay in RAM. But what about .ini file I want to use with the executable ? Is it also loaded to RAM when opening the ini file for reading? also what about /var and /tmp directories which are used by file system. Do I have control what and when things are written there ? Best Regards, Ran
  • Ran,

    Any file that you access from your application is going to get cached in the "buffer cache" which will get temporarily cached in the RAM. Even if its from RAM disk, it will still get "buffer cached". I hope I've clarified you. 

    What is the target boot time that you are targeting?

  • Hi, The target boot time we are targeting is ~5 seconds. the boot process is composed of: 1. reading application from NAND flash (but with 8 pins instead of 16), 2. load executables to hardware accelerators, and to start the streaming application in ARM. I understand what you say about "buffer cache", and it seems problematic. From our expreince with real time application we prefer: 1. All relevant files for read to be in RAM and stay there after application initialization finished. 2. we want to have control on what and when files are written into flash. From what you write it seems that this is not the case when we work with ubifs as root file system, and without mounting any other file system, and therefore it is not "real-time" from our point of view: 1. If there are pages in files that were not access till the point of initialization finished and are needed to be read after initilization (like the configuration file example I've gave) , it means that there will be access to flash for reading some pages in file at some point while application run. 2. I gave example of /var and /tmp that some information might be written there by some daemons or something else which I have no control on. Writing to flash is much worse then reading. I didn't find answer for that in what you wrote. Do I have control on things that are written there ?? Thank you very much for your time, Ran
  • Hi Ran,

    I can share you some more information. Could you please send me a mail @ renjith.thomas@pathpartnertech.com