Amadeus

This weekend, I have extended the DLDI calling function with GBA ROM bank switching. And done a new framework for detection of GBA RAM cards. So now the preferred type of build is DLDI, and the extended RAM is auto-detected.

With DLDI, more slot-1 devices are able to boot dslinux. And what do you do with the slot-2? Insert the Opera Memory Expansion and enjoy 8 MByte RAM.

The last weeks, there were so many questions for flash cards / slot 1 cards, that I decided to make a DLDI driver for DSLinux. Thanks to the available documentation, it was an easy task.

Enjoy!

What has Amadeus done in the last few weeks?

Well, my wife and I have bought an old farm with plenty of room for living and working. So in the next weeks, my free time for DSLinux will be limited by moving to our new location.

SirSiggi has sent me his M3CF card, and I have written an new CF driver for M3 and Supercard.

So, I think, the majority of RAM based cards has a driver now.

Pepsiman and me have found the cause of the data abort errors we suffer so many months. There was code in libgcc.a (a support library of gcc, doing 64 bit math and other mythical stuff), which was not compiled with -fpic (generates position-independent code).

This bug was fixed by modifying the toolchain. Fix is in CVS today. If you want to compile DSLinux apps, you need to update. Compile time on a fast machine is 1 hour, size on disk is 172 MBytes.

There is a preliminary toolchain for linux i386 at http://dslinux.in-berlin.de/toolchain_multilib.tbz.

Stsp tries to shrink the size by stripping the debug information from the libraries.

Can you imagine how often you start your DS and type the login sequence if you are writing software for the DS?

Yesterday, I have added autologin support for DSLinux, and enabled in the RAM-DEVEL build.

What do you think of enabling it in the other builds?

I got many comments about my last blog entry.

First of all, there was Tony who tried to test the last ram-devel on his M3 microSD. I know that this will not work; there is no need to test.

Second, I have emailed M3adapter to find a way to do a switching driver for M3CF. No response.

Third, there are comments of people who own a M3CF and are very unhappy that no driver will be written. Well, they may consider to lean me their hardware, or write the driver himself. Writing a driver without access to the hardware is no fun, and I have decided against this. Pepsiman has leaned me his M3SD and we got a M3SD driver now.

Fourth, it should be very clear to everybody that I don’t want to write drivers for DSLinux all the time. I also want to do something with applications, too.

I have set up switching (between RAM and IO) drivers for the SD-based cards from Supercard and M3. They are working fine, although there are some rumors you need a FAT32 card for M3 miniSD(?). I think these drivers are near optimum, and they can be used as a template for other RAM-based SD cardridges in the future.

For CF cardridges, I have written support for Supercard CF. I consider this driver to be an “ugly hack”, because the address-based interface of the Linux IDE driver is not well suited for RAM/IO switching.

It turned out that using this interface for the M3CF is nearly impossible due to the fact that the RAM/IO switching is doing a parasitic read from the CF data register.

For CF cards, it would be better to write an own BLK device, and leave the IDE driver alone. As I do not own any CF cardridge and no CF card and no CF cardreader, I will not waste my time until someone wants to lean me this hardware. IMHO, CF cards are a thing of the past (for the DS), and most new products will use miniSD and microSD because of the form factor.

I have also decided not to write drivers for non-GBA cardridges (like the ninjaDS) because I do not see the value and will have limited time in the future.

Instead, I will turn to the user interface and try to setup some nice applications. And I will try to use WiFi the first time;-) - wish me luck!

A long journey has come to its end… last weekend, the first linux version was booting with uses the GBA ROM space as RAM on the supercard. There were many places to convert assembler code in linux or in uClibc, and the compiler needs tweaking the code generator again and again.

Now, we have a running linux for all supercards, and 17 MByte RAM free. I am sure that there will be some fixes for forgotten bugs the next days, but basicly, the work is done.