FSG-3 Community Release
|Following the instructions or suggestions in this article may void your FSG Warranty.|
The idea is to take responsibility for the FSG-3 firmware and, as a community, further develop and enhance it. Although the FSG-3 is the primary target, DTG and NDP support will be designed in from the start.
Please add your thoughts and comments to this page, along with any areas of expertise you might be able to contribute.
The whole thing started with this forum thread. In summary, FreeCom have no plans to further develop the firmware and we've decided to pick up the ball and run with it, instead of just moaning about it.
Call For Help
If you have an FSG, DTG or NDP that's just collecting dust at the moment, consider donating/lending it to the project? Our primary units are generally in live use and can't readily be taken out of action for development. Lack of hardware is likely to be the largest roadblock to progress.
See the section Interested Parties below if you have any spare time and/or brainpower to give us.
To produce and maintain a release of FSG-3 firmware using contemporary technologies, notably:
- Linux 2.6 kernel
- Apache, including full scripting support
- Telnet, FTP, SSH.
- Out-of-the-box functionality
- Comprehensive web-based administration
- Other opensource media servers?
- Webcam support is a must-have
- to be continued
- FSG (with or without WLAN)
- ALL known WLAN PCI cards used in FSGs
- FSG (with or without WLAN)
Everything used must be open-source. No proprietory stuff allowed - even if licensed. The current Twonky situation is to be avoided at all costs.
Not necessarily included, and almost certainly not in first release. To be voted on!
- Support for SSH-controlled runlevel zero to allow for drive-cloning.
Simply "OpenFSG" has been proposed and met with favourable reaction so far. Add your thoughts and comments to the discussion page.
Submissions are invited for a suggested mascot for the project. No reason, just a bit of fun. Absolutely open to all ideas - any artists out there?
General Design Considerations
Build upon the existing RedBoot structure. It works, and it's a great way to recover from disasters.
Do we use a copy of the current "official" firmware as the foundation? Or more to an already-maintained more generic release such as OpenWRT or Debian?
Like any good opensource project, this will only work if it's managed. Not in terms of telling people what to work on, but in the way in which the work is done and submitted to the project. Setting up a CVN repository (or do we just dump it on SourceForge?) and a BugZilla system would be a good start. Documentation is important, and Wiki systems are ideal for that.
Before we can start moving forwards, we need to make sure we can reproduce where we currently are:
- Obtain latest beta firmware from Freecom (if we are going to build on that foundation)
- (in fact, obtain and archive copies of all versions)
- Document process for setting up compile tools
- Document the build process
- Document process for preparing a .bin upgrade file for the device
Alternatively we could decide to abandon the supplied FSG firmware altogether and join the OpenWRT project, play with Debian, or even look at adapting the NSLU2 release. Any other ideas/options to be looked at? Is there another Linux release out there aimed squarely at low-power embedded devices?
Always up to date ChangeLog from our SVN Repository: 
Please add your name to the list, along with your level of interest. Suggested role names include:
- User - I'd just like to use it. There is no problem with just wanting to be a user. Without people wanting to use it, there would be no point!
- Beta - I'll take an early release to help evaluate it.
- Test - I'll actively test pre-beta releases and provide feedback.
- Cont - I'd like to contribute some of the code.
- Lead - I'd like to help guide the project.
It's assumed that each level include the responsibilities of those above it. So if you volunteer as a contributor, you'll also be expected to test, etc.
- Juansa - Test. My code and linux knowlenge is poor.
- Jo-master - Cont, Help to Lead (Currently i begin with the rebuild and can answer your developer questions.) (I bought a FSG only for tests so i will start them next weeks)
- Kenpem -
Cont for sure, possibly Lead if we don't have at least two other volunteers.Have had to downgrade to Beta for a while, very little time on my hands at the moment.
- Andohl - Test/Cont.
- Valkenier - User , maybe Beta, although I'm relying on my DTG as main router/NAS. I really appreciate your goals/initiaves!
- Hiljolodewijk - User, Cont. I've already developed a new administration interface for my NDP with cron abilities and file management and reboot and shutdown function. This one can be translated to English (from Dutch) and can be extended.
- lit - User, Beta, Test - only using as wireless access point connected to router with dd-wrt
- xenophage - Cont - don't trust my DTG any more as a gateway, so going to use it like a linux server box. Also interested in fixing/replacing the chronic web interface. Also need ruby scripting.
- Dragon - User, Poss test/Beta but will see.
- zetetic - Test, Hopeless at coding,more a hardware dude.I have a spare fsg to abuse
- TTC - User, Cont, Translation, Documentation: Currently short on time. I like to support the Open idea of the FSG3. As I have only one (which holds my valuable data) I do not dare to do anything that spoils my FSG3. But I am willing to deploy some Apps, use them, write some documentation. If you need translation from English to Deutsch or vice versa: I am your man. For any action: Drop me a private message in the Forum! (If time allows I'll look there regularly...) Keep the wheels rollin'!
- Daniel Ellis - Beta/Test (if no risk of bricking the device). Possibly code if build environment is simple enough, and there is a simple issue for me to get started with.