Understanding the MOD5441X file system

Discussion to talk about software related topics only.
SeeCwriter
Posts: 606
Joined: Mon May 12, 2008 10:55 am

Re: Understanding the MOD5441X file system

Post by SeeCwriter »

The file MX29GL256F.h is used in numerous example programs. The one I used is still in v2.9.4 in examples\MOD5441X\EFFS-STD-SpeedTest. I don't remember why I used that particular example. And I'm sure I didn't realize that the same file would be different in different examples.

However, before I dive into trying to change the file system size I need to determine if it's needed. The only reason I'm looking into this is because I will need to store certificate and key files when SSL is implemented. Since the file system is 128k, is that sufficient room for these files plus about 10k for SNMP files? If not, or if it's too close to call, would the default of a 1.3MB file system be adequate?
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Understanding the MOD5441X file system

Post by TomNB »

I checked all of the file occurrences of MX29GL256F.h, and you are correct in that in the speed test file system size is 25M. This is unique because the purpose is a speed test of the file system.

But it would not matter where you started, 1.3M or 25M, changing the FS_SIZE parameter to 4 blocks would have resulted in the same outcome: your file system size would only be 128k because 2 blocks are descriptors, and 1 is required to be free for the fs to function.

//#define FS_SIZE ( 25*1024*1024 ) // amount allocated to file system, including descriptor blocks
#define FS_SIZE ( 4*BLOCKSIZE ) // amount allocated to file system, including descriptor blocks

Anytime the file system parameters are changed the get free space function should be run and the numbers checked so the expected file system size can be confirmed. That is the only way I would feel comfortable the code I wrote is doing what I want it to.

Regarding the size you need, I don't think anyone can answer that question without having the files and testing it. Again, the get space function must be used to see where your at. I would like to note that we do have an example on uploading a cert to the file system. In no way should this example be interpreted as knowing the file size of the certificates you may use. If you do not test with the actual certificates there will always be the possibility of a problem.

I think the next step would be get everything you need to store and verify it fits. Then, and I think most importantly, make a determination on the worse case scenario for maximum size based on what you might do in the future. Some things to consider, does your product:
- Only store a server eed the server cert
- Do you need to store a certificate authority cert
- Do you need to store a client cert?
- Do you need to store a backup/default cert?

These are worse case considerations. Sounds like you only need a server cert. If so, that should be part of your spec.
SeeCwriter
Posts: 606
Joined: Mon May 12, 2008 10:55 am

Re: Understanding the MOD5441X file system

Post by SeeCwriter »

All valid points. I'm looking at the SslOnboardCertGeneration example, which is supposed to store a cert & key "on the module", and there are no files related to the file system. In my project I have FS_FileSystemUtils.h/cpp, MX29GL256F.h/cpp, and I have to call a function to initialize the file system before I can use it. Why is none of that in the example?
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Understanding the MOD5441X file system

Post by TomNB »

There are a number of options for handling certs, and not everyone wants to use a file system. While you have 32MB of flash, we also run on single chip solutions with only 256k of flash. Although the smaller platforms use 4k blocks instead of 128k blocks, some applications need every last byte of space.

For those who want to handle their own certs, whether self-signed or from a certificate authority, the easiest way is to use a file system and simply use the cert files. That has been our discussion up to this point, and is the recommended method for handing your own certs.

A second method is for an application to use the User Parameter bulk flash sector. No file system, so the app must handle receiving, storing and accessing the raw binary data. Sector sizes range from 128k on your platform, to 8k on smaller platforms.

Now we get to onboard cert generation. The purpose is to provide a secure communication method when you are not using your own certs, or temporarily until you do upload your own. For example, it could provide a cert in your case until you uploaded your own to your file system. Again, we don't want to force everyone to use a file system. In this case the cert is stored internally in a configuration section of flash memory. The system maintains it, and it is not intended to be accessed by a file system.

I hope that helps
SeeCwriter
Posts: 606
Joined: Mon May 12, 2008 10:55 am

Re: Understanding the MOD5441X file system

Post by SeeCwriter »

Everything you said about storage matches what I'm seeing. I added the fs_xxx file system functions to the example project, and nothing is being written to the file system. The certificate is 740 bytes, and the key is 167 bytes. Even if they were written to the file system, and were each 100-times larger, there would still be plenty of room in my existing file system. At this point I see no need trying to figure out how to change the fs size without corrupting files on fielded units.
Post Reply