|  Page Type: Article
Edit this page (last editedJuly 29, 2006)
Bookmarks1: Bitsum | Wiki | Frontpage | RecentChanges | TitleIndex | CategoryIndex | UserPreferences | FindPage | HelpPage | SandBox
» Welcome » Building micro firmwares
Research and development efforts take considerable time. If you would like to encourage further work on this project, or reward work already done, please donate if you are able.
WARNING: Early in creation of page.
About
Building micro-sized firmwares has many special considerations. This page will attempt to list a few ideas on how to microtize firmwares and the design ideals that should be associated with micro sized firmwares.
Difference of ideals
The ideals between larger firmwares and micro-sized firmwares are often in conflict. Here are some of the differences:
- A micro-sized firmware should intend to be a static configuration of packages and data, not requiring or designed for post-install addition of new packages.
- A micro-sized firmware should not intend to be multi-platform in cases where optimizations for the target platform can save space. Several different platforms can be targetted in the source code, but each build should be optimized as much as possible for its particular platform.
Techniques to reduce size
- Strip unused objects from the runtime library. This can save much space, but it hinders post-install extendability, thus should not be done for firmwares that require later extension.
- Reduce size of boot loader. In the case of the Broadcom CFE, it's uncompressed size is ~256KB. To reduce this, vmlinuz style compression can be applied to the CFE. The Belkin 7230-4 does just this, and the compressed CFE size is < 128KB, freeing up 128KB of flash space.
- Strip uncommon BusyBox? utilities and extra fluff if needed. My personal preference is to preserve as much as BusyBox? as possible, but in the end it's optional. If desired you can even kill most all the shell and telnetd, so only the web UI can be used for configuration. This limits the fun and usefulness of third-party firmwares though.
- JFFS2 should usually be removed, at least for BCM43xx boards. All configuration data should be kept in the NVRAM partition of the flash. If the OS needs a writable partition, it's concievable to store and restore a ramdisk filesystem the overlays the RO filesystem and store modified data in the NVRAM area. Of course, a reset of NVRAM will invoke a reset of this data, but that's usually desired in the case of a 'hard' reset. In cases where JFFS2 is desired, for some reason (i.e. not completing the above or more space is needed than the NVRAM area offers):
- 2.4 kernel: The DYNRUBIN decoder should be removed. It's essentially unused.
- squashfs (with LZMA extensions, squashfs-lzma) should be used instead of cramfs.
Patches
Summary : Building micro firmwares
| |
|
