Sunday, April 27, 2014

The Adventure of running Linux on an Amiga 1200 in 2014

A few weeks ago I've googled a little bit for the keywords "amiga" and "linux" and discovered that the m68k port of Debian is still in development and maintenanced.
I remembered trying to install a Debian 2.0 inside a WinUAE enviroment a few years ago but it somehow failed as the kernel never really came up running. At this point it was only a small test and I just said myself that the kernel maybe needs a part of Hardware which only a real Amiga has.
Looking back I assume I've forgotten to enable the MMU emulation....

Being more experienced with linux now and also in the possession of an Amiga 1200 equipped with a 68030 (with MMU!!) and 64 MB of memory I finally decided to try it again. But this time without any old prebuilt solutions.
As it turned out the only part really maintained is the Debian Ports repository. New installation CDs are not available. But this shouldn't be an issue I thought. Experienced with the Debian multistrap tool for embedded systems I've built a root file system using this repository with nearly up-to-date packages.

The official Debian Wiki for M68k gives a few hints on the installation and also distributes prebuilt kernel images. I've tried one and guess what. It actually worked and my 1200 was running linux 3.2.x!
I just had to grin while the ridiculously slow configuration process was running.... time zone ... click click ..... keyboard layout .... click click ..... discoverying network hardware........ FAILED!!!


If you are not a linux user you might don't know this but having access to a network hardware is essential for Debian. Especially if you don't have any installation CD this is the only way to install software.
So what to do now? Looking into /lib/modules I could find some drivers but none for my 3COM Etherlink III which apparently has the chip 3c589. There is actually a list of some guy about supported PCMCIA network hardware for the Amiga. My card is also listed but as an unsupported one.

The kernel of the Debian Wiki offered only about 6 network drivers and I couldn't believe these were all. So I downloaded a vanilla 3.14.1 kernel wishing I could compile it with more modules. So the pain was about to begin...

What do you need to compile a kernel? A compiler might be a good starting point. If you want to compile linux software for the m68k a m68k-linux-gnu-gcc is the right thing. Debian offers the Emdebian repository which gives quite a few cross compilers. So while browsing the package manager I've found the right thing. So cool, huh? Well no! The m68k-gcc inside the official Emdebian Repository has an unresolved dependency and couldn't be installed. I couldn't believe it. So I started to compile binutils and the gcc manually. Somehow no success. I don't want to discuss the reasons here. Some missing headers or what......
As the process of making a toolchain seemed to be black magic i tried to use crosstool-ng, a software to auto-generating gcc toolchains. So cool, huh?
Well NO! crosstool-ng doesn't offer m68k support with the normal libC. Instead only µlibC. Arghh! No! Well, I dont' care. Just build the µlibC version It might work as well. And again a stone in my way. The elf2flt repository is down and crosstool-ng is unable to build anything. What a joke!
I also tried to use a prebuilt bare metal compiler using the target m68k-elf- as I thought it wouldn't matter for the kernel. It compiled well but It crashed at the point in head.S where the startup routine was about to enable the MMU. You can actually see it as the m68k port prints the alphabet on the Amiga's serial port before starting the true kernel code.
Kinda depressed about the bad shape of this part of the community I was about to stop this whole test.

But then I got one idea! I couldn't install the gcc compiler from Emdebian because the dependencies were unresolved. But not because the package was missing. It was a version mismatch between the gcc and the libgcc2. Well F*CK the dependecies I said myself and so I've force installed all needed packages and tried it again. I've compiled the kernel, installed it and then another try...... It worked......

I was proud as I've managed to get a 3.14.1 kernel running on my real Amiga. I've also selected a 3com driver and at this point I thought it was the right one. But ..... duuuh .... as I've loaded it the kernel said it couldn't find the card. I looked again in the kernel config and yes it was the wrong driver. It was for the 3c509 which is a character apart from my 3c589 and not a PCMCIA but instead an ISA card. :-(

I've filtered the kernel config for "5c589" and a driver was existing. I looked for dependencies and guess what.

Depends on: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_3COM [=y] && PCMCIA [=n]

I couldn't select the driver as PCMCIA was not enabled...... not enabled I thought??
I remembered activating "Amiga 1200/600 PCMCIA support" and here is the deal. It was handled seperatly as AMIGA_PCMCIA. I thought that this might be some configuration problem inside the kernel as I don't assume that the Amiga port was tested very well. I looked inside linux-3.14.1/drivers/net/ethernet/3com/Kconfig and changed the dependency to "PCMCIA || AMIGA_PCMCIA" and tried it again. This time the compilation failed as a few functions were not available. Looking at the source code of the PCMCIA implementation I've discovered the reason. The PCMCIA subsystem for the Amiga is quite old (I'm not even wondering) and also has a different interface compared to the normal one.

At this point I've compared both subsystems but couldn't help it. I'm not experienced enough to solve this issue and the motivation was about to drift away. I will still try it though and write about it here.

Monday, March 3, 2014

SlamyCopter Project - Part 1

I has been a while since the last serious stuff here. Since September 2013 I'm working on a quadrocopter from scratch (uuuh mainstream D:).

But a little story first. When I was 14 or 15 this thing here came out.


This is the Silverlit X-Ufo and one of the first r/c quadrocopters you could buy for private use. I WANTED it ... and got it for christmas :3 lol. Compared to the models we have today the X-Ufo was kinda strange as it uses a mechanical gyroscope in the middle to detect the angle. It was simply awful as this was quite a limitation. After you start this thing up you had to wait for about 5 seconds until it was ready which is not that bad as todays gyroscopes also want to calibrate themselfs to have less drift. But bad is the limitation of the angle as .... if i remember correctly .... about 10 degrees are the maximum for every axis. And not only bad but quite frustrating is the tendency to failure. The mechanical gyro was deactivated if to much g-force was applied horizontally. This always happend if you move in one direction and then flipped the joystick in the other direction very fast. The resulting negative acceleration was to much for the little gyro which stopped rotating. Without any stability system the X-Ufo crashed to it's doom. I got a friend having also one. His died first. My only weeks later....

So the years were going and after seeing the Parrot ARDrone owned by another friend and, some DJI Phantoms in the r/c stores and some videos on YouTube about the famous MikroKopter I was hyped again. The last important question was: Buying or Building? As I'm quite experienced in soldering, pcb design and digital circuit design I decided to give it a go. Until this point I didn't knew how much blood, sweat and money I've to spend to reach my goal.

The first part I've built is the motor controller which is based loosely on the schematics found here on the microcontroller wiki. And I have to say that these look quite similar to those of the BL-Ctrl. You can see my inspiration^^. My controller is based on IR2104S FET drivers, an ATMega88 and IRFR1205 FETs. The prototype looked like this and was tested using an old broken harddrive.

After that multiple things were done simultaneously. I've bought my R/C the Spektrum DX6i together with an AR2610 receiver while I've layouted the circuit of the brushless controller using eagle so that I could send it to the pcb manufactory which takes quite some time. The mentioned wait time was used for other planings as a frame had to be constructed. I first thought about building it with balsawood which is quite light. But some forums said it wouldn't be the ideal material for a project like that..... so i sticked to 10mm aluminium profiles from the hardware store.... like everyone else. Some big inspiration was Thomas Pfeifer and his quadro project here.
Sadly I don't have any photos to show here from this time...

Also I needed a cental controller which contains the "intelligence". A friend of mine suggested using the STM32F4 Discovery which he had lying around at the moment. Normaly the NXP LPC guy i tried it out and it seemed to be a rather good board.... a little bit big but whatever. Besides the controller some sensory was needed. The quadro needs to know how angled it is as usual quadrocopters are self stabilizing. Through my work I've learnt about the MPU9150 which is a monolithic chip including an accelerometer, a gyroscope, a magnetometer and a DSP :-O. This thing is simply amazing as you don't have to do any data fusion to get the 3 sensors together. At least the manufacturer praises this.....

What is still missing? Right, the motors! I've used the MK2832-35. The inspiration coming from the MikroKopter isn't deniable. The motors are quite expensive but I'm hoping for good quality here. Bad motors tend to have some problems as this german review suggests. 

After soldering the brushless controller and building a cross out of aluminium I designed a power supply board which sticks under the STM32F4 discovery containing a step down to generate 5V for the discovery from the battery pack.

Speaking of batteries. The one I use is the Turnigy 4S 3000mAh 20 which gives me ~13 minutes of flight time. For charging I use a SkyRC IMAX B6 (the non fake version :3).

Then I put it all together and finally in december my first flight was possible.
At least I tried. The PID algorithm i used wasn't optimized yet. Again Thomas Pfeifer was my inspiration as I've built myself a wooden structure containing the quadro in a free rotating position at least for one axis. The videos below will explain more about it. After I've found a quite usable configuration it was time to fly.

There are still enhancements going on. GPS, a barometer, and FPV flight are the topics I'm working on at the very moment. I've prepared also a VideoBlog on YouTube. Check them out and stay tuned for more :3.

Wednesday, January 22, 2014

zprommer - Modifiction for 272001

As mentioned in a previous post I use an RR-Prommer to program my EPROMs. As the RR-Prommer is a copy of an very old EPROM Burner by Batronix I could use the linux tool zprommer which is made by zut. Please take a look here to see what it can do. It's a really cool tool if you still use EPROMs.

One problem with this tool is that it doesn't support the EPROM 272001. As my RR-Prommer mentioned support for this one I decided it must be a software issue. I modified the zprommer sources to get this to work and you can download them here.