We are developing the port of Linux to the Nintendo DS. The project is based on uClinux. We have inherited uClinux' build system and CVS organisation.
Just like in uClinux, our CVS repository contains everything (Linux kernel, uClibc C library, uClinux userland). It is very, very large (almost 1GB). It has multiple branches to keep imports of third party sources organised. I've written a page on our wiki that explains how we set things up in the repository.
Not everyone is really happy with this. While I am comfortable using CVS (since by now I know how not to shoot myself in the foot), there are a couple of things that CVS cannot do for us. When it comes to moving things around on a great scale CVS is just a pain in the ass.
Regarding the build system: Our current setup makes package management quite impractical, but people keep requesting this feature It is very hard to incorporate, because of our strong ties to the way things are done in uClinux (zero package management).
Also, there is currently only one anonymous CVS mirror. At peak times the load is very high, and people keep complaining about poor performance of the server. Making CVS use a ram disk for temporary files helped a little, but the bottleneck is really CVS's poor ability to scale to large trees.
So we are considering moving to git. I am currently investigating it and I must say that I like it much more than CVS and subversion. The way we handle branching should feel much more natural with git. Conversion from CVS seems to be very smooth, at least according to the git documentation.
Conclusion:
Changing the version control system is not a huge problem really. You can always do that. What is very hard is changing the build system. You should really consider and evaluate all alternatives you've got before going productive. The question is of course what you really want to do, and what you are starting out with.
In your case, you should probably take a look at various other Debian-based projects. You may find a suitable solution, already tried and tested.
In our case, uClinux was an obvious choice, since it included an (incomplete) port of Linux to the Gameboy Advance, which DSLinux is based on. Alas, it looks like we now have to live with the deficiencies of the build system.
The portions of the NVidia and ATi driver that *do* link directly to the kernel (also known as the "kernel stub"), are indeed GPL.
Apparently they aren't GPL:
/* _NVRM_COPYRIGHT_BEGIN_ * * Copyright 2001-2002 by NVIDIA Corporation. All rights reserved. All * information contained herein is proprietary and confidential to NVIDIA * Corporation. Any use, reproduction, or disclosure without the written * permission of NVIDIA Corporation is prohibited. * * _NVRM_COPYRIGHT_END_ */
This is from the top of a file called nvidia_linux.c from the nvidia driver stub version 1.0-8762.
What happens, is the closed source X driver communicates to and from the stub indirectly, not via linking.
No, what happens is that the user links the module into the kernel. As long as the user does not distribute the resulting kernel, there is no violation of the GPL.
Much easier to write it on a notebook and be able to take screenshots/videos to show the judges and not to mention sticking it on a projector
Point taken.
rather than to get them all to crowd around the one ds that you've flashed so you can run your own code on.
It could still be argued that a game designed for the DS should be presented on a DS nonetheless. The judges should take the time to give the game a spin on a real DS if they could.
And you don't need to modify (or flash, as you put it) the DS in order to run your own code. You just need extra hardware which costs about 75 Euros. See here for more info on this.
Nintendo machines are traditionally hard for established companies to get a foothold on, let alone students.
Well, I'm a student, too, and I'm working on the port of Linux to the DS. And no, we do not have an official development kit. We use gcc and tools supplied by the homebrew community.
And there are countless others who are developing games and other applications, too. I'd say most of them are students. See here
Another difference to what TFA describes and the homebrew scene is that the homebrew scene is largely open source.
Since the team couldn't actually get hold of a DS development kit, Metalheads was made on a PC using a Wacom tablet in place of a touchscreen.
Doh. They obviously haven't informed themselves well before writing the game. They could have written it for real hardware and tested it on real hardware. See here
DS Linux is a port of the Linux operating system to the Nintendo DS. The project hopes to bring the full capability of Linux to the DS, but is still in the developmental stages. The project supports a full keyboard on the touchscreen, and will allow users to send and read email, chat online, and play text-based games. (emphasis mine)
We are actually a bit further than that. Two IRC clients are available (tinyirc and bitchX). BSDgames and other text games are mostly working. The article forgot to mention highlights such as working wifi support, ssh/scp, an algebra system (mathomatic), and text-based web browsing. (To be fair, they contacted us for an interview before writing the article but it seems we were to busy to respond:P)
The biggest limitation is the lack of an MMU, which means neither paging nor swapping is possible. Hence DSLinux is a port of uClinux to the DS, not of the vanilla kernel. Our current kernel version is 2.4.16-hsc0 with an awful lot of patches and lots of new drivers to support the hardware of the Nintendo DS itself and various add-on devices (mostly storage devices using CF or SD cards).
At the moment we are stuck with 4MB RAM, which makes things a bit tricky. There is work going on to expand the available RAM from 4MB to up to 32MB for storage devices that sport on-board RAM, for example the Supercard. We also have someone on the team capable of building custom RAM expansion carts for the DS's GBA slot. Once we have more memory we'll have much more possibilities (there's talk about a GUI, for example, but that is still far off). Accessing RAM through the GBA slot involves gcc modifications, which have already been made. We still have to rewrite some of the assembly code in the kernel and the C library (uClibc). You can read more about this here if you are interested.
As you can see, this project is quite fun and challenging. Tasks on the TODO list range from shell scripting and cross-compiling applications to hacking ARM assembly in the Linux kernel. Progress is slow because we only have 3 very active developers at the moment (myself included), and some people who occasionally send patches. There is a lot of work to do. Get in touch if you are interested in helping out.
I'm still praying the Nintendo Wii will be opened up like this
I'm wondering to what degree they will "open up" though. After all this is Microsoft *and*
the console market we are talking about. You will probably not see much of the underlying
hardware:(
Another poster suggested to port the Linux kernel, which was modded +5 Funny, but
being a developer on the port of Linux to the Nintendo DS I'd consider this point
more seriously. To port another OS to the X360 you will probably still have to
rely on software hacks or even hardware mods to get things running, even if you
have Microsoft's devkit.
I'm probably stating the obvious when I say that I'd like consoles to be opened up
to a point where you can port a bare kernel easily because you have documentation
for the hardware. And not because some crazy hacker figured out how to make code
run on an otherwise proprietary platform that is shielded of as much as possible
from running custom code. I don't even want to think about all the DRM methods
vendors might employ in their next generation consoles.
Alas, I agree that what microsoft is doing here is definitely a good thing in many respects.
At least it gets some people do some coding before they wreck their brains with endless hours of game play.
I hope Nintendo follows their example, maybe even to a greater extent.
I don't think we'll need an official toolchain for the wii. There is an actively maintained multi-platform open source homebrew toolchain for GameBoy Advance, GP32, Playstation Portable, GameCube and Nintendo DS here. Adding support for the wii will just be a matter of time. Actually the guys already opened up an IRC channel for the wii, even though there's probably not much coding going on yet:)
You forgot to mention the large amount of homebrew available for the DS.
There is Linux, DOOM, Moonshell (graphical mp3/ogg and video player + picture viewer),
DSOrganize (an organizer), ScummVM, NDSmail, Python, just to name a few.
Sony fights homebrew, Nintendo doesn't seem to care. Makes the biggest difference for me.
What can you do to foil the 22 per cent rise in people out to steal your iPod? What can be done for the 22 per cent so they do not even want to think about mugging anybody,
but do something worthwhile instead?
Besides, if the guy actually had got shot in the head, would this still be about the iPod?
Seriously, why so much interest in building a walknig robot
Because our houses and cities have stairs, and people are keen on getting robots to their house to do dirty work for them. Wouldn't you like to do dirty work for a robot?
"hey, I'm a driver for [some non-removable component]. If I can't find my hardware, maybe I should print an error to ksyslogd and unload myself."
Better yet, print nothing. Linux is quite noisy while booting as is. Canned distribution kernels often print lots of messages from drivers that are not related to any hardware in the box. This is just annoying. It is solved much better in *BSD, where drivers seem to only print something once they've initialised their hardware.
a page saying nothing but "FSI INF". "FSI INF"? WTF?
Heh. That's shorthand for "Fachschaftsinitiative Informatik". Translates roughly to "Student Council of the CS department."
Slashdot Mirror
We are developing the port of Linux to the Nintendo DS. The project is based on uClinux. We have inherited uClinux' build system and CVS organisation.
Just like in uClinux, our CVS repository contains everything (Linux kernel, uClibc C library, uClinux userland). It is very, very large (almost 1GB). It has multiple branches to keep imports of third party sources organised. I've written a page on our wiki that explains how we set things up in the repository.
Not everyone is really happy with this. While I am comfortable using CVS (since by now I know how not to shoot myself in the foot), there are a couple of things that CVS cannot do for us. When it comes to moving things around on a great scale CVS is just a pain in the ass.
Regarding the build system: Our current setup makes package management quite impractical, but people keep requesting this feature It is very hard to incorporate, because of our strong ties to the way things are done in uClinux (zero package management).
Also, there is currently only one anonymous CVS mirror. At peak times the load is very high, and people keep complaining about poor performance of the server. Making CVS use a ram disk for temporary files helped a little, but the bottleneck is really CVS's poor ability to scale to large trees.
So we are considering moving to git. I am currently investigating it and I must say that I like it much more than CVS and subversion. The way we handle branching should feel much more natural with git. Conversion from CVS seems to be very smooth, at least according to the git documentation.
Conclusion:
Changing the version control system is not a huge problem really. You can always do that. What is very hard is changing the build system. You should really consider and evaluate all alternatives you've got before going productive. The question is of course what you really want to do, and what you are starting out with.
In your case, you should probably take a look at various other Debian-based projects. You may find a suitable solution, already tried and tested.
In our case, uClinux was an obvious choice, since it included an (incomplete) port of Linux to the Gameboy Advance, which DSLinux is based on. Alas, it looks like we now have to live with the deficiencies of the build system.
Correct.
Apparently they aren't GPL:
This is from the top of a file called nvidia_linux.c from the nvidia driver stub version 1.0-8762.
No, what happens is that the user links the module into the kernel. As long as the user does not distribute the resulting kernel, there is no violation of the GPL.
Much easier to write it on a notebook and be able to take screenshots/videos to show the judges and not to mention sticking it on a projector
Point taken.
rather than to get them all to crowd around the one ds that you've flashed so you can run your own code on.
It could still be argued that a game designed for the DS should be presented on a DS nonetheless. The judges should take the time to give the game a spin on a real DS if they could.
And you don't need to modify (or flash, as you put it) the DS in order to run your own code. You just need extra hardware which costs about 75 Euros. See here for more info on this.
From TFA:
Nintendo machines are traditionally hard for established companies to get a foothold on, let alone students.
Well, I'm a student, too, and I'm working on the port of Linux to the DS. And no, we do not have an official development kit. We use gcc and tools supplied by the homebrew community.
And there are countless others who are developing games and other applications, too. I'd say most of them are students. See here
Another difference to what TFA describes and the homebrew scene is that the homebrew scene is largely open source.
Since the team couldn't actually get hold of a DS development kit, Metalheads was made on a PC using a Wacom tablet in place of a touchscreen.
Doh. They obviously haven't informed themselves well before writing the game. They could have written it for real hardware and tested it on real hardware. See here
From TFA:
Go on, somebody give him a development kit.
Here you go.
The catch is that you need to tilt your monitor.
From TFA:
The installer is designed to work at a resolution of 600x800;
Our current kernel version is 2.4.16-hsc0
Doh, it's actually 2.6.14-hsc0...
From TFA:
DS Linux is a port of the Linux operating system to the Nintendo DS. The project hopes to bring the full capability of Linux to the DS, but is still in the developmental stages. The project supports a full keyboard on the touchscreen, and will allow users to send and read email, chat online, and play text-based games. (emphasis mine)
We are actually a bit further than that. Two IRC clients are available (tinyirc and bitchX). BSDgames and other text games are mostly working. The article forgot to mention highlights such as working wifi support, ssh/scp, an algebra system (mathomatic), and text-based web browsing. (To be fair, they contacted us for an interview before writing the article but it seems we were to busy to respond :P)
The biggest limitation is the lack of an MMU, which means neither paging nor swapping is possible. Hence DSLinux is a port of uClinux to the DS, not of the vanilla kernel. Our current kernel version is 2.4.16-hsc0 with an awful lot of patches and lots of new drivers to support the hardware of the Nintendo DS itself and various add-on devices (mostly storage devices using CF or SD cards).
At the moment we are stuck with 4MB RAM, which makes things a bit tricky. There is work going on to expand the available RAM from 4MB to up to 32MB for storage devices that sport on-board RAM, for example the Supercard. We also have someone on the team capable of building custom RAM expansion carts for the DS's GBA slot. Once we have more memory we'll have much more possibilities (there's talk about a GUI, for example, but that is still far off). Accessing RAM through the GBA slot involves gcc modifications, which have already been made. We still have to rewrite some of the assembly code in the kernel and the C library (uClibc). You can read more about this here if you are interested.
As you can see, this project is quite fun and challenging. Tasks on the TODO list range from shell scripting and cross-compiling applications to hacking ARM assembly in the Linux kernel. Progress is slow because we only have 3 very active developers at the moment (myself included), and some people who occasionally send patches. There is a lot of work to do. Get in touch if you are interested in helping out.
This could be a killer feature.
Indeed.
I'm still praying the Nintendo Wii will be opened up like this
I'm wondering to what degree they will "open up" though. After all this is Microsoft *and* the console market we are talking about. You will probably not see much of the underlying hardware :(
Another poster suggested to port the Linux kernel, which was modded +5 Funny, but being a developer on the port of Linux to the Nintendo DS I'd consider this point more seriously. To port another OS to the X360 you will probably still have to rely on software hacks or even hardware mods to get things running, even if you have Microsoft's devkit.
I'm probably stating the obvious when I say that I'd like consoles to be opened up to a point where you can port a bare kernel easily because you have documentation for the hardware. And not because some crazy hacker figured out how to make code run on an otherwise proprietary platform that is shielded of as much as possible from running custom code. I don't even want to think about all the DRM methods vendors might employ in their next generation consoles.
Alas, I agree that what microsoft is doing here is definitely a good thing in many respects. At least it gets some people do some coding before they wreck their brains with endless hours of game play. I hope Nintendo follows their example, maybe even to a greater extent.
I don't think we'll need an official toolchain for the wii. There is an actively maintained multi-platform open source homebrew toolchain for GameBoy Advance, GP32, Playstation Portable, GameCube and Nintendo DS here. Adding support for the wii will just be a matter of time. Actually the guys already opened up an IRC channel for the wii, even though there's probably not much coding going on yet :)
You forgot to mention the large amount of homebrew available for the DS. There is Linux, DOOM, Moonshell (graphical mp3/ogg and video player + picture viewer), DSOrganize (an organizer), ScummVM, NDSmail, Python, just to name a few.
Sony fights homebrew, Nintendo doesn't seem to care. Makes the biggest difference for me.
What can you do to foil the 22 per cent rise in people out to steal your iPod?
What can be done for the 22 per cent so they do not even want to think about mugging anybody, but do something worthwhile instead?
Besides, if the guy actually had got shot in the head, would this still be about the iPod?
Seriously, why so much interest in building a walknig robot Because our houses and cities have stairs, and people are keen on getting robots to their house to do dirty work for them. Wouldn't you like to do dirty work for a robot?
I want one with a Genuine People Personality so it can take over when I have to talk to people I don't like.
"hey, I'm a driver for [some non-removable component]. If I can't find my hardware, maybe I should print an error to ksyslogd and unload myself."
Better yet, print nothing. Linux is quite noisy while booting as is. Canned distribution kernels often print lots of messages from drivers that are not related to any hardware in the box. This is just annoying. It is solved much better in *BSD, where drivers seem to only print something once they've initialised their hardware.
a page saying nothing but "FSI INF". "FSI INF"? WTF?
Heh. That's shorthand for "Fachschaftsinitiative Informatik". Translates roughly to "Student Council of the CS department."