Memory and Filesystems

From gc-linux

Jump to: navigation, search

Contents

Swap to Audio RAM

In addition to its 24M of system RAM the GameCube contains 16M that is normaly used to hold audio data buffers. The CPU cannot address the audio RAM directly so this memory cannot be used like normal system memory but it is possible to use the audio RAM as a swap device.

Kernel support: CONFIG_GAMECUBE_ARAM - Device Drivers -> Block devices -> Nintendo GameCube ARAM

Create the device node for the audio RAM driver

Enter the following command as root.

cube# mknod /dev/aram b 37 0

Tell the kernel about the swap device

Add the following line to /etc/fstab:

/dev/aram       swap            swap    pri=32767       0       0

Note: pri=32767 ensures that the ARAM is the kernel's preferred swap device, that is pages will be stored in ARAM in preference to other swap devices such as via ethernet. At present there is no other hardware for a GameCube that offers more performant swap device so giving it maximal priority really does make sense. It is perhaps odd that there are several thousand possible swap priorities when the kernel can only support 32 swap partitions.

To enable swap

Enter the following commands either after every reboot or automatically as part of the initialization scripts.

cube# mkswap /dev/aram
cube# swapon -a

Note: On Debian swapon -a is called from /etc/init.d/checkroot.sh so if you requre ARAM swap to be enabled automatically on reboot you must edit this script to issue the mkswap command before swap is enabled.

Swap to the network

While the system RAM and the audio RAM combined are quite sufficient for simple tasks it is quite likely at some point that this will prove insufficient. Debian's apt-get (and the configuration programs it tries to run) is a good example. In situations like this it is useful to swap over the network. Whilst this is very slow it does allow operations to be performed that would simply be impossible to do otherwise.

To achieve we create a block device (UNIX speak for random access devices such as hard discs, optical drivers etc.) where any read or write performed will be sent over the network. It may astonish the casual reader to discover that such a device is called a network block device.

Setting up the Network Block Device server

We must first create a file on the server to store the data written from the client. The following command creates a zero initialize 128M file.

cube# dd if=/dev/zero of=/tmp/swap-gc bs=$((1024*1024)) count=128

Note: On Debian systems files in /tmp are destroyed every time the host is rebooted.

Having done this we can now start the server.

cube# ./nbd-server-2.7.1 55321 /tmp/swap-gc 128M

Note: the NBD server/client can be downloaded from their website http://nbd.sourceforge.net/

Configuring the client

TODO: nbd setup with the userland nbd client

Kernel support: CONFIG_BLK_DEV_NBD - Device Drivers -> Block devices -> Network block device support and CONFIG_BLK_DEV_NBDC - Device Drivers -> Block devices -> Network block device support -> Network Block Device tiny in-kernel client


The GameCube Linux kernel (when appropriately patched) contains an in-kernel nbd client that can be managed by writing to /proc/nbdc. If this file exists then you can be confident you have a suitable kernel.

Before anything else we must create the device nodes:

cube# for i in `seq 0 3`; do mknod /dev/nbd$i b 43 $i; done

Following this the following line should be added to /etc/fstab:

/dev/nbd0       swap            swap    defaults         0       0

Finally we can configure the network device and use it as a swap partition:

cube# echo '192.168.0.3 55321 /dev/ndb0' > /proc/nbdc
cube# swapon -a

The last stage must be performed after every reboot so it is best to add the configuration command to your init scripts.

Adding Swap with Debian package dphys-swapfile

PROBLEM: After trying to mount the scenario showed in http://www.gc-linux.org/wiki/Setting_up_GC-Linux_with_NFS unsuccessfully i tried to set up with http://www.gc-linux.org/wiki/Setting_up_GC-Linux_with_NBD-root and the only way that runs for me was doing it using a nbd-server running on a windows PC (I tried before whith my PS2 running a BlackRhino Debian flavour, but as I said before, unsuccessfully, sorry!). In this scenario, How do I set up the Network Block Device server (my windows PC!) to get some more extra swap memory?

My SOLUTION: After doing some experiments, googling the net, I found a Debian package that does the job: dphys-swapfile, so (as root):

cube:~# apt-get install dphys-swapfile
cube:~# free
            total       used       free     shared    buffers     cached
Mem:         20392      17532       2860          0       2256       9564
-/+ buffers/cache:       5712      14680
Swap:        61424       1244      60180
cube:~# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/aram                               partition       14328   1244    -1
/var/swap                               file            47096   0       -2
cube:~# ls -l /var/swap
-rw------- 1 root root 48234496 Nov 11 11:41 /var/swap


dphys-swapfile computes the size for an optimal swap file (and resizes an existing swap file if neccessary), mounts an swap file, unmounts it, and and delete it if not wanted any more.Default its 2 times RAM size. (see man dphys-swapfile)

Hope this help someone!


Reading/writing directly to SD/MMC cards

Overview

The GameCube memory card interface is electrically compatible with the interface used by MMC cards. This means that MMC cards can be connected to the 'Cube without requiring any electronic components, this allows very cheap card readers to be manufactured. It also means that homebrew adapters can be built even by the most inexperienced developer. Since SD cards support a superset of the MMC specification these cards are also work well.

Note: While SD/MMC cards are electrically compatible with the EXI interface they are not protocol compatible with GameCube memory cards. This means that although the SD/MMC card reader works well with Linux (and the few games that support SD cards) they cannot be used as a general replacement for normal GameCube memory cards.

Nintendo do manufacture an 'official' SD/MMC card reader but only for the Japanese market. Like the broadband adapter it is therefore quite difficult to source. It is probably worth the money only if you still keep your 'Cube in the family living room!

TODO: write (or link to) instructions on making a homebrew adapter.

GO TO: This linky (Broken?)

Found by Dakota Courtois; it's in the beginning of the driver's comments.

Configuring the kernel

The following options must be set to include the SD/MMC driver in the kernel:

Kernel support: CONFIG_EXPERIMENTAL - Code maturity level options -> Prompt for development and/or incomplete code/drivers and CONFIG_GAMECUBE_EXI - Bus options -> EXI (Expansion Interface) support and CONFIG_GAMECUBE_SD - Device Drivers -> Block devices -> Nintendo GameCube SD and MMC memory card

Creating the SD/MMC card device nodes

The GameCube SD/MMC card driver exposes its devices using the major number 61 and the minor number 0 through 15. This is sufficient for both slot A and slot B. Before using the driver we must therefore create the device nodes. This is achieved as follows:

cube# mknod /dev/sdcarda  b 61 0
cube# mknod /dev/sdcarda1 b 61 1
cube# mknod /dev/sdcarda2 b 61 2
cube# mknod /dev/sdcarda3 b 61 3
cube# mknod /dev/sdcarda4 b 61 4
cube# mknod /dev/sdcarda5 b 61 5
cube# mknod /dev/sdcarda6 b 61 6
cube# mknod /dev/sdcarda7 b 61 7
cube# mknod /dev/sdcardb  b 61 8
cube# mknod /dev/sdcardb1 b 61 9
cube# mknod /dev/sdcardb2 b 61 10
cube# mknod /dev/sdcardb3 b 61 11
cube# mknod /dev/sdcardb4 b 61 12
cube# mknod /dev/sdcardb5 b 61 13
cube# mknod /dev/sdcardb6 b 61 14
cube# mknod /dev/sdcardb7 b 61 15

Mounting a filesystem

After inserting your card reader into a running Linux kernel a message is issued by the kernel.

cube# dmesg | tail -2
gcn-sd: slot1: descr "S016B", size 14560k, serial 36b122c5
 sdcardb: sdcardb1

This message tells us that an SD card (identified as SO16B) has been inserted into the second memory card slot and its partition table has yielded just one device, sdcardb1. You can now perform any operation on /dev/sdcardb1 that you normally perform on devices such as /dev/hda1 on a normal Linux computer. For example, the following commands create and mount an ext2 filesystem on the card, obviously this will destroy everything on the card.

cube# mke2fs /dev/sdcardb1
cube# mkdir -p /media/sdcardb
cube# mount -t auto /dev/sdcardb1 /media/sdcardb
Personal tools