Should I Boot From SD Card?

Hello!

I have a 16GB SD card in my Beaglebone Black A5A. I used it to flash the on-board eMMC to Debian, then reformated it to use as extra storage. I boot from the on-board eMMC.

I’m wondering if I would be better off, in the grand scheme of things, to boot from the big SD card and just ignore the eMMC, using it only as a backup in case my SD card goes south at some point. I’d be pleased to hear from more experienced users about this choice and what course they would recommend.

Thanks.

This is what I do. Part of the reason for leaving the factory image in emmc is that my image of The Deck needs 12GB.

Hello!

I have a 16GB SD card in my Beaglebone Black A5A. I used it to flash the on-board eMMC to Debian, then reformated it to use as extra storage. I boot from the on-board eMMC.

I’m wondering if I would be better off, in the grand scheme of things, to boot from the big SD card and just ignore the eMMC, using it only as a backup in case my SD card goes south at some point. I’d be pleased to hear from more experienced users about this choice and what course they would recommend.

Thanks.

The answer is it depends on the SDCard you are using. Compare the number of write cycles for your SDCard to that of the eMMC. If the number of write cycles is the same for both devices, the eMMC will fail first because of the smaller spare capacity given the use of wear leveling. To reduce the possibility of write failure, increase the size of your storage.

http://en.wikipedia.org/wiki/Flash_memory
http://en.wikipedia.org/wiki/Wear_leveling

Regards,
John

Thanks John. I’ve read the two articles.

I have no idea of the endurance of my SD card, but it seems that I will be better off using it as the boot device in a development environment as it can be replaced when the time comes, where as the eMMC can’t, and development involves a lot of file creation and deletion over time, at least the way I do it :slight_smile: Does that sound right to you?

I guess I need to design and build my software too so that it minimizes file I/O. Is that standard practice for linux programs that I might download with apt-get, or are there some that I should avoid for that reason?

I don’t know what The Deck is John, but I doubt if I’ll ever need 12 GB. I just happened to have a 16 laying around from another project. Hard to imagine a 12GB app on a board this small :slight_smile:

Thanks for the inputs/

Thanks John. I’ve read the two articles.

I have no idea of the endurance of my SD card, but it seems that I will be better off using it as the boot device in a development environment as it can be replaced when the time comes, where as the eMMC can’t, and development involves a lot of file creation and deletion over time, at least the way I do it :slight_smile: Does that sound right to you?

I guess I need to design and build my software too so that it minimizes file I/O. Is that standard practice for linux programs that I might download with apt-get, or are there some that I should avoid for that reason?

To start with, you should try to use a read only rootfs. Search beagleboard groups as this has been discussed several times. In addition, if your app involves some sort of data acquisition or data logging, use ram based files and then only write the contents to disk on a periodic bases or when the power fails. This means you need circuitry to detect the power fail and then trigger writing all ram based files to disk and then start an orderly shutdown. Traditionally, this is done with a temporary energy source from supercaps or batteries. The circuit requires a state machine to cater for situations such as power fails during power up, or power fails and then returns before shutdown is complete.

I don’t know what The Deck is John, but I doubt if I’ll ever need 12 GB. I just happened to have a 16 laying around from another project. Hard to imagine a 12GB app on a board this small :slight_smile:

The Deck is a wireless penetration suite developed by Philip Polstra.

Regards,
John

OK thank you – I’ll look for more information on read only rootfs. I guess I should plan on avoiding on-board compilation too, since I have no way of knowing if, for example, the GNU compilers are sensitive to the disk endurance issue.

compilation time is to direct the temp files to a ramdisk. Having said
that, this is less of an issue in modern kernels, because the buffer cache
often manages to contain temp files so that they don't actually reach the
disk media. The actual situation depends on the actual memory pressure on
your system, and the specifics of your particular compile (how
large/complex are the source files, etc). Just test that.