* Q: file system for embedded [not found] <CAJ2oMh++ji7YBrx6UcLdhPVDmLuTZCr8kGQR8aEAYWyob_ccBQ@mail.gmail.com> @ 2012-06-13 21:31 ` Ran Shalit 2012-06-14 8:34 ` Christophe Aeschlimann 0 siblings, 1 reply; 4+ messages in thread From: Ran Shalit @ 2012-06-13 21:31 UTC (permalink / raw) To: linux-embedded Hello, I hope you can help main understand issue of file system for embedded linux. I read free-electrons "Embedded Linux system development training" and some of the files recommended there such as cramfs, are aceesing the flash during execution of apllications. As far as I understand accessing the flash after initilization is not good in embedded system. Is there something here that I am missing ? Thanks, Ran ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Q: file system for embedded 2012-06-13 21:31 ` Q: file system for embedded Ran Shalit @ 2012-06-14 8:34 ` Christophe Aeschlimann 2012-06-14 12:58 ` Ran Shalit 0 siblings, 1 reply; 4+ messages in thread From: Christophe Aeschlimann @ 2012-06-14 8:34 UTC (permalink / raw) To: Ran Shalit; +Cc: linux-embedded Hi, Le 13.06.2012 23:31, Ran Shalit a écrit : > Hello, > > I hope you can help main understand issue of file system for embedded linux. > I read free-electrons "Embedded Linux system development training" and > some of the files recommended there such as cramfs, are aceesing the > flash during execution of apllications. As far as I understand > accessing the flash after initilization is not good in embedded > system. Define not good... some applications requires write accesses to the flash. (how would you program music in your MP3 player ? Where do you store crash dumps so they are persistent across reboot ? Where do you store your user configurable options, etc.) There are different kinds of flash memory but each have a limited number of program/erase cycle so you have to use them sparingly. (e.g. make sure the write accesses are distributed across the chip that's called "wear levelling", detect when bits have toggled and correct the error using some extra redundancy stored in the out-of-band area of each block (e.g. ECC). If the error cannot be repaired mark the block as unusable. When you access the bare memory chips then these issues are solved in the different layers of MTD [1] and the specific flash file system [2] : JFFS2, UBIFS, etc. If you don't access the bare memory chips e.g. you use eMMC or an SSD these problems are left to a dedicated controller/firmware. [1] http://www.linux-mtd.infradead.org/index.html [2] http://elinux.org/File_Systems Best regards, -- Christophe Aeschlimann Embedded Software Engineer & IT Manager ACN Advanced Communications Networks S.A. 2000 - Neuchâtel, Switzerland Tel. +41 32 724 74 31 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Q: file system for embedded 2012-06-14 8:34 ` Christophe Aeschlimann @ 2012-06-14 12:58 ` Ran Shalit 2012-06-14 14:48 ` Christophe Aeschlimann 0 siblings, 1 reply; 4+ messages in thread From: Ran Shalit @ 2012-06-14 12:58 UTC (permalink / raw) To: Christophe Aeschlimann; +Cc: linux-embedded On Thu, Jun 14, 2012 at 11:34 AM, Christophe Aeschlimann <c.aeschlimann@acn-group.ch> wrote: > Hi, > > Le 13.06.2012 23:31, Ran Shalit a écrit : > >> Hello, >> >> I hope you can help main understand issue of file system for embedded linux. >> I read free-electrons "Embedded Linux system development training" and >> some of the files recommended there such as cramfs, are aceesing the >> flash during execution of apllications. As far as I understand >> accessing the flash after initilization is not good in embedded >> system. > > > Define not good... some applications requires write accesses to the > flash. (how would you program music in your MP3 player ? Where do you > store crash dumps so they are persistent across reboot ? Where do you > store your user configurable options, etc.) > > There are different kinds of flash memory but each have a limited number > of program/erase cycle so you have to use them sparingly. (e.g. make > sure the write accesses are distributed across the chip that's called > "wear levelling", detect when bits have toggled and correct the error > using some extra redundancy stored in the out-of-band area of each block > (e.g. ECC). If the error cannot be repaired mark the block as unusable. > > When you access the bare memory chips then these issues are solved in > the different layers of MTD [1] and the specific flash file system [2] : > JFFS2, UBIFS, etc. > > If you don't access the bare memory chips e.g. you use eMMC or an SSD > these problems are left to a dedicated controller/firmware. > > [1] http://www.linux-mtd.infradead.org/index.html > [2] http://elinux.org/File_Systems > > Best regards, > > -- > Christophe Aeschlimann > Hi Christophe, Thanks for the reply. I have no need to write to flash during the main application execution: I will program the configuration and executable before start of execution, and after initialization there is no need to write again to flash. What I still do not understand is why cramfs, ubifs are recommended for embedded if they access the flash. Is accessing the flash not a problem in embedded linux ? What does it mean using mlockall with cramfs ? Regards, Ran ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Q: file system for embedded 2012-06-14 12:58 ` Ran Shalit @ 2012-06-14 14:48 ` Christophe Aeschlimann 0 siblings, 0 replies; 4+ messages in thread From: Christophe Aeschlimann @ 2012-06-14 14:48 UTC (permalink / raw) To: Ran Shalit; +Cc: linux-embedded Le 14.06.2012 14:58, Ran Shalit a écrit : > Hi Christophe, > > Thanks for the reply. > I have no need to write to flash during the main application > execution: I will program the configuration and executable before > start of execution, and after initialization there is no need to write > again to flash. How are you going to program the flash ? Which initialization ? > What I still do not understand is why cramfs, ubifs are recommended > for embedded if they access the flash. For the reasons I gave in my previous email. I never used cramfs but I see that it is a read-only compressed format (like supported in JFFS2) which decompresses your data on-the-fly before read/execution hence allowing to store more information if your flash is small. > Is accessing the flash not a problem in embedded linux ? I'm not sure what you mean here. It's not a problem, but it requires some care. > What does it mean using mlockall with cramfs ? Well if you don't have swap enabled mlockall has no effect since there is nowhere to swap anyway. But I'm not sure I understand your question. > Regards, Ran Regards, -- Christophe Aeschlimann Embedded Software Engineer & IT Manager ACN Advanced Communications Networks S.A. 2000 - Neuchâtel, Switzerland Tel. +41 32 724 74 31 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-06-14 14:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAJ2oMh++ji7YBrx6UcLdhPVDmLuTZCr8kGQR8aEAYWyob_ccBQ@mail.gmail.com>
2012-06-13 21:31 ` Q: file system for embedded Ran Shalit
2012-06-14 8:34 ` Christophe Aeschlimann
2012-06-14 12:58 ` Ran Shalit
2012-06-14 14:48 ` Christophe Aeschlimann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox