Wii-Linux Wiki - User contributions [en]

Main Page

2026-02-22T22:04:30Z

Tech64DD: renamed troubleshooting page

== Welcome to the Wii-Linux Wiki! ==

You've reached the wiki page of [[Wii-Linux]]. Here you may find some information related to Wii-Linux, it's development, and a bit about the [[Wii]] hardware itself.

''' You may also want to check out a similar wiki site, ''' [https://wiibrew.org WiiBrew].

== Navigation ==
{| class="wikitable"
! Hardware !! Software !! Misc
|-
| valign="top" |
* Consoles
** [[Wii U]]
** [[Wii]]
** [[GameCube]]
* Accessories
** Memory Card ([[EXI]] bus)
*** [[SD Gecko]]
*** [[USB Gecko]]
*** [[Memory Card]]
*** [[Microphone]]
*** [[Broadband Adapter]]
*** [[Modem]]
** [[GameCube Controller]]
| valign="top" |
* [[Wii-Linux]]
* [[Wii-Linux Distros|Distros]]
** [[ArchPOWER]]
** [[Void-PPC]]
** [[Debian-Ports PPC]]
* [[Recommended Apps]]
| valign="top" |
* [[Troubleshooting/FAQ]]
* [[Useful Development Info]]
|}

Troubleshooting/FAQ

2026-02-22T22:03:42Z

Tech64DD: add some FAQs about wiimotes

This page contains some fixes for common issues and frequently asked questions with [[Wii-Linux]].

== [[Gumboot]] isn't loading! What's going on? ==
Depends on what's wrong with it.
* '''Black screen? Immediate reboot?''' Check if you have [[BootMii]] installed correctly.
* '''Blinking disk slot?''' Check if your SD Card is inserted properly, this means that BootMii can't find <code>bootmii/ppcboot.elf</code>, <code>bootmii/armboot.bin</code>, or its config.
* '''HBC / Priiloader won't load BootMii'''? Check if BootMii is installed correctly as an IOS - these can't load BootMii as boot2.

== I get an error from Gumboot trying to load the kernel! What's wrong? ==
Check that you copied all of the files properly. It's possible that the kernel was corrupted while copying it.
Try putting the SD Card in a computer, deleting wiilinux/vX_X.krn, and copying it out of the SD Files archive.

== How do I modify the kernel arguments? ==
Open the kernel binary (<code>wiilinux/vX_X.krn</code>) in a hex editor, search for the ASCII text <code>root=</code>, then user overwrite mode to modify the arguments (tip: overwrite the large chunk of padding, that's what it's there for!)

== The kernel seems to load (green bar on Gumboot), but then the screen stays on garbled colors, fully black, or black screen with the loader text! What's wrong? ==
This could be tons of things.
* '''If you're getting the garbled colors''', it means the kernel failed to initialize very early on, before initializing the [[AVE-RVL]].
* '''If you're getting a fully black screen without even the loader text at the top''', that means that it failed after initializing the AVE-RVL, gcnfb, but before displaying the loader text.
* '''If you're getting a black screen with the loader text at the top left''', it means the kernel has initialized a decent bit, but something isn't working. Try setting the kernel arguments (see the previous answer, right above this), replace the loglevel=x parameter with loglevel=7 to get full kernel logs on the screen, or check a USB gecko.
For all of these, having a [[USB Gecko]] would be very beneficial.

== I see the login screen, but I can't type on my USB keyboard, what gives? ==
Check your USB keyboard connection, is it plugged in, and plugged in all the way? (more common than you might think)
Try pressing num lock/caps lock/scroll lock, do the lights come on? If not, check if your keyboard is just dead (plug it into another device). If you've verified all of this, and it still doesn't work, ask for assistance.

== Why is my WiFi so slow? I can't even get 1MB/s! ==
That's just how it is. It's [https://web.archive.org/web/20180817063137/http://www.gc-linux.org/wiki/Wii:WLAN hardware limitations], that's how it is in all standard Wii software as well, the Wii's WiFi chipset is just that slow. I highly recommend using USB Ethernet, or a supported USB WiFI adapter wherever possible if you care about speed.

== Why isn't [some package name here] in the ArchPOWER repos? ==
I don't maintain the [[ArchPOWER]] repos, but I do maintain a small group of extra packages for ArchPOWER in a seperate repo.
Ask me, I'll check for you, and build it if possible.

== Why is logging in so slow? ==
Arch (and by extension, ArchPOWER) uses a fairly inefficient (though more secure) hashing algorithm for the password by default, that is quite slow on the Wii's mediocre CPU. If you'd like a better balance between security and speed, you can use SHA256 instead.
Simply edit <code>/etc/login.defs</code>, then replace <code>YESCRYPT</code> with <code>SHA256</code>, then regenerate the password of each user.
'''New rootfs's have this by default.'''

== Why I get out-of-memory errors despite turning on a swapfile/swap partition? ==
This is a bug in the default Wii-Linux configuration that was shipped for quite some time, but eventually fixed. 
You can either: 
A) Update your system (the latest wii-linux-meta fixes it) 
B) Delete, or fix, <code>/etc/udev/rules.d/99-zram.rules</code> to not have 100M allocated

== Can I play [insert game here] on Wii Linux? ==
Short Answer: '''No'''. Stop trying. You don't want to get it to work. 
Long answer: Well.... technically, yes.
It's very likely compiled for x86, so it'll need to be emulated. That's already unusably slow on the Wii, but let's carry on.
There's no graphics acceleration of any kind, so it'll be rendering on the emulated x86 CPU, and then drawing to the screen w/ native PPC code, but still on the CPU
So, yes, it may execute the game's code, technically, but you sure as hell won't be "playing" it.

== Why is my Wii Remote unpaired after going back to the Wii Menu? ==
The Linux kernel interacts in some weird way with the Bluetooth module causing Wii Remotes to get unpaired when rebooted into the Wii System Menu (and only the menu, other software like the Homebrew Channel works fine). The exact cause of this problem isn't known yet. You'll have to simply pair the Wii Remote(s) again with the console.

== Can I use a Wii Remote as a mouse? ==
Yes but no. The software to do this (xwiimote) has not seen any actual updates since 2013 and does not work on modern systems. You can use cwiid, which is packaged, to interact with a Wii Remote, but it does not give you mouse emulation.

== Why is pairing my Wii Remote to Linux so finnicky? ==
Linux currently has crippling issues with USB support, and the internal Broadcom 2045A Bluetooth card in the Wii is connected over USB, so it inherits these issues. There is nothing that can currently be done to work around or fix this.

== Why do package downloads sometimes fail / "Operation too slow"? ==
The Wii's WiFi connection is ''incredibly'' slow. This leads to downloads sometimes just failing due to timeout. Newer Wii-Linux builds have <code>DisableDownloadTimeout</code> set in <code>/etc/pacman.conf</code>, so this issue should be mitigated. Existing Wii-Linux installs can set this either with ConfigMii, or by manually editing the config file.

Troubleshooting

2026-02-22T22:00:26Z

Tech64DD: Tech64DD moved page Troubleshooting to Troubleshooting/FAQ

#REDIRECT [[Troubleshooting/FAQ]]

Troubleshooting/FAQ

2026-02-22T22:00:26Z

Tech64DD: Tech64DD moved page Troubleshooting to Troubleshooting/FAQ

This page contains some fixes for common issues with [[Wii-Linux]].

== [[Gumboot]] isn't loading! What's going on? ==
Depends on what's wrong with it.
* '''Black screen? Immediate reboot?''' Check if you have [[BootMii]] installed correctly.
* '''Blinking disk slot?''' Check if your SD Card is inserted properly, this means that BootMii can't find <code>bootmii/ppcboot.elf</code>, <code>bootmii/armboot.bin</code>, or its config.
* '''HBC / Priiloader won't load BootMii'''? Check if BootMii is installed correctly as an IOS - these can't load BootMii as boot2.

== I get an error from Gumboot trying to load the kernel! What's wrong? ==
Check that you copied all of the files properly. It's possible that the kernel was corrupted while copying it.
Try putting the SD Card in a computer, deleting wiilinux/vX_X.krn, and copying it out of the SD Files archive.

== How do I modify the kernel arguments? ==
Open the kernel binary (<code>wiilinux/vX_X.krn</code>) in a hex editor, search for the ASCII text <code>root=</code>, then user overwrite mode to modify the arguments (tip: overwrite the large chunk of padding, that's what it's there for!)

== The kernel seems to load (green bar on Gumboot), but then the screen stays on garbled colors, fully black, or black screen with the loader text! What's wrong? ==
This could be tons of things.
* '''If you're getting the garbled colors''', it means the kernel failed to initialize very early on, before initializing the [[AVE-RVL]].
* '''If you're getting a fully black screen without even the loader text at the top''', that means that it failed after initializing the AVE-RVL, gcnfb, but before displaying the loader text.
* '''If you're getting a black screen with the loader text at the top left''', it means the kernel has initialized a decent bit, but something isn't working. Try setting the kernel arguments (see the previous answer, right above this), replace the loglevel=x parameter with loglevel=7 to get full kernel logs on the screen, or check a USB gecko.
For all of these, having a [[USB Gecko]] would be very beneficial.

== I see the login screen, but I can't type on my USB keyboard, what gives? ==
Check your USB keyboard connection, is it plugged in, and plugged in all the way? (more common than you might think)
Try pressing num lock/caps lock/scroll lock, do the lights come on? If not, check if your keyboard is just dead (plug it into another device). If you've verified all of this, and it still doesn't work, ask for assistance.

== Why is my WiFi so slow? I can't even get 1MB/s! ==
That's just how it is. It's [https://web.archive.org/web/20180817063137/http://www.gc-linux.org/wiki/Wii:WLAN hardware limitations], that's how it is in all standard Wii software as well, the Wii's WiFi chipset is just that slow. I highly recommend using USB Ethernet, or a supported USB WiFI adapter wherever possible if you care about speed.

== Why isn't [some package name here] in the ArchPOWER repos? ==
I don't maintain the [[ArchPOWER]] repos, but I do maintain a small group of extra packages for ArchPOWER in a seperate repo.
Ask me, I'll check for you, and build it if possible.

== Why is logging in so slow? ==
Arch (and by extension, ArchPOWER) uses a fairly inefficient (though more secure) hashing algorithm for the password by default, that is quite slow on the Wii's mediocre CPU. If you'd like a better balance between security and speed, you can use SHA256 instead.
Simply edit <code>/etc/login.defs</code>, then replace <code>YESCRYPT</code> with <code>SHA256</code>, then regenerate the password of each user.
'''New rootfs's have this by default.'''

== Why I get out-of-memory errors despite turning on a swapfile/swap partition? ==
This is a bug in the default Wii-Linux configuration that was shipped for quite some time, but eventually fixed. 
You can either: 
A) Update your system (the latest wii-linux-meta fixes it) 
B) Delete, or fix, <code>/etc/udev/rules.d/99-zram.rules</code> to not have 100M allocated

== Can I play [insert game here] on Wii Linux? ==
Short Answer: '''No'''. Stop trying. You don't want to get it to work. 
Long answer: Well.... technically, yes.
It's very likely compiled for x86, so it'll need to be emulated. That's already unusably slow on the Wii, but let's carry on.
There's no graphics acceleration of any kind, so it'll be rendering on the emulated x86 CPU, and then drawing to the screen w/ native PPC code, but still on the CPU
So, yes, it may execute the game's code, technically, but you sure as hell won't be "playing" it.

== Why is my Wii Remote unpaired after going back to the Wii Menu? ==
The Linux kernel interacts in some weird way with the Bluetooth module causing Wii Remotes to get unpaired when rebooted into the Wii System Menu (and only the menu, other software like the Homebrew Channel works fine). The exact cause of this problem isn't known yet. You'll have to simply pair the Wii Remote(s) again with the console.

== Why do package downloads sometimes fail / "Operation too slow"? ==
The Wii's WiFi connection is ''incredibly'' slow. This leads to downloads sometimes just failing due to timeout. Newer Wii-Linux builds have <code>DisableDownloadTimeout</code> set in <code>/etc/pacman.conf</code>, so this issue should be mitigated. Existing Wii-Linux installs can set this either with ConfigMii, or by manually editing the config file.

Broadband Adapter

2025-09-26T23:20:27Z

Tech64DD: broadband adapter is known working

The GameCube Broadband Adapter (sometimes abbreviated as BBA) is a device that plugs into the serial port (the [[EXI]] bus) on the bottom of a [[GameCube]], and exposes an RJ-45 (commonly referred to as Ethernet) plug. It's intended use is for online or local multiplayer games.

== Compatibility ==
The BBA has a driver in [[Wii-Linux]], and has been confirmed to be fully working.

Troubleshooting/FAQ

2025-08-10T01:22:58Z

Tech64DD: fix broken code block

Troubleshooting/FAQ

2025-05-30T21:07:21Z

Tech64DD: added the wii remote unpairing bug

This page contains some fixes for common issues with [[Wii-Linux]].

== [[Gumboot]] isn't loading! What's going on? ==
Depends on what's wrong with it.
* '''Black screen? Immediate reboot?''' Check if you have [[BootMii]] installed correctly.
* '''Blinking disk slot?''' Check if your SD Card is inserted properly, this means that BootMii can't find <code>bootmii/ppcboot.elf</code>, <code>bootmii/armboot.bin</code>, or its config.
* '''HBC / Priiloader won't load BootMii'''? Check if BootMii is installed correctly as an IOS - these can't load BootMii as boot2.

== I get an error from Gumboot trying to load the kernel! What's wrong? ==
Check that you copied all of the files properly. It's possible that the kernel was corrupted while copying it.
Try putting the SD Card in a computer, deleting wiilinux/vX_X.krn, and copying it out of the SD Files archive.

== How do I modify the kernel arguments? ==
Open the kernel binary (<code>wiilinux/vX_X.krn</code>) in a hex editor, search for the ASCII text <code>root=</code>, then user overwrite mode to modify the arguments (tip: overwrite the large chunk of padding, that's what it's there for!)

== The kernel seems to load (green bar on Gumboot), but then the screen stays on garbled colors, fully black, or black screen with the loader text! What's wrong? ==
This could be tons of things.
* '''If you're getting the garbled colors''', it means the kernel failed to initialize very early on, before initializing the [[AVE-RVL]].
* '''If you're getting a fully black screen without even the loader text at the top''', that means that it failed after initializing the AVE-RVL, gcnfb, but before displaying the loader text.
* '''If you're getting a black screen with the loader text at the top left''', it means the kernel has initialized a decent bit, but something isn't working. Try setting the kernel arguments (see the previous answer, right above this), replace the loglevel=x parameter with loglevel=7 to get full kernel logs on the screen, or check a USB gecko.
For all of these, having a [[USB Gecko]] would be very beneficial.

== I see the login screen, but I can't type on my USB keyboard, what gives? ==
Check your USB keyboard connection, is it plugged in, and plugged in all the way? (more common than you might think)
Try pressing num lock/caps lock/scroll lock, do the lights come on? If not, check if your keyboard is just dead (plug it into another device). If you've verified all of this, and it still doesn't work, ask for assistance.

== Why is my WiFi so slow? I can't even get 1MB/s! ==
That's just how it is. It's [https://web.archive.org/web/20180817063137/http://www.gc-linux.org/wiki/Wii:WLAN hardware limitations], that's how it is in all standard Wii software as well, the Wii's WiFi chipset is just that slow. I highly recommend using USB Ethernet, or a supported USB WiFI adapter wherever possible if you care about speed.

== Why isn't [some package name here] in the ArchPOWER repos? ==
I don't maintain the [[ArchPOWER]] repos, but I do maintain a small group of extra packages for ArchPOWER in a seperate repo.
Ask me, I'll check for you, and build it if possible.

== Why is logging in so slow? ==
Arch (and by extension, ArchPOWER) uses a fairly inefficient (though more secure) hashing algorithm for the password by default, that is quite slow on the Wii's mediocre CPU. If you'd like a better balance between security and speed, you can use SHA256 instead.
Simply edit <code>/etc/login.defs</code>, then replace <code>YESCRYPT</code> with <code>SHA256</code>, then regenerate the password of each user.
'''New rootfs's have this by default.'''

== Why I get out-of-memory errors despite turning on a swapfile/swap partition? ==
This is a bug in the default Wii-Linux configuration that was shipped for quite some time, but eventually fixed. 
You can either: 
A) Update your system (the latest wii-linux-meta fixes it) 
B) Delete, or fix, <code>/etc/udev/rules.d/99-zram.rules</code> to not have 100M allocated

== Can I play [insert game here] on Wii Linux? ==
Short Answer: '''No'''. Stop trying. You don't want to get it to work. 
Long answer: Well.... technically, yes.
It's very likely compiled for x86, so it'll need to be emulated. That's already unusably slow on the Wii, but let's carry on.
There's no graphics acceleration of any kind, so it'll be rendering on the emulated x86 CPU, and then drawing to the screen w/ native PPC code, but still on the CPU
So, yes, it may execute the game's code, technically, but you sure as hell won't be "playing" it.

== Why is my Wii Remote unpaired after going back to the Wii Menu? ==
The Linux kernel interacts in some weird way with the Bluetooth module causing Wii Remotes to get unpaired when rebooted into the regular Wii OS, and the exact cause of this problem isn't known yet. 
You'll have to simply pair the Wii Remote(s) again with the console.

Building Kernel Guide

2025-05-19T21:32:40Z

Tech64DD: standalone argument

This Guide will teach you how to cross-compile the [[Wii-Linux]] kernel and supporting elements.

== Requirements ==

* An x86 or AArch64 device running GNU/Linux

== Setup and Compile==
# Install Crosstool-NG via package manager or compile it by cloning <code>git clone https://github.com/crosstool-ng/crosstool-ng</code>.
# Make a directory to have all the files/folders to be in
# In that directory clone the Wii-Linux-Toolchain <code>https://github.com/Wii-Linux/wii-linux-toolchain</code>.
# cd into the wii-linux-toolchain folder and run <code>mv ct-ng.config .config</code> and run <code>ct-ng build</code>.
#* The process will take a while depending on how bad your computer is.
# Once it's installed, it should make a directory in your home folder called <code>x-tools</code>.
#* You can optionally move this directory elsewhere first, if you don't find <code>x-tools</code> appealing.
# You must now add it to your PATH. This varies per shell, and based on where you put it, but as an example:
#* for bash: <code>echo 'PATH="$PATH:~/<path to ct-ng output>/powerpc-unknown-linux-gnu/bin"' >> ~/.bashrc && source ~/.bashrc</code>.
# After you have added it to your path, go back to the main directory and run <code>git clone https://github.com/Wii-Linux/build-stack && cd build-stack</code>.
# Once you're in the build-stack folder, run <code>./setup.sh</code> and follow it's instructions, to make sure that you have all the necessary requirements installed. If it asks to clone and build various requirements, answer Yes unless you have a very specific reason not to.
# After setup.sh finishes successfully, go back to the main directory, and now finally run <code>https://github.com/Wii-Linux/wii-linux-ngx -b <Branch You want></code>.
#* The branch you clone is the source code to the kernel branch you are going to compile (this could be specialized kernels (like for [[OpenWRT]], or just various versions of the main one). The following kernel branches are the ones currently supported:
#** <code>wii-v4.5</code>
#** <code>wii-v4.14-openwrt</code>
#** <code>wii-v4.19</code>
# After you cloned the kernel that you want to build go back into <code>build-stack</code> and run <code>./build-kernel.sh [name of your kernel directory]</code>.
#* Example: <code>./build-kernel.sh wii-linux-ngx</code>.
#* The <code>--standalone</code> argument can be used to build a kernel that doesn't require a loader, <code>arch/powerpc/boot/dts/wii.dts</code> needs to be edited accordingly with the boot device that will be used.
# After the kernel compiles, you have to build the loader (small squashfs that the kernel boots, provides the boot menu). In the build-stack run <code>./build-loader.sh ../v<kernel version short>.ldr</code>.
#* Example: <code>./build-loader.sh ../v4_19325.ldr</code>.
# After the loader is done, you need to go install it. This consists of 2 parts:
#* '''Installing the kernel+loader'''. A script has been provided to make this easier, <code>build-stack/copy-ssh.sh</code>. This provides an easy way to copy the kernel+loader to a remote machine in any directory. This could even be a Wii-Linux install.
#** Example 1 (copy to local machine's SD Card on /mnt): <code>./copy-ssh.sh root@localhost /mnt v4_19325 4.19.325-wii+ kernel v4_19325.ldr</code>
#** Example 2 (copy to Wii with SD Card on /boot): <code>./copy-ssh.sh root@wii.local /boot v4_19325 4.19.325-wii+ kernel v4_19325.ldr</code>
#* ''''Installing the kernel modules''. The kernel modules are output as <code>modules.tar.gz</code> in your kernel directory. You will need to safely extract these to your Wii-Linux distro's rootfs. ''WARNING'': Extracting directly to the rootfs '''''WILL HOSE YOUR PERMISSIONS - DO NOT DO THAT'''''. It will set the UID/HID of the root directory, and /usr, and /usr/lib, to the UID/GID of the user who built the kernel. Instead, you can extract it to a temporary directory, then <code>mv</code> or <code>cp -r</code> the modules (<code>temp_dir/usr/lib/modules/[kernel version]-wii+</code> into your rootfs.

Troubleshooting/FAQ

2025-05-08T10:04:49Z

Tech64DD: formatting

Troubleshooting/FAQ

2025-05-08T09:56:55Z

Tech64DD: formatting

This page contains some fixes for common issues with [[Wii-Linux]].

== [[Gumboot]] isn't loading! What's going on? ==
Depends on what's wrong with it.
* '''Black screen? Immediate reboot?''' Check if you have [[BootMii]] installed correctly.
* '''Blinking disk slot?''' Check if your SD Card is inserted properly, this means that BootMii can't find <code>bootmii/ppcboot.elf</code>, <code>bootmii/armboot.bin</code>, or its config.
* '''HBC / Priiloader won't load BootMii'''? Check if BootMii is installed correctly as an IOS - these can't load BootMii as boot2.

== I get an error from Gumboot trying to load the kernel! What's wrong? ==
Check that you copied all of the files properly. It's possible that the kernel was corrupted while copying it.
Try putting the SD Card in a computer, deleting wiilinux/vX_X.krn, and copying it out of the SD Files archive.

== How do I modify the kernel arguments? ==
Open the kernel binary (<code>wiilinux/vX_X.krn</code>) in a hex editor, search for the ASCII text <code>root=</code>, then user overwrite mode to modify the arguments (tip: overwrite the large chunk of padding, that's what it's there for!)

== The kernel seems to load (green bar on Gumboot), but then the screen stays on garbled colors, fully black, or black screen with the loader text! What's wrong? ==
This could be tons of things.
* '''If you're getting the garbled colors''', it means the kernel failed to initialize very early on, before initializing the [[AVE-RVL]].
* '''If you're getting a fully black screen without even the loader text at the top''', that means that it failed after initializing the AVE-RVL, gcnfb, but before displaying the loader text.
* '''If you're getting a black screen with the loader text at the top left''', it means the kernel has initialized a decent bit, but something isn't working. Try setting the kernel arguments (see the previous answer, right above this), replace the loglevel=x parameter with loglevel=7 to get full kernel logs on the screen, or check a USB gecko.
For all of these, having a [[USB Gecko]] would be very beneficial.

== I see the login screen, but I can't type on my USB keyboard, what gives? ==
Check your USB keyboard connection, is it plugged in, and plugged in all the way? (more common than you might think)
Try pressing num lock/caps lock/scroll lock, do the lights come on? If not, check if your keyboard is just dead (plug it into another device). If you've verified all of this, and it still doesn't work, ask for assistance.

== Why is my WiFi so slow? I can't even get 1MB/s! ==
That's just how it is. It's [https://web.archive.org/web/20180817063137/http://www.gc-linux.org/wiki/Wii:WLAN hardware limitations], that's how it is in all standard Wii software as well, the Wii's WiFi chipset is just that slow. I highly recommend using USB Ethernet, or a supported USB WiFI adapter wherever possible if you care about speed.

== Why isn't [some package name here] in the ArchPOWER repos? ==
I don't maintain the [[ArchPOWER]] repos, but I do maintain a small group of extra packages for ArchPOWER in a seperate repo.
Ask me, I'll check for you, and build it if possible.

== Why is logging in so slow? ==
Arch (and by extension, ArchPOWER) uses a fairly inefficient (though more secure) hashing algorithm for the password by default, that is quite slow on the Wii's mediocre CPU. If you'd like a better balance between security and speed, you can use SHA256 instead.
Simply edit <code>/etc/login.defs</code>, then replace <code>YESCRYPT</code> with <code>SHA256</code>, then regenerate the password of each user.
'''New rootfs's have this by default.'''

== Why I get out-of-memory errors despite turning on a swapfile/swap partition? ==
This is a bug in the default Wii-Linux configuration that was shipped for quite some time, but eventually fixed.
You can either:
A) Update your system (the latest wii-linux-meta fixes it)
B) Delete, or fix, <code>/etc/udev/rules.d/99-zram.rules</code> to not have 100M allocated

== Can I play [insert game here] on Wii Linux? ==
Short Answer: '''No'''. Stop trying. You don't want to get it to work. 
Long answer: Well.... technically, yes.
It's very likely compiled for x86, so it'll need to be emulated. That's already unusably slow on the Wii, but let's carry on.
There's no graphics acceleration of any kind, so it'll be rendering on the emulated x86 CPU, and then drawing to the screen w/ native PPC code, but still on the CPU
So, yes, it may execute the game's code, technically, but you sure as hell won't be "playing" it.

File:Kernelport flowchart.png

2025-05-07T19:41:34Z

Tech64DD: Techflash's old code porting guide turned into a flowchart

== Summary ==
Techflash's old code porting guide turned into a flowchart

Useful Development Info

2025-05-07T19:29:10Z

Tech64DD: added flowchart to make it easier to understand

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
'''Warning''': The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.

the development of the Flipper and Hollywood is actually kind of a funny story 
Nintendo contracted SGI to make the graphics for the N64, as is very well known 
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"? 
a bunch of the employees from that division spun off into their own company, ArtX Inc 
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI 
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with '''[*]'''. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at '''least''' here)

=== Linux, Gumboot, BootMii specific ===
| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| '''[*]''' BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| '''BRANCH''' - If stock MINI, load <code>bootmii/ppcboot.elf</code>. If neagix modified MINI, load <code>gumboot/gumboot.elf</code>, then if failed, <code>bootmii/gui.elf</code>, then if failed, <code>bootmii/ppcboot.elf</code>.
|
| Code is now loaded on the Broadway and begins executing

=== Linux specific ===
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. <code>4.5.0</code> -> <code>v4_5_0.ldr</code>) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is: 
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not 
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue. 
jump forward a few releases 
add your code in 
Build and test. 
If it works out of the box, save this as the last known commit, jump to step 3. 
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3. 
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time 

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray 

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>
[[File:Kernelport flowchart.png]]

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since <code>/bin/sh</code> is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, <code>pacman -S dash</code> to install it, then, as root, <code>ln -sf dash /bin/sh</code>
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to <code>none</code>. This depends on how your DE/WM handles environment variables. If running <code>startx</code> from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T19:00:24Z

Tech64DD: better readability of the kernel code porting "guide"

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
'''Warning''': The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.

the development of the Flipper and Hollywood is actually kind of a funny story 
Nintendo contracted SGI to make the graphics for the N64, as is very well known 
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"? 
a bunch of the employees from that division spun off into their own company, ArtX Inc 
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI 
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with '''[*]'''. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at '''least''' here)

=== Linux, Gumboot, BootMii specific ===
| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| '''[*]''' BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| '''BRANCH''' - If stock MINI, load <code>bootmii/ppcboot.elf</code>. If neagix modified MINI, load <code>gumboot/gumboot.elf</code>, then if failed, <code>bootmii/gui.elf</code>, then if failed, <code>bootmii/ppcboot.elf</code>.
|
| Code is now loaded on the Broadway and begins executing

=== Linux specific ===
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. <code>4.5.0</code> -> <code>v4_5_0.ldr</code>) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is: 
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not 
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue. 
jump forward a few releases 
add your code in 
Build and test. 
If it works out of the box, save this as the last known commit, jump to step 3. 
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3. 
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time 

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray 

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since <code>/bin/sh</code> is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, <code>pacman -S dash</code> to install it, then, as root, <code>ln -sf dash /bin/sh</code>
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to <code>none</code>. This depends on how your DE/WM handles environment variables. If running <code>startx</code> from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T17:09:42Z

Tech64DD: more formatting fixes

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
'''Warning''': The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.

the development of the Flipper and Hollywood is actually kind of a funny story 
Nintendo contracted SGI to make the graphics for the N64, as is very well known 
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"? 
a bunch of the employees from that division spun off into their own company, ArtX Inc 
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI 
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with '''[*]'''. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at '''least''' here)

=== Linux, Gumboot, BootMii specific ===
| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| '''[*]''' BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| '''BRANCH''' - If stock MINI, load <code>bootmii/ppcboot.elf</code>. If neagix modified MINI, load <code>gumboot/gumboot.elf</code>, then if failed, <code>bootmii/gui.elf</code>, then if failed, <code>bootmii/ppcboot.elf</code>.
|
| Code is now loaded on the Broadway and begins executing

=== Linux specific ===
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. <code>4.5.0</code> -> <code>v4_5_0.ldr</code>) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since <code>/bin/sh</code> is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, <code>pacman -S dash</code> to install it, then, as root, <code>ln -sf dash /bin/sh</code>
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to <code>none</code>. This depends on how your DE/WM handles environment variables. If running <code>startx</code> from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T15:45:17Z

Tech64DD: /* History of the GameCube and Wii GPUs */

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
'''Warning''': The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.

the development of the Flipper and Hollywood is actually kind of a funny story
Nintendo contracted SGI to make the graphics for the N64, as is very well known
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"?
a bunch of the employees from that division spun off into their own company, ArtX Inc
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
<pre>
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with [*]. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at *least* here)
</pre>

=== Linux, Gumboot, BootMii specific ===
<pre>| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| [*] BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| **BRANCH** - If stock MINI, load `bootmii/ppcboot.elf`. If neagix modified MINI, load `gumboot/gumboot.elf`, then if failed, `bootmii/gui.elf`, then if failed, `bootmii/ppcboot.elf`.
|
| Code is now loaded on the Broadway and begins executing
</pre>

=== Linux specific ===
<pre>
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. `4.5.0` -> `v4_5_0.ldr`) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here
</pre>

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since `/bin/sh` is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, <code>pacman -S dash</code> to install it, then, as root, <code>ln -sf dash /bin/sh</code>
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to `none`. This depends on how your DE/WM handles environment variables. If running <code>startx</code> from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T15:44:54Z

Tech64DD: /* History of the GameCube and Wii GPUs */

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
'''Warning''': The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.
the development of the Flipper and Hollywood is actually kind of a funny story
Nintendo contracted SGI to make the graphics for the N64, as is very well known
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"?
a bunch of the employees from that division spun off into their own company, ArtX Inc
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
<pre>
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with [*]. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at *least* here)
</pre>

=== Linux, Gumboot, BootMii specific ===
<pre>| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| [*] BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| **BRANCH** - If stock MINI, load `bootmii/ppcboot.elf`. If neagix modified MINI, load `gumboot/gumboot.elf`, then if failed, `bootmii/gui.elf`, then if failed, `bootmii/ppcboot.elf`.
|
| Code is now loaded on the Broadway and begins executing
</pre>

=== Linux specific ===
<pre>
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. `4.5.0` -> `v4_5_0.ldr`) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here
</pre>

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since `/bin/sh` is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, <code>pacman -S dash</code> to install it, then, as root, <code>ln -sf dash /bin/sh</code>
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to `none`. This depends on how your DE/WM handles environment variables. If running <code>startx</code> from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T15:44:36Z

Tech64DD: more formatting

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
```Warning```: The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.
the development of the Flipper and Hollywood is actually kind of a funny story
Nintendo contracted SGI to make the graphics for the N64, as is very well known
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"?
a bunch of the employees from that division spun off into their own company, ArtX Inc
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
<pre>
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with [*]. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at *least* here)
</pre>

=== Linux, Gumboot, BootMii specific ===
<pre>| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| [*] BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| **BRANCH** - If stock MINI, load `bootmii/ppcboot.elf`. If neagix modified MINI, load `gumboot/gumboot.elf`, then if failed, `bootmii/gui.elf`, then if failed, `bootmii/ppcboot.elf`.
|
| Code is now loaded on the Broadway and begins executing
</pre>

=== Linux specific ===
<pre>
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. `4.5.0` -> `v4_5_0.ldr`) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here
</pre>

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since `/bin/sh` is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, <code>pacman -S dash</code> to install it, then, as root, <code>ln -sf dash /bin/sh</code>
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to `none`. This depends on how your DE/WM handles environment variables. If running <code>startx</code> from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T15:43:47Z

Tech64DD:

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
```Warning```: The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.
the development of the Flipper and Hollywood is actually kind of a funny story
Nintendo contracted SGI to make the graphics for the N64, as is very well known
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"?
a bunch of the employees from that division spun off into their own company, ArtX Inc
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
<pre>
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with [*]. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at *least* here)
</pre>

=== Linux, Gumboot, BootMii specific ===
<pre>| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| [*] BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| **BRANCH** - If stock MINI, load `bootmii/ppcboot.elf`. If neagix modified MINI, load `gumboot/gumboot.elf`, then if failed, `bootmii/gui.elf`, then if failed, `bootmii/ppcboot.elf`.
|
| Code is now loaded on the Broadway and begins executing
</pre>

=== Linux specific ===
<pre>
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. `4.5.0` -> `v4_5_0.ldr`) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here
</pre>

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing <code>/etc/systemd/journald.conf</code>, setting <code>Storage=volatile</code> and <code>RuntimeMaxUse=500K</code>. Without this, it uses around '''5MB'''
* Disable <code>systemd-userdbd</code> with <code>systemctl disable --now systemd-userdbd</code>, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about '''9MB'''. Alternative networking managers may be more lightweight.
* Replace <code>/bin/sh</code>'s symlink to <code>bash</code> with one to <code>dash</code>. Since `/bin/sh` is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with <code>dash</code> should free up a variable amount of RAM, depending on how many shell instances are running. To do this, `pacman -S dash` to install it, then, as root, `ln -sf dash /bin/sh`
* Tips specific to running a graphical environment
** Disable <code>at-spi-dbus-bus</code>, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run <code>systemctl --user mask at-spi-dbus-bus</code>.
** Also, set the <code>GTK_ALLY</code> environment variable to `none`. This depends on how your DE/WM handles environment variables. If running `startx` from a terminal, where <code>~/.xinitrc</code> is parsed, simply add <code>export GTK_ALLY=none</code> at the top.
** Reboot to apply the changes
* If using <code>pipewire</code> + <code>pipewire-pulse</code>, DON'T! They're significantly slower than standard <code>pulseaudio</code>, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T15:40:23Z

Tech64DD: fix formatting

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
```Warning```: The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.
the development of the Flipper and Hollywood is actually kind of a funny story
Nintendo contracted SGI to make the graphics for the N64, as is very well known
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"?
a bunch of the employees from that division spun off into their own company, ArtX Inc
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
<pre>
| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| BRANCH - If BootMii installed as boot2, skip the to the step marked with [*]. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at *least* here)
</pre>

=== Linux, Gumboot, BootMii specific ===
<pre>| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| [*] BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| **BRANCH** - If stock MINI, load `bootmii/ppcboot.elf`. If neagix modified MINI, load `gumboot/gumboot.elf`, then if failed, `bootmii/gui.elf`, then if failed, `bootmii/ppcboot.elf`.
|
| Code is now loaded on the Broadway and begins executing
</pre>

=== Linux specific ===
<pre>
| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. `4.5.0` -> `v4_5_0.ldr`) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here
</pre>

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing `/etc/systemd/journald.conf`, setting `Storage=volatile` and `RuntimeMaxUse=500K`. Without this, it uses around 5MB
* Disable `systemd-userdbd` with `systemctl disable --now systemd-userdbd`, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about **9MB**. Alternative networking managers may be more lightweight.
* Replace `/bin/sh`'s symlink to `bash` with one to `dash`. Since `/bin/sh` is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with `dash` should free up a variable amount of RAM, depending on how many shell instances are running. To do this, `pacman -S dash` to install it, then, as root, `ln -sf dash /bin/sh`
* Tips specific to running a graphical environment
** Disable `at-spi-dbus-bus`, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up 10MB. Run `systemctl --user mask at-spi-dbus-bus`.
** Also, set the `GTK_ALLY` environment variable to `none`. This depends on how your DE/WM handles environment variables. If running `startx` from a terminal, where `~/.xinitrc` is parsed, simply add `export GTK_ALLY=none` at the top.
** Reboot to apply the changes
* If using `pipewire` + `pipewire-pulse`, DON'T! They're significantly slower than standard `pulseaudio`, which works just as well on the Wii.

'''Note that these do cause the loss of some important functionality'''
* Tips that will break things
** '''If you do this, pipewire will stop working.''' Disable <code>wireplumber</code>, run the following, <code>systemctl --user disable --now wireplumber</code>, and <code>systemctl --user mask wireplumber</code>. Without this, it uses '''10MB'''.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)

64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)

Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Useful Development Info

2025-05-07T15:30:30Z

Tech64DD: Created page with "This page contains some information about the GameCube, Wii or Wii U hardware or software, Linux kernel and general Wii-Linux topics that can be useful for development. == History of the GameCube and Wii GPUs == ```Warning```: The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate. the development of the Flipper and Hollywood is actually kind of a funny sto..."

This page contains some information about the [[GameCube]], [[Wii]] or [[Wii U]] hardware or software, Linux kernel and general [[Wii-Linux]] topics that can be useful for development.

== History of the GameCube and Wii GPUs ==
```Warning```: The source of the following info is a Discord message that Techflash wrote based on his memory of various other sources, so it might not be 100% accurate.
the development of the Flipper and Hollywood is actually kind of a funny story
Nintendo contracted SGI to make the graphics for the N64, as is very well known
there was a specific division in SGI to handle it, it was such a big deal, iirc the "Nintendo Operations Division"?
a bunch of the employees from that division spun off into their own company, ArtX Inc
Nintendo contracted ArtX Inc to design the GPU for the GameCube, however, only a year before the launch of the GameCube, ArtX got acquired by ATI
that's how the GameCube got the ATI branding, because ATI was now the parent company of ArtX - technically, the GPU wasn't designed by ATI, and has no relation whatsoever to any ATI Radeon GPU

== Wii (and Wii-Linux) boot process ==
=== Common ===
<nowiki>| Your Wii starts
|
| boot0 (stored in mask ROM inside the Starlet)
|
| All looks good with boot1? If so, continue, if not, die.
|
| boot1 (stored on NAND)
|
| All looks good with boot2? If so, continue, if not, die.
|
| boot2 (stored on NAND)
|
| **BRANCH** - If BootMii installed as boot2, skip the to the step marked with **[\*]**. Otherwise, continue directly below this
|
| PowerPC startup and SysMenu loads (I think? I can't find any info on necessarily when it happens, but I know it doesn't happen until at *least* here)</nowiki>

=== Linux, Gumboot, BootMii specific ===
<nowiki>| Depends on the user's setup, but somehow load BootMii, either via IOS or boot2
|
| **[\*]** BootMii begins trying to load armboot.bin from SD
|
| armboot.bin (MINI) loaded and begins executing
|
| **BRANCH** - If stock MINI, load `bootmii/ppcboot.elf`. If neagix modified MINI, load `gumboot/gumboot.elf`, then if failed, `bootmii/gui.elf`, then if failed, `bootmii/ppcboot.elf`.
|
| Code is now loaded on the Broadway and begins executing</nowiki>

=== Linux specific ===
<nowiki>| User selects Linux kernel, either via BootMii's file picker, or Gumboot's boot menu
|
| Linux kernel loaded from SD, into RAM, and starts executing
|
| Regular Linux kernel initialization
|
| Linux loads the compiled-in initramfs CPIO, and executed init from it
|
| internal-loader determines a valid version number to try to use (e.g. `4.5.0` -> `v4_5_0.ldr`) finds any partition on SD that holds that file
|
| That file is found, mounted, and swtich_root'ed into. Otherwise, die here
|
| the loader launches the boot menu, letting the user pick a distro to boot
|
| distro is picked, mounted, and switch_root'ed into
|
| regular Linux boot process for your selected distro continues here</nowiki>

== Techflash's method of porting over old kernel code ==
<blockquote>
my personal process for porting over really old code like that is:
start with the last commit in which your "good" code still exists, if upstream, or is known good, if not
sanity check - does it actually work there? Yes - continue. No - figure out what's wrong (bad toolchain?), fix it, continue.
jump forward a few releases
add your code in
Build and test.
If it works out of the box, save this as the last known commit, jump to step 3.
If it works after minor fixes, save that code as the new "good" code, save this as the last known good commit, and jump to step 3.
If it's horribly broken, go back to the last known good commit, and jump forward by less releases this time

eventually, you'll narrow down between 2 releases, where the "major" issues occurred, you can now scan through the git log between them, and find the commit removing / renaming whatever functions, variables, etc, your code needs. You can now look back through the previous few commits, you'll probably see some changes happening to other drivers in preparation for the removal / rename / whatever. Apply those to your driver, rebuild, and pray

That's my personal process anyways, just figured I would drop it here in case it may be useful
</blockquote>

== Linux graphics stack simplified ==
* Kernel
** DRM (Direct Rendering Manager, a basic layer for hw accel)
** (legacy, what the Wii uses) fbdev, a simple framebuffer with no inherent acceleration support
** KMS (Kernel Mode Setting, kernel sets up a framebuffer on top of DRM. Handles the framebuffer TTY when using DRM)
* Userspace
** Xorg Driver (e.g. xf86-video-blahblah), provides 2D acceleration under Xorg
** Mesa Driver (e.g. /usr/lib/dri/blah_drv.so), provides 3D acceleration
** Mesa provides an OpenGL (and Vulkan iirc) interface to applications

== Tips for reducing memory and CPU usage ==
* Reduce the systemd-journald max memory usage by editing `/etc/systemd/journald.conf`, setting `Storage=volatile` and `RuntimeMaxUse=500K`. Without this, it uses around **5MB**
* Disable `systemd-userdbd` with `systemctl disable --now systemd-userdbd`, you probably don't need this.
* Switch to an alternative network manager, or none at all if you want an offline experience. While I ship NetworkManager by default, due to it's ease of setup, it is rather bulky, using about **9MB**. Alternative networking managers may be more lightweight.
* Replace `/bin/sh`'s symlink to `bash` with one to `dash`. Since `/bin/sh` is meant to be the POSIX conformant shell, applications theoretically shouldn't rely on bashisms to be present. Replacing it with `dash` should free up a variable amount of RAM, depending on how many shell instances are running. To do this, `pacman -S dash` to install it, then, as root, `ln -sf dash /bin/sh`
* Tips specific to running a graphical environment
** Disable `at-spi-dbus-bus`, it's a systemd user service. Unless you're using accessibility features, this is just sitting here sucking up **10MB**. Run `systemctl --user mask at-spi-dbus-bus`.
** Also, set the `GTK_ALLY` environment variable to `none`. This depends on how your DE/WM handles environment variables. If running `startx` from a terminal, where `~/.xinitrc` is parsed, simply add `export GTK_ALLY=none` at the top.
** Reboot to apply the changes
* If using `pipewire` + `pipewire-pulse`, **DON'T!!** They're significantly slower than standard `pulseaudio`, which works just as well on the Wii.

```Note that these do cause the loss of some important functionality```
* Tips that will break things
** ```If you do this, pipewire will stop working```. Disable `wireplumber`, run the following, `systemctl --user disable --now wireplumber`, and `systemctl --user mask wireplumber`. Without this, it uses **10MB**.

== Some useful datasheets, and most notable, their operating temperatures, for parts of the Wii ==
"observed at" readings are with the case of, heatsink of Broadway + Hollywood, and no fan - left running for 1 hour.

SHARP Voltage Regulator - [https://www.digikey.in/htmldatasheets/production/44030/0/0/1/pq070xh02zxh.html] (85C max - observed at 47C)
64MB (512Mbit) GDDR3 - [https://www.alldatasheet.com/datasheet-pdf/view/207161/QIMONDA/HYB18H512321BF.html] (85C max - observed at 57C)
Various off-the-shelf power circuitry (generally very high maximum temperature - observed between 45C to 52C)

Main Page

2025-05-07T15:07:01Z

Tech64DD: added troubleshooting to main page

== Welcome to the Wii-Linux Wiki! ==

You've reached the wiki page of [[Wii-Linux]]. Here you may find some information related to Wii-Linux, it's development, and a bit about the [[Wii]] hardware itself.

''' You may also want to check out a similar wiki site, ''' [https://wiibrew.org WiiBrew].

== Navigation ==
{| class="wikitable"
! Hardware !! Software
|-
| valign="top" |
* Consoles
** [[Wii U]]
** [[Wii]]
** [[GameCube]]
* Accessories
** Memory Card ([[EXI]] bus)
*** [[SD Gecko]]
*** [[USB Gecko]]
*** [[Memory Card]]
*** [[Microphone]]
*** [[Broadband Adapter]]
*** [[Modem]]
** [[GameCube Controller]]
| valign="top" |
* [[Wii-Linux]]
* [[Wii-Linux Distros|Distros]]
** [[ArchPOWER]]
** [[Void-PPC]]
** [[Debian-Ports PPC]]
* [[Recommended Apps]]
* [[Troubleshooting]]
|}

Troubleshooting/FAQ

2025-05-07T15:05:05Z

Tech64DD: Created page with "This page contains some fixes for common issues with Wii-Linux. == Gumboot isn't loading! What's going on? == Depends on what's wrong with it. Black screen? Immediate reboot? Check if you have bootmii installed correctly. Blinking disk slot? Check if your SD Card is inserted properly, this means that bootmii can't find ppcboot.elf, armboot.elf, or it's config. HBC / Priiloader won't load bootmii? Check if bootmii is installed correctly as an IOS - these can't l..."

This page contains some fixes for common issues with [[Wii-Linux]].

== Gumboot isn't loading! What's going on? ==
Depends on what's wrong with it.
Black screen? Immediate reboot? Check if you have bootmii installed correctly.
Blinking disk slot? Check if your SD Card is inserted properly, this means that bootmii can't find ppcboot.elf, armboot.elf, or it's config.
HBC / Priiloader won't load bootmii? Check if bootmii is installed correctly as an IOS - these can't load bootmii as boot2.

== I get an error from Gumboot trying to load the kernel! What's wrong? ==
Check that you copied all of the files properly. It's possible that the kernel was corrupted while copying it.
Try putting the SD Card in a computer, deleting wiilinux/vX_X.krn, and copying it out of the SD Files archive.

== How do I modify the kernel arguments? ==
Open the kernel binary (wiilinux/vX_X.krn) in a hex editor, search for the ASCII text root=, then user overwrite mode to modify the arguments (tip: overwrite the large chunk of padding, that's what it's there for!)

== The kernel seems to load (green bar on gumboot), but then the screen stays on garbled colors, fully black, or black screen with the loader text! What's wrong? ==
This could be tons of things.
If you're getting the garbled colors, it means the kernel failed to initialize very early on, before initializing the AVE-RVL.
If you're getting a fully black screen without even the loader text at the top, that means that it failed after initializing the AVE-RVL, gcnfb, but before displaying the loader text.
If you're getting a black screen with the loader text at the top left, it means the kernel has initialized a decent bit, but something isn't working. Try setting the kernel arguments (see the previous answer, right aove this), replace the loglevel=x parameter with loglevel=7 to get full kernel logs on the screen, or check a USB gecko.
For all of these, having a USB gecko would be very beneficial.

== I see the login screen, but I can't type on my USB keyboard, what gives? ==
Check your USB keyboard connection, is it plugged in, and plugged in all the way? (more common than you might think)
Try pressing num lock/caps lock/scroll lock, do the lights come on? If not, check if your keyboard is just dead (plug it into another device). If you've verified all of this, and it still doesn't work, ask for assistance.

== Why is my WiFi so slow? I can't even get 1MB/s! ==
That's just how it is. It's hardware limitations, that's how it is in all standard Wii software as well, the Wii's WiFi chipset is just that slow. I highly recommend using USB Ethernet, or a supported USB WiFI adapter wherever possible if you care about speed.

== Why isn't [some package name here] in the ArchPOWER repos? ==
I don't maintain the ArchPOWER repos, but I do maintain a small group of extra packages for ArchPOWER in a seperate repo.
Ask me, I'll check for you, and build it if possible.

== Why is logging in so slow? ==
Arch (and by extension, ArchPOWER) uses a fairly inefficient (though more secure) hashing algorithm for the password by default, that is quite slow on the Wii's mediocre CPU. If you'd like a better balance between security and speed, you can use SHA256 instead.
Simply edit /etc/login.defs, then replace YESCRYPT with SHA256, then regenerate the password of each user.

== Why I get out-of-memory errors despite turning on a swapfile/swap partition? ==
This is a bug in the default Wii Linux configuration that was shipped for quite some time, but eventually fixed.
You can either:
A) Update your system (the latest wii-linux-meta fixes it)
B) Delete, or fix, /etc/udev/rules.d/99-zram.rules to not have 100M allocated

== Can I play [insert game here] on Wii Linux? ==
Short Answer: No. Stop trying. You don't want to get it to work.
Long answer: Well.... technically, yes.
It's very likely compiled for x86, so it'll need to be emulated. That's already unusably slow on the Wii, but let's carry on.
There's no graphics acceleration of any kind, so it'll be rendering on the emulated x86 CPU, and then drawing to the screen w/ native PPC code, but still on the CPU
So, yes, it may execute the game's code, technically, but you sure as hell won't be "playing" it.

Modem

2025-05-06T22:19:06Z

Tech64DD:

The GameCube Modem is a device that plugs into the serial port (the [[EXI]] bus) on the bottom of a [[GameCube]], and exposes an RJ11 connector for dial-up internet access. It's intended use is for online multiplayer games.

== Compatibility ==
There is no driver for the Modem in either [[Wii-Linux]], nor [[NetBSD]].

Broadband Adapter

2025-05-06T22:18:00Z

Tech64DD: added mention of the EXI bus

Modem

2025-05-06T22:13:19Z

Tech64DD: created the page

The GameCube Modem is a device that plugs into the serial port on the bottom of a [[GameCube]], and exposes an RJ11 connector for dial-up internet access. It's intended use is for online multiplayer games.

== Compatibility ==
There's no driver available for it, but it does get detected by the system (even if it can't be used).

Broadband Adapter

2025-05-06T22:03:19Z

Tech64DD: created the page

The GameCube Broadband Adapter (sometimes abbreviated as BBA) is a device that plugs into the serial port on the bottom of a [[GameCube]], and exposes an RJ-45 (commonly referred to as Ethernet) plug. It's intended use is for online or local multiplayer games.

== Compatibility ==
There is a kernel driver for it, but since the GameCube port of Wii-Linux hasn't been confirmed working on a [[GameCube]] yet it's functionality status is unknown.

User:Tech64DD

2025-01-08T13:48:11Z

Tech64DD: Created page with "Don't worry boys, the Engineer is Engi-here!"

Don't worry boys, the Engineer is Engi-here!