Note: this is work-in-progress. This note will be gone when the post is finished.
Being the distro with the most versatile CPU architecture support, it was no wonder that Debian and its derivative systems were the first to be installed and run on homebrew-enabled Wii once the linux kernel was successfully ported. Debian is equipped with a powerful and easy-to-use Debian Installer, which enables people unfamiliar with linux to install and enjoy Debian without needing any fancy tool or ‘professional help’. Unfortunately, installing Debian-based systems on Wii has always been a headache, because Debian Installer can not output correct colour due to an issue with Wii’s framebuffer data format, and the user is unable to interact with it. It may be a little bit late, but that issue can now be dealt with and it is now possible to install Debian on Wii in the real ‘Debian way’.
This post will guide you through the process of installing Debian on homebrew-enabled Wii using a customized Debian Installer. However, if you prefer to go the lazy/easy way, there is a pre-installed disk image file available for download towards the end of the post, along with explanations on usage.
- Homebrew-enabled Wii
Checkout WiiBrew if you have no idea what this means.
- Debian Installer for Wii
The compressed archives contain both IOS and MINI versions of the installer, which can be loaded by Homebrew Channel (HBC) and Bootmii, respectively.
Note: only Lenny supports the currently available version of ‘cube’ Xorg driver.
- SD(HC) card
This will hold the Debian Installer for Wii files and go into the front SD slot of Wii. The card should be formatted as a single FAT(16/32) partition or has its first partition formatted as FAT(16/32).
Extract the ‘apps’ folder, which holds files of IOS version of the installer, or the ‘bootmii’ folder, which holds files of MINI version of the installer, to the root folder of the (first partition of the) card. For the MINI version to work, Bootmii files (armboot.bin, ppcboot.elf and bootmii.ini) should also be placed inside ‘bootmii’ folder.
- Debian CD/DVD ISO image
One businesscard (smallest), netinst (medium size) or DVD (HUGE!) ISO image is needed. A copy of netinst ISO is included in the Installer packages for your convenience. For other types of images, please use this debian-cd mirror, which has the most complete collection. Just select a version and browse into ‘powerpc/iso-cd’ or ‘powerpc/iso-dvd’. Larger images usually save some installation time, because fewer packages need to be downloaded. Remember to use Lenny ISO for Lenny Installer, and Squeeze ISO for Squeeze Installer.
- USB storage device
This will hold the Debian ISO image during installation onto the card in front SD. Extract the ISO image from downloaded installer archive and save it, preferably in the root folder, to any partition of this device.
(Alternatively, you can place the Debian ISO image on the front SD card and install Debian onto this USB device. In fact, this device can be omitted. Advanced users can partition the front SD card into at least 2 partitions, which is not a trivial task in Windows, but trivial enough in Linux, with the first formated as FAT to hold both the Installer files and ISO image, and install Debian onto the second partition.)
- USB Keyboard
USB mouse is only required after the installation is complete and if you intend to install and use a GUI desktop.
- Network connection through USB LAN/wifi adapter (IOS/MINI) or Wii native wifi (MINI)
Actually, this is not absolutely necessary, except when businesscard ISO is being used, but without it, you will end up with a very limited (base) system, unless you use the Debian DVD ISO image for installation. As much support for various USB LAN adapters and USB wifi adapters as possible have been built into the Installer. Note that the Installer’s wifi support is limited to WEP-based security mode.
You most likely will also need a USB hub. Just remember that USB 1.0/1.1 hubs might slow down transfer speeds of connected USB storage devices, especially in MINI.
Boot Debian Installer for Wii
The IOS version of the Installer can be directly loaded through HBC by selecting ‘Debian Installer’. In this version, Wii’s native wifi and DVD drive are unavailable.
The MINI versions are in the ‘bootmii’ folder with names like ‘d-i.480i(NTSC).elf’. You can load the file corresponding to your TV signal format through Bootmii GUI, or rename the file to ‘ppcboot.elf’ and let Bootmii auto-launch it at Wii power-on, or boot directly into it by launching Bootmii installed as IOS from HBC. You might want to remove all files incompatible with your TV signal format to avoid confusion and make selection in bootmii GUI easier.
Good news everyone, I’ve managed to track down most of the issues with my highly optimized 126.96.36.199 GC/Wii Linux Kernel and have recently made the repository pubic. It can be found on Github at: “https://github.com/DeltaResero”. Due to something I overlooked, the repository may have to be moved, but even if does, I’ll still keep it under the same name in the link. Within the next 6 months, I hope to have another repository set up for a 3.0 (and above) kernels and a page with a few compiled Kernels as I was mostly successful in porting this as well (GPIO breaks). While this 188.8.131.52 repository still suffers from the accept4 issue I previously mentioned, my 3.0 Kernel doesn’t. I would definitely be interested in a 3.0 Wheezy installer once I make the 3.0 patch public, if this is possible.
Oops, I thought the comment above was lost, it didn’t show like the rest with any browsers, even after clearing the cache and refreshing the page…
Sorry, wordpress email settings got messed up.
I suggest a little help.
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
put a comment
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6
the Wii, will thank you. 🙂
That depends on your needs. If two ttys are enough for you, it’s ok. But you might need multiple tty consoles simultaneously for debugging or development. Either way, the memory saved or wasted won’t make that much difference.
It seems that 184.108.40.206 was just recently released and has quite a few bug fixes, so I’ll try to make some time for building a custom kernel. After taking a look through the sources and the default Wii Linux configuration, it should be quite easy to build one with some backports and bug fixes from recent kernels. I’ll post here (hopefully in the next few days) regarding my findings, but in theory I should be able to free up about 3MB of RAM from the kernel just by removing non essentials such as kernel debugging; as well as about another 10MB and possibly some CPU usage with some tweaks and patches.
Also, when building kernels, I get warnings from what seems to be the deffered I/O patch (“/drivers/video/gcnfb.c”). I get warnings such as “unused variable ‘adr’ ” (from line 286 in patch)”. I’m not sure why this was here originally, but it seems it can be removed. In total there are 5 other warnings generated by this in recent kernels, but they have no effect on building.
warnings about unused variables usually don’t matter, because they are unused.
Also, line 297 should be: ” “virtual framebuffer at 0x%p, size %luk\n” “, (the “d” was replaced by “lu”). The kernel seems to compile without the extra functions, “vifb_mmap” and “vifb_pan_display”, I’m not sure if these are needed, but I can’t find any calls to them elsewhere else. So that just leaves the “ISO C90 forbids mixed declarations and code” warning, I not sure what this means.
It means variable declarations should be placed at the beginning of file/function, separate from actual code. No real harm.
Just a quick update, I have everything working in the kernel, but after Kubuntu 120.10 upgraded I seemed to have lost the ability to mount external JFS drives (like the one containing the kernel patches I was working on) and my system is completely unstable for me. I guess I’ll have to aim for next weekend instead. It may be wise for me to start using Github in the near future…
Newer userspace will have more and more trouble working with old kernels, that is expected.
Sorry for the lack of contact with everyone, since October with hurrican Sandy, my priorities have changed and my internet usage has been sparse to say the least. I will resume with what I left off with in October after Christmas.
By the way, the nearly endless udev error messages caused in running Debian Wheezy/Sid with the 2.6.32 kernels are caused by the lack of an accept4 system call. Unfortanetly the only solutions currently are to patch udev or with a kernel patch (doesn’t exist for powerpc yet) or to use udev versions under 170 (breaks a few packages).
I’m just going to post in the forms here from now on due to my post mostly no longer showing up here. By the way, the optimized Kernel I’ve been working on is now finished and I’ve attempted to post more info in the form under the Linux on Wii topic.
I’ve a little pb, my wii stuck at this line and seem to have freezed
0.172570 irq:irq 2 on host /soc/[email protected] mapped to virtual irq 19
Installation was made with your netinstall iso (sd with fat32 swap  ext3 as / and a usb on the 2.0 as /home)
I’ve tested all the elf files (the d ones, not the d-i ) with bootmii (by renaming ppcboot.elf) and by the Ios
Same shit happens.
Sorry for bad english.
Regards, Paul the frenchy.
Can’t say much about that freezing line, but i’m guessing it most likely is not what is wrong.
With your partition setup, you will have to “manually hexedit the ‘root=’ kernel commandline argument in the kernel files”. If you already did this, make sure you did not change the filesize in the process.
To clarify, what I mean is, is there’s a new version than JOVI and HAXX? I’m using version 1.1.0 and cannot find what the code name/id name is for it.
Yes, there is. They changed it to sth non-ASCII to circumvent Nintendo firmware check. You probably would have to search on wiibrew wiki/forum for the acutal hex code.
Thanks, this was all that was missing. In the mikep5 patch, I added the lines “define STARLET_TITLE_HBC_V107 0x00010001AF1BF516ULL” ( for starlet-ios.h) and “starlet_es_reload_ios_and_launch(STARLET_TITLE_HBC_V107);” (for wii.c) near where HAXX and JODI are mentioned.
Also I found out why there was an ohci.h error occurring in patching recent 2.6.32 series kernels. Why the error occured was due to an extra line added in to prevent a Nvidia power bug that’s not in the mikep5 patch. This can easily be fixed by editing the extra line into the patch. If for some reason this does not work with future 2.6.32 series kernels, it seems that replacing ohci.h and ohci-hcd with older original versions of themselves (such as the ones from 220.127.116.11) seem to work without major errors. I only recommend this second way as a last alternative as it is prone to errors. Also, most of the other warnings when cross compiling regarding various variables being unused have been queued to kernel 18.104.22.168. Maybe this will lead to a minor memory gain.
I would think most 2.6.32 updates nowadays are related to security instead of performance. So if it takes too much work, you could just stick with the easier-to-compile old kernels.
Your right about it being mostly security fixes and not performance impovements, but I found some patches that may greatly reduce memory usage with these recent kernels. I still need to do some more testing, one of them seems to be causing a memory leak somewhere.
Right now, I’m just debating on whether or not to use an initrd. Why do kernels have an initrd (initial ramdisk) anyway? Other than RAID compatibility and maybe a slight boost in initial I/O speeds, is there a reason why this should be included or does it not really matter much. From what I understand, this is just a 300kb penalty for a slight i/o boost during boot.
initrd is usually optional if your rootfs is not peculiar and directly mountable by kernel.
In the GC-Linux patch, I found “#define STARLET_TITLE_HBC_JODI 0x000100014A4F4449ULL”, “starlet_es_reload_ios_and_launch(STARLET_TITLE_HBC_JODI)” and their HAXX counterparters. At first, I thought it was named HAXX, so I left it. I am unable to find the id/name of the current 1.1.0 version. How is this normally found, I tried searching Google but could not find it?
I think I might finally be making some progress as I’m now able to successfully build a working kernel. I solved most of my problems by just running “fsck /dev/sdCardMountPoint -f” on the various partitions, it seems “fsck” alone wasn’t enough. I found out that most of the I/O errors caused while in MINI are probably from an old unsolved bug in Debian operating systems (effects certain SDHC cards at random during read/write). The wireless patch that I asked about before had no effect, although using a different 2.6.32 series kernel seemed to fix this. Due to these bugs, I’ve decided to build an IOS kernel. The only problem is, when I reboot, my IOS kernels always reboot the Wii (no matter which version) rather than to the Homebrew Channel like it should. The GC-Linux mikep5 patch and your deffered I/O patch, are the only ones that I’ve been applying so far. I’ve been using the configuration (.config) from your kernel here too. I have not been successful in compiling any working external modules yet (mostly due to lack of time), so I rebuilt the same kernel using 22.214.171.124 with your configuration so your compiled modules would work with it, but this had no effect on solving the reboot issue. I did not attempt to add an initrd image, but this should not effect it from what I understand. Did you apply other patches or add a flag to activate this when compiling somehow, your IOS kernel reboots to the Homebrew Channel?
Also, I just noticed that you have a forum for here. Sorry if my post are getting excessive and making a mess. I don’t know if it matters to you or not, but if your able to delete or move them, I don’t mind as it seems these post have been taking up more room than your actual blog.
The reboot issue is due to the ‘newest’ HBC updating its channel name. You can search the kernel patch for JODI to see where to change.
It really does not matter whether you use this blog or the forum. Since wordpress sends automatic email notification, I usually reply faster here.
I forget to ask earlier, how did you compile your kernel modules and firmware files (your lib folder in the download)? It seems after compiling a native kernel with GNU make, all that’s created are .o files, not .ko for modules and the firmware is in hexadecimal format. If my understanding of modules is correct, than my custom kernel will not be compatible with the modules/firmware you provided as they are different versions.
Also, MINI bootloaders you provided (like official ones) all seem to have multiple I/O output warning that seem to be related to the wireless card. I get warnings in TTY during startup and shutdown such as “multiple chipcommon found”. Do you know of any patches or workarounds other than possibly disabling printk? The closest fix I could find using google was a BRCM4716 patch, but I’m quite sure this isn’t going to help (link is in my name).
Kernel building is not like simple software building. You must provide various options to build the correct files. See geexbox for wii sources (packages/linux/build and install) for examples. Kernel version checking can be overridden in kernel config, and maybe at runtime too.
I don’t remember seeing the wifi errors you describe. On the other hand, native wifi only barely works in MINI to begin with. The patch you referred to may or may not help, but you can try.