Installation of kernel modules
Since there is no official powerpc kernel module package available for our particular version of kernel, we have to manually install the pre-compiled modules.
At the Installer GUI, press ‘Alt-F2’ to open a second termial console and press ‘Enter’ to activate it. Now input the following commands into the console:
cp -a /lib/modules /lib/firmware /target/lib chroot /target depmod -a exit
And we are done. Press ‘Alt-F1’ to return to the Installer GUI and select ‘Continue’ to reboot Wii.
If you happen to forget to perform this step during installation, you can either boot into the Installer again, manually mount the partition you just installed to and use the above commands with appropriate changes, or boot into the newly installed Debian (see below) and manually extract the contents of ‘modules.tar.bz2’ into ‘/’.
Boot the installed Debian
Booting the installed system is very similar to booting the Installer. All that has to be changed is the kernel used.
If you have not done so yet, extract the ‘apps’ folder, which holds the kernel of IOS version, or the ‘bootmii’ folder, which holds the kernels of MINI version, to the root folder of the first FAT 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.
To boot Debian in IOS mode, select ‘Debian’ from HBC.
To boot Debian in MINI mode, either load a file like ‘d.480i(NTSC).elf’ through Bootmii GUI, or rename the file corresponding to your TV signal format 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.
It is perfectly OK to use IOS mode for installation and boot in MINI mode, and vise versa. In other words, the root filesystem generated by the Installer is compatible with both modes.
Also note that the pre-compiled kernels all assume the presence of root filesystem on second partition of front SD (‘Whiite style’). If your root fs is located elsewhere, you will have to manually hexedit the ‘root=’ kernel commandline argument in the kernel files.
In addtion, video driver in all the pre-compiled kernels has been configured to run in overscan-safe mode with a smaller than maximumly possible screen size. If you wish to disable this to get full screen display, add ‘nostalgic’ parameter to ‘video=’ argument in the kernel commandline.
Debian backports enable users of Stable (Squeeze for now) and Old Stable (Lenny for now) to enjoy the benefits of some new(er) packages available only in Testing or Unstable. To enable backports repository in Lenny, add the following line to ‘/etc/apt/sources.list’:
deb http://backports.debian.org/debian-backports lenny-backports main
For Squeeze, add the following line to the same file:
deb http://backports.debian.org/debian-backports squeeze-backports main
Remember to run ‘apt-get update’ for this change to take effect.
Installing and using a desktop environment
A Linux system with only text-mode consoles to play with is not much fun. Although Wii is an extremely low-end machine, it is still possible to install and run a full-fledged X window system on it, but it is advised to use one of the ‘light-weight’ desktop environments on top of X, such as LXDE. Just type ‘apt-get install gdm lxde xorg-xserver-video-fbdev’ in the console, go get a cup of coffee or tea and almost everything will be in place after a while.
If you are in Squeeze, you do NOT need to create or edit a ‘xong.conf’ file. Modern X is totally capable of figuring out pretty much everything by itself.
If you are in Lenny, you will have to modify ‘/etc/X11/xorg.conf’ by adding a line to the following Section:
Section "Device" Identifier "Configured Video Device" Option "UseFBDev" "true" EndSection
so that the Section now looks like this:
Section "Device" Identifier "Configured Video Device" Driver "fbdev" Option "UseFBDev" "true" EndSection
Debian with a splash
After the system is installed and running, you may want to avoid seeing those boring kernel and userspace messages during boot time. The simplest solution is of course splashy. Run the following in a terminal console/emulator:
apt-get install splashy splashy-themes
To enable splash, kernel boot commandline must be modified to contain ‘splash quiet’.
What about ‘cube’?
As mentioned earlier, the currently available ‘cube’ Xorg driver, with minor patching, is only compatible with the version of Xorg server in Lenny. Consequently, it is not possible to use it in Squeeze or higher. A pre-compiled version of the driver along with a corresponding xorg.conf file is included in the Lenny installer. Just extract the contents of cube.tar.bz2 into your root filesystem. Since ‘cube’ only supports 640×480 NTSC, you will have to add ‘nostalgic’ parameter to ‘video=’ argument in the kernel commandline, and force NTSC in ‘video=’ argument, if you are not using it.
UNFORTUNATELY, THE FOLLOWING ARE NO LONGER AVAILABLE
Disk image with pre-installed Debian
Being a low-end machine with low disk I/O, it takes a lot of time and patience to do a full installation of Debian on Wii, even without installing a GUI desktop environment. Fortunately, since all Wiis are made the same, we can create a pre-installed disk image that can be simply dumped onto a SD card (or USB storage device) and boot into Debian on any homebrew-enabled Wii.
The downloaded package is a compressed image file derived from a 4GB SD card partitioned into a 1GB FAT first partition containing the kernels, an about 2.8GB second partition with a Debian Lenny LXDE installation, and a third swap partition of about 100MB. You will need a 4GB or larger card to use the image and make sure to back up your data on the card, because it will be irreversibly overwritten.
If your OS has the GNU ‘dd’ utility (all *nix-like systems do), just type the following in a console/terminal, assuming /dev/sdd is your card:
dd if=Lenny.bin of=/dev/sdd
If you are on Windows, you can either use various dd ports for Windows (Google is your friend) or use the Grub4DOS Toolbox for Windows utility.
The root password is ‘wii’, as is the user name and password of the normal user. Enjoy!
Good news everyone, I’ve managed to track down most of the issues with my highly optimized 188.8.131.52 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 184.108.40.206 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 220.127.116.11 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 18.104.22.168) 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 22.214.171.124. 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 126.96.36.199 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.