Editing Useful Development Info

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)