FSG-3 Community Release

From OpenFSG
Jump to: navigation, search

Contents

Introduction

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

Hardware

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.

Brains

See the section Interested Parties below if you have any spare time and/or brainpower to give us.

Aims

To produce and maintain a release of FSG-3 firmware using contemporary technologies, notably:

Everything used must be open-source. No proprietory stuff allowed - even if licensed. The current Twonky situation is to be avoided at all costs.

Wish List

Not necessarily included, and almost certainly not in first release. To be voted on!

Working Title

Simply "OpenFSG" has been proposed and met with favourable reaction so far. Add your thoughts and comments to the discussion page.

Mascot

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?

Project Management

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.

First Steps

Before we can start moving forwards, we need to make sure we can reproduce where we currently are:

  1. Obtain latest beta firmware from Freecom (if we are going to build on that foundation)
    • (in fact, obtain and archive copies of all versions)
  2. Document process for setting up compile tools
  3. Document the build process
  4. 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?

Compiling

Changelog

Always up to date ChangeLog from our SVN Repository: [1]

Interested Parties

Please add your name to the list, along with your level of interest. Suggested role names include:

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.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox