http://www.rockbox.org/ is a portable music player software/firmware
Just recently, it was announced that the guys now have a Rockbox port with working sound on the Mini 2440 device. So it seems this port is already in a quite advanced state with most of the Rockbox functionality in place. The Rockbox Mini2440 page lists USB and SD drivers as notable missing pieces. So there’s still room for you to join in and help out!
Congratulations guys!
Michael “TheSeven” Sparmann is one of the primary magicians behind the recent linux4nano efforts and he has done a lot of the Rockbox port for the iPod Nano 2nd generation.
Some 10 hours or so he posted this neat picture:
… showing off custom code running on an iPod Nano 4th generation. If you want to keep track of his/their work on recent iPods, follow @linux4nano on twitter. I do!
While this is not yet Rockbox on the device, this is a least proof it can be done and this could indeed be seen as the first tiny steps towards a full port! Good job Michael!
On ebay there’s a fancy S3C244-based board named mini 2440 with a 3.5″ touch LCD attached on sale for 85 USD. 64MB ram, 400MHz CPU, a nand flash and more. Lots of stuff for the money.
The guys in the lyre project seem to have adopted this as yet another hardware platform to attempt to run Rockbox on. After their Atmel AT91SAM target was ditched, they went the ARMopendous route and now this seems to have entered. This third hardware platform is called the Lyre prototype 2…
You should note that this Mini 2440 board has no batteries or anything and thus is not really meant to be a portable device in this shape.
“Bob” seems to have initial Rockbox code running on this device, and well-established Rockbox hackers JdGordon and domonoky have both ordered their own kits so the future looks bright.
Hey, it’s really about time to nominate your favourite Free Software persons and projects from the nordic region for the 2009 awards before the time runs out.
This year, I decided to nominate the following “nordic” heroes:
Simon Josefsson
For his excellent work in GnuTLS, libssh2 and a bunch of other projects.
Henrik Nordström
For his work in the Squid project, and his efforts within IETF and its HTTP related struggles and more.
Björn Stenberg
As the primary founder of the Rockbox project. He started somehting special back in 2001 that now is a huge, thriving and succesful Free Software project.
As you might spot, I favor “doers”. I don’t believe in the concept of “nordic projects” when it comes to free or open software – the entire concept of open and free should mean that projects cross borders and regions.
In fact, it feels so out of the ordinary to think about open source people in a geographical context I find it hard to come up with a lot of names. It would be cool if ohloh had some ways to list people and projects based on where people live.
Then again, if a person from a nordic country moves somewhere else, is he or she still a nordic person? Does it depend on where the person lived during the actual act? Is Linus Torvalds a nordic person since he was born, lived many years and started his big project in Finland?
(yeah I already blogged about this subject but hey, it can’t hurt can it?)
Robert Menes held a talk at the NYLUG a while ago about the Rockbox project:
I started out the talk by giving a little background on Rockbox; basically how it started, how it was ported around to new targets, and how the community grew as interest peaked. I showed off features of Rockbox, as well as supported targets, nearly supported targets, and even in-progress targets. I then went into describing Rockbox’s features in greater detail, and then a run-down of the development process, as well as how to compile your own builds. Many people asked questions along the way, so I answered them as they were asked. I also think that people were probably shocked at the sheer amount of targets that were shown off (nearly 40 DAPs were there!)
The 76 minute (1.6 GB) video from that event is available from the download.rockbox.org mirrors. Set your video player to stream from there unless you really want to download that entire thing!
Some owners of the Sans
a Clip player from SanDisk noticed that it does playback of all songs with a minor pitch. Due to a flawed HW setup they don’t do a proper 44,100 Hz but instead 43,791 Hz (0.993 times the target value) or something like that. According to some sources this problem might be fixed in the Sansa Fuze players now.
Bugs aren’t really so surprising, perhaps what is surprising is that this bug has been around now for almost two years. To make matters worse, SanDisk now decided that due to them making cheap players people shouldn’t expect them to be very good sound quality wise and therefore they can simply not fix the problems:
due to trade-off decisions that were made in engineering these products to deliver superior consumer value at what we believe are extremely attractive price points, our sound fidelity isn’t perfect. We have re-evaluated the possibility of reducing the pitch variation and due to the engineering trade-offs the decision was made to stay with the current design. Very few listeners, however, have noticed or complained about it as an issue in actual practice. For those who can detect sound differences with their naked ears during actual use and not via frequency analysis, our products may not be the best choice for them.
Clip owners out there now put their hope even more on Rockbox for Clip.
Several sites in the haxx.se domain and other stuff related to me and my fellows were completely offline for almost 50 hours between August 24th 19:00 UTC and August 26th 20:30 UTC.
The sites affected included the main web sites for the following projects: curl, c-ares, trio, libssh2 and Rockbox. It also affected mailing lists and CVS repositories etc for some of those.
The reason for the outage has been explained by the ISP (Black Internet) to be because of some kind of sabotage. Their explanation given so far (first in Swedish):
Strax efter kl 20 i måndags drabbades Black Internet och Black Internets kunder av ett mycket allvarligt sabotage. Sabotaget gjordes mot flera av våra core-switchar, våra knutpunkter. Detta resulterade i ett mer eller mindre totalt avbrott för oss och våra kunder. Vi har polisanmält händelsen och har ett bra samarbete med dem.
Translated to English (by me) it becomes:
Soon after 8pm on Monday, Black Internet and its customers were struck by a very serious act of sabotage. The sabotage was made against several of our core switches. This resulted in a more or less total disruption of service for us and our customers. We have reported the incident to the police and we have a good cooperation with them.
Do note that you could keep track of this situation by following me on twitter.
It’s good to be back. Let’s hope it’ll take ages until we go away like that again!
Update: according to my sources, someone erased/cleared Black Internet’s core routers and then they learned that they had no working backups so they had to restore everything by hand.
Recently we’ve seen progress by the linux4nano guys in their quest to get custom code to run on an Ipod Nano 2nd generation. They’ve apparently managed to extract the bootrom off a 2nd gen ipod nano (my copy of their extracted data is here – a reminder on objdump usage: “arm-elf-objdump -D --target binary -marm [file]“). I believe their intent is to port Linux to the newer ipods. Possibly ipodlinux. They do mention providing the necessary info to Rockbox and yes we will welcome it.
A large crowd of Rockbox hackers have joined their IRC channel and have been hanging out with them and helped out discussing ideas and pushed them towards publishing their news and infos on how this all is accomplished etc. Their SVN repo hosts some (most?) of the tools made so far.
The Rockbox wiki page for nano2g has been updated and hopefully it will keep track of what happens.
There have been speculations, but I don’t yet know based on what facts, that this recent news and hacks will be usable on other recent (encrypted) ipod models.
Summary: very interesting progress has been made. Lots of it is still left to figure out. There seems to be a bunch of skilled people around and now we’re seeing information and documentation for this getting published so I can’t but to hope for a bright future!
It was time to make an overhaul of our distributed builds system for Rockbox. The one currently in place is quite fancy and it does build 106 builds in around 7-8 minutes, but during the years it has served us we have found a few areas where we want to improve.
The goals for the new system were primarily:
The biggest weaknesses of the existing system:
The new system is currently in development. It consists of a server that runs on one of our main servers, and there’s a client script that each volunteer contributor runs on their systems.
The clients connect to the master on a dedicated TCP port, specifying user name, password, name of the particular client instance, what particular architectures the client can build and how many bogomips the client boasts. While bogomips is a bogus way to measure anything, we’ve started out using it for a rough way to sort the the build clients based on speed.
The clients keep connected to the server all the time. There’s a ping message from the master every N second of idleness to make sure the connection is kept alive. As soon as the master wants the client to do a build, it sends a message to it detailing exactly how it should build it and using what SVN revision. The client will then do the build at once, upload the results using HTTP to a dedicated place and then tell the server the build is complete.
The server knows about all builds to do at a commit, what we call a build round. It has a rough “score” or “weight” for each build that grades them in a slow to fast order. When a build round starts, the server will first sort all builds based on number of times they’ve been handed out and as secondary sort key the “weight” of it. Then it loops over the currently connected build clients and hand out builds from the sorted build table. The server then continues to do that until all clients have three builds each to build. As soon as a build is reported to have been completed by a client, that client will get the next build from the sorted build list.
If a client connects to the server and the server deems the client to be too old (since it does specify its version in the handshake message), it will be told to update to a specific version instead and come back then. This way the server can update all build clients when important things are fixed.
The clients will soon start to get assigned builds that already have been assigned to another client. This is not a problem but in fact our intention. The client that completes the build first will simply tell the server, and the server will then tell all the other clients that build that same build that they should cancel that particular build.
A client that joins the server in the middle of a build round will simply get a bunch of builds immediately and join in. A client that disconnects during a build round simply won’t complete its builds and other clients will instead do them. The system is also tolerant against the fact that bogomips is lame to compare computers with, and that the build “score” may not be very accurate or even that some server will have very slow or very fast upload speeds at unpredictable times.
The build master itself does not know when to start a new build round. It simply knows about the concept and it knows how to tell clients to complete a round. To make the master to start a new round, you need to connect to the server’s listening port and issue a special command and provide a password and then you can tell the server to start a build of a specific SVN revision. Or to queue up a build to be performed after the current one if there happens to be one in progress already.
When a full build round is complete, a hundred or so builds have been done, and full packages and log files are now in a directory on the build server, the server will simply trigger an external script that then takes care of updating our build table etc. In fact, every single completed build will optionally trigger an external script to allow web pages or stats pages to get updated as we go.
This build system is currently pretty Rockbox-specific as this is the project and development system we’re writing this for, but there’s really nothing in this that must be this way. I’m sure that if someone (you?) wants to adapt this for another project, I’d be more than happy to assist and to help ensuring that this becomes a more generic distributed build system. Just raise your hand and step forward!
At the time of this writing, (primarily) me and Björn are still ironing out quirks in this new system to hopefully get it going live real soon…
The Rockbox team that gathered in Ghent for this weekend of talk, hacking and socializing (drinking beer) is caught on this group picture. Click the image for a slightly larger version. Photo by Petur.
The people on the photo
The top line from the left: amiconn, markun, bertrik, gevaerts, GodEater, AlexP, Zagor, domonoky, Bagder (me!)
The lower line from the left: kugel, pixelma, scorche, petur
We did have a 2-hour discussion session on the saturday, and I expect to post an mp3 of it later on. The short and compressed outcome in plain text is found here. Petur was a great host. The facilities were nice, the hotel was great, the food arrangements worked out perfectly. A swell weekend!
As our tradition demands, we did bring out all our targets (portable music devices that can run Rockbox or at least have some code in the Rockbox repo) to be used as building bricks to create a Tower of Rockbox.
This first picture shows that we have a pretty wide selection of players in this room:
With all those “bricks” put in an imaginative order on top of each other, the result could look something like this:
you may enjoy comparing this building with last year’s creation.
More pictures from this year can be found in Petur’s collection and gevaerts’ collection.