I am an open source developer. I purchased a NetWinder because I feel that this type of machine has a big future in many vertical markets. It is an concrete existence proof that open source software leads to innovation.
I plan to use the machine to demonstrate new possibilities to my clients
and to help them "think outside the box" when architecting new systems.
I also plan to make it a second platform for testing purposes and
binary releases. I will probably write some demonstrations for the
NetWinder that take advantage of it's unique hardware.
Here is what I've produced for downloading:
Downloads
Links
This section contains pointers to resources that I've made use of and recommend to others starting out with the NetWinder. It's also got links to other Web resources I've created.
I can be reached at brianbr@ibm.net.
NetWinder Review
An excellent experimental machine with fascinating hardware and good long term prospects as long as Corel can "go the distance."
At this writing (September 1998) all aspects of the machine are in rapid evolution:
What shipped to me on September 15th was:
All of the software is available on the ftp.netwinder.org site at these links: NeTTrom, 2.0.31Kernel Source, Disk Image, and Packages. The kernel source is basically "read-only" because a) you need an a.out configured cross compiler to build it, and b) it can only be safely tested using bootp or an external hard drive. The NetWinder Rescue HOWTO contains more details. There is also little point in mucking with these because a sparkling new version will be out real soon now.
My understanding (could be wrong!) of the soon to be coming release is:
The "experimental" Nettrom can be found on San Mehat's page http://www.netwinder.org/devel/notes/sanm.html.
The experimental kernel is in ftp://ftp.netwinder.org/pub/ccc/kernel. Modutils that go with it are in ftp://ftp.netwinder.org/users/p/patb/modutils-2.1.107. The set_therm and read_temp that go with it are in ftp://ftp.netwinder.org/users/w/woody/therm3. You need to carefully read the instructions at http://www.netwinder.org/~ralphs/knotes.html before installing the new kernel. Installing the new modutils is particularly risky because the floating point emulator cannot be loaded with the new insmod. You need to keep the old insmod under a different name (eg: /sbin/insmod.aout) and modify /etc/rc.d/rc.sysinit to use the old one when loading the fpe. There are a number of other init files in rc.d and rc.init.d that need to change to load new modules instead of old ones. Change "insmod /lib/modules/..foo.o" to just "insmod foo". The new insmod is smart enough to find the right versions. The other change is that the device number for /dev/therm has changed to 10 131 from 102 0.
I used the configure option arm-unknown-linux-gnu for the modutils build. I didn't recompile read_temp and set_therm, but used the binaries given.
There is still no experimental version of the disk image publicly available, but it should be announced real soon now.
Experimental development tools are in ftp://ftp.netwinder.org/pub/contrib/unsupported.
While rapid progress is clearly visible, the transition period is a little rough. With literally everything changing at the same time, it's hard for anyone, including CCC, to put together a system where all of the pieces are in sync.
The original system was based on aout and the new one is ELF based.
Anyone who went through this transition with RedHat will know that this is
a tricky update. CCC staff and a few selected outsiders are running test
versions of the new release, so some of the things uploaded to netwinder.org
do not run at all or have problems for the rest of us.
News
The number of alignment fix-ups reported by the new kernel is in the millions. "cat /proc/cpuinfo" gives a count. I still consider this a compiler problem. Many C programs (especially for graphics) are written for speed over portability. The alignment trap increases portability at the expense of speed. Fixing the compiler increases portability with a negligable speed penalty. Writing ARM specific versions of X windows and application code is work that will never finish.
Glad I didn't install the experimental bash RPM. It toasts the boot process by trying to use the FPE before it is loaded.
I also gained some new problems from installing the experimental RPMs (these started with the old kernel and didn't change with the new one)
Next step...replace all the old a.out binaries. This should increase stability and, more importantly, make it possible to identify which things are real problems with the experimental RPMs instead of just blaming strangeness on the a.out/ELF mix.
I used the glibc from ftp.netwinder.org/pub/contrib/unsupported with the following 'configure' options:
The egcs I installed was egcs-1.1b with the patches from Phil Blundel (http://www.tazenda.demon.co.uk/phil/armlinux). Configure options were:
C++ programs that reference libstdc++ fail at the ld phase with a message that 'exception virtual table' was an undefined reference. Phil Blundel is looking into the cause. The problem could be either in the compiler or in ld.
I am part way through installing RPMs. The first sticking point was getting RPM itself installed. I was unable to build RPM from the supplied source tarball using the compiler and setup from diskimage 1.1b. I think it was a problem with static linking. In any event, one of the tarballs I found had the binary sitting in it, so I ran that to install the actual RPM. I had to fiddle with the rpm configuration files to get this to work.
To make this easier for those who follow, I've uploaded a binary tar.gz of rpm 2.5.2 as installed from andrewm's RPM files. It's at ftp.netwinder.org/users/b/brianbr/rpm-2.5.2-arm.tar.gz.
To use:
I've gone about as far as I can go right now without excessive --nodeps use. My next step is to recompile glibc and get ecgs working.
For the benefit of those now ordering or waiting, it took 22 days from the date of my order until I had a working machine. This is on the fast side of my experience with other mail order hardware vendors. CCC needs to improve it's estimates, however.
I'm not yet out of the woods yet on the hardware front, however. The machine fails 4 out of 8 of the diagnostics tests shipped with the latest NetWinders. It looks like all the failures are due to software incompatibilities, but I won't know for sure until the next "official distribution" is out. The most serious problem is that the temperature sensor cannot be read or the thermostat set reliably. As a consequence, the fan nevers goes to high speed and I only run the machine for limited periods at a time.
I currently have two goals. First, catch up to the "state-of-the-art" so I can contribute to the next distribution release. I'm installing andrewm's 5.1 RPMs.
Second, I'm looking into writing a userland utility that can "reset" the thermostat chip so that I can leave my NetWinder running. I don't know if just resetting the chip will work or if I will finish before the new release obsoletes my work, but it's a good way to get my hands dirty with the hardware.