gc-linux on Wii: fixing display and SDHC issues

[neagix]

Hi there!

Really glad I found gc-forever, as the gc-linux wiki seems quite dead.

In the past few days I have been playing around with the code found at https://github.com/DeltaResero/GC-Wii-Linux-Kernels with the goal of re-basing DeltaResero's work on top of v3.x and v4.x upstream kernels.

The result of my work so far is here:

https://github.com/neagix/wii-linux-ngx

I have created a few branches and will update the README in the next few days; I also just noticed these two threads here that seem related/useful (although for GC only): viewtopic.php?f=27&t=769 and viewtopic.php?f=27&t=3733

During this testing I have always been able to use ttyUSB0 for serial output, except in the cases when it panics. No luck with udbg-immortal though.

My hardware is a Wii post-2008, and I would like to share with you some thoughts as maybe you can help me; I will probably also ask on some Wii-centered forums (any tips?).
It seems that so far the v2.6.32 is the best kernel for this hardware, but it would be nice if I can maintain (with some help) a more recent one for a while.

Thanks!

Update 9 Aug 19:32:55 CEST 2017 Reporting about branches that are working good, status update

Update 10 Aug 01:55:16 CEST 2017 solved all the console display issues, were due to other problems; updated links and description

Update 12 Aug 03:16:35 CEST 2017 completed the packaging of Debian Jessie with the best v3.x kernel, released here:

Update 12 Aug 14:15:58 CEST 2017 created new thread for the release: https://www.gc-forever.com/forums/viewt ... =27&t=3829 please follow that for further releases

Update 14 Aug 01:28:36 CEST 2017: false positive, not yet solved

[Deltaresero]

Thanks for your efforts on re-basing and testing the patches. It's been a few years since I looked at the code last, but if I remember correctly, why I stopped working on it was after an update in Debian Jessie while it was in Testing, there was no display. Basically things happened in outside life which lead to me moving and I lost the SD card in the process that had the OS on it and that left me to lose track of when the change occurred. I'm not sure if this is the same issue or not, but it could be related. As you probably know, there is an SDHC driver in the mainline kernel for the Wii, but why I didn't just use it was I couldn't figure out out what the issue was with just using it directly with the rest of the patch. So what I did was just re-base the driver from the patch into it instead of use the mainline one. It's a bit of a mess, but I'd be really grateful if someone was able to take a look at that and get it working with the mainline one instead. Also, the stuff in the readme about there being demos and disc images needs to go. Better would be to explain how to create a zImage booting a net install Debian ISO. Looking back now, I wish I had wrote down how I did that.

If we could get the display working again and SDHC mainline driver working at the very least, that would be great. If we could simplify the USB stuff and have someone go through that and fix what I'm sure I partially broke along the way, then it wouldn't be that hard to maintain the patches for future versions.

[emu_kidid]

does the SDHC driver developed by _Nold_ need to be integrated to fix the above?

The driver _Nold_ wrote is for GameCube via SD card connected to one of the memory card slots (EXI), if you want to add that to wii linux, sure, but it's not required as there is a separate SD/SDHC driver for the Wii internal slot I'd imagine.

[novenary]

Does the Wii have a proper SD/MMC controller? I thought the slot was hooked up to EXI.

[emu_kidid]

Does the Wii have a proper SD/MMC controller? I thought the slot was hooked up to EXI.

http://wiibrew.org/wiki/Hardware/SD_Host_Controller

[neagix]

Thanks for your efforts on re-basing and testing the patches. It's been a few years since I looked at the code last, but if I remember correctly, why I stopped working on it was after an update in Debian Jessie while it was in Testing, there was no display. Basically things happened in outside life which lead to me moving and I lost the SD card in the process that had the OS on it and that left me to lose track of when the change occurred. I'm not sure if this is the same issue or not, but it could be related. As you probably know, there is an SDHC driver in the mainline kernel for the Wii, but why I didn't just use it was I couldn't figure out out what the issue was with just using it directly with the rest of the patch. So what I did was just re-base the driver from the patch into it instead of use the mainline one. It's a bit of a mess, but I'd be really grateful if someone was able to take a look at that and get it working with the mainline one instead. Also, the stuff in the readme about there being demos and disc images needs to go. Better would be to explain how to create a zImage booting a net install Debian ISO. Looking back now, I wish I had wrote down how I did that.

If we could get the display working again and SDHC mainline driver working at the very least, that would be great. If we could simplify the USB stuff and have someone go through that and fix what I'm sure I partially broke along the way, then it wouldn't be that hard to maintain the patches for future versions.

Hi there!! Glad you're around here

No worries, I was going to cleanup the README too. Will add also instructions how to build. Thanks for the pointers; the mainline SDHC does not seem to work either (I reverted the "SDHC fixes" commit during my attempts, still panics). I will try to see if it boots removing all changes (those from MIKEp5 patch) from the SDHC part.
I also will try the udbg-immortal to see if I can have any early serial output, doubt it though.

If anyone has information about the issues I posted in OP, please reply.

The driver _Nold_ wrote is for GameCube via SD card connected to one of the memory card slots (EXI), if you want to add that to wii linux, sure, but it's not required as there is a separate SD/SDHC driver for the Wii internal slot I'd imagine.

Thanks for the information. Will ignore it for now.

[neagix]

I have updated the post with recent information. The console issue can be ignored for now, we have a v3.x and v4.x tree with console support!

I am focusing on the SDHC issue.

I have found that this commit is responsible for the SDHC breakage.

Will report back if I manage to fix SDHC for the v3.x and v4.x trees.

Another update will include a root image distro and better documentation.

To try the kernels check out OP, where I put some instructions and links.

[liquitt]

kernel 2.6.32 is not bad and 3.x and 4.x might not give us THAT much since we're using butt-old hardware - nevertheless, love your work, keep going!

also, switch to the gc from that wii-thing

[Deltaresero]

The advantage to using a newer kernel is things like zRAM and ZCache RAM and cache compression become available for us to utilize along with several other bug fixes elsewhere. True not much has changed with the Gamecube and Wii stuff specifically, but a few useful things have been added along the way and it would be much easier to use a modern OS with it if we could get a modern Kernel working with it. Though as Debian dropped support for 32 bit PPC last year, the packages are there, but they aren't officially maintained past Stretch. https://www.phoronix.com/scan.php?page= ... hitectures

[neagix]

kernel 2.6.32 is not bad and 3.x and 4.x might not give us THAT much since we're using butt-old hardware - nevertheless, love your work, keep going!

also, switch to the gc from that wii-thing

Whether you are interested on Linux for Wii as an user or a developer, you always need (modern) software. Modern software runs on modern operative systems..so the goal is to extend the longevity of the hardware, and it's totally feasible.

The biggest roadblock is Xorg of course; but I will release something using framebuffers in the next days.

Also, I managed to pack Jessie with some tools and an updated MINI, I will release it soon, possibly tomorrow, as I polish everything up.

I am opening the issues on Github here: https://github.com/neagix/wii-linux-ngx/issues in case someone wants to contribute.

[neagix]

The advantage to using a newer kernel is things like zRAM and ZCache RAM and cache compression become available for us to utilize along with several other bug fixes elsewhere. True not much has changed with the Gamecube and Wii stuff specifically, but a few useful things have been added along the way and it would be much easier to use a modern OS with it if we could get a modern Kernel working with it.

Quite on point. If patches are maintained and merged upstream (that's hard of course..) there is hope of some cool projects coming along.

Though as Debian dropped support for 32 bit PPC last year, the packages are there, but they aren't officially maintained past Stretch. https://www.phoronix.com/scan.php?page= ... hitectures

Sad to hear I had forgotten about this, hopefully Emdebian keeps up after the official Debian stops.

[Sierron]

Also older version of programs who run on the old OS versions might have exploits or other bugs.

On another note. Is this topic only about the wii linux?

[neagix]

Also older version of programs who run on the old OS versions might have exploits or other bugs.

On another note. Is this topic only about the wii linux?

As I do not have the GameCube it means I cannot test my fork on it, however I will not voluntarily break support for the GC. If someone (or more) could test it on GC, that'd be great! I am actually kinda looking for someone that will test it regularly there too.

[Deltaresero]

Back in April of 2010, Albert Herranz did some work in getting swiotlb working with Wii consoles. Back around 2013, I ended up playing around with this and forward porting it to 2.6.36 on a local branch and everything seemed to work at the time, but going back to it now I can't seem to get it working. I can't remember what I did to get it working, but if anyone is interested, I'll leave the patches I tried to rebase here as well as a link to his repository that this came from. http://git.infradead.org/users/herraa1/ ... 2.6.34-rc5

[neagix]

Back in April of 2010, Albert Herranz did some work in getting swiotlb working with Wii consoles. Back around 2013, I ended up playing around with this and forward porting it to 2.6.36 on a local branch and everything seemed to work at the time, but going back to it now I can't seem to get it working. I can't remember what I did to get it working, but if anyone is interested, I'll leave the patches I tried to rebase here as well as a link to his repository that this came from. http://git.infradead.org/users/herraa1/ ... 2.6.34-rc5

Whoa, thanks for sharing this! What does swiotlb exactly bring to the Wii? I am a bit ignorant here..I googled around, it seems to allow advanced virtualization features?

[Deltaresero]

For us, basically it would allow for use of a software I/O TLB. Software Input Output Translation Lookaside Buffer allows for a much more configurable memory management interface. The physical address of the memory map (bounce buffer) is held in this virtual space of and I/O is bounced between the physical I/O and the physical memory by this virtual lookaside buffer. It allows for quicker memory mapping. It's faster than having it created physically in RAM and presented to the system as usable.

[neagix]

For us, basically it would allow for use of a software I/O TLB. Software Input Output Translation Lookaside Buffer allows for a much more configurable memory management interface. The physical address of the memory map (bounce buffer) is held in this virtual space of and I/O is bounced between the physical I/O and the physical memory by this virtual lookaside buffer. It allows for quicker memory mapping. It's faster than having it created physically in RAM and presented to the system as usable.

If I understand correctly, this would swipe away at once the reserved memory areas problem? And perhaps advantages for DMA and such?

[Deltaresero]

It would benefit for DMA, but I'm not sure about the reserved memory area problem due to my limited understanding of it. The Wii has two discontiguous RAM memory areas called MEM1 (24MB of 1T-SRAM) and MEM2 (64MB of DDR2 RAM). From what I understand, struct dma_map_ops and swiotlb here would act as a bounce buffer implementation allocating coherent buffers from MEM2 and to bounce to/from MEM2, but past this basic general concept of this I don't know. I remember when testing it, it seemed like ECHI was more responsive, but that's about all I remember. I think the code uses dmabounce currently.

[Sierron]

As I do not have the GameCube it means I cannot test my fork on it, however I will not voluntarily break support for the GC. If someone (or more) could test it on GC, that'd be great! I am actually kinda looking for someone that will test it regularly there too.

It would be nice if we can get it to work on GC as well. As I have both I could test on both of them when new version arrive but as far as I understand it's over console only, correct? So no video output yet. Would it be possible to ssh into the cube then?

[neagix]

As I do not have the GameCube it means I cannot test my fork on it, however I will not voluntarily break support for the GC. If someone (or more) could test it on GC, that'd be great! I am actually kinda looking for someone that will test it regularly there too.

It would be nice if we can get it to work on GC as well. As I have both I could test on both of them when new version arrive but as far as I understand it's over console only, correct? So no video output yet. Would it be possible to ssh into the cube then?

No, that issue was basically this: https://github.com/neagix/wii-linux-ngx/issues/2

So if you go through the Bootmii shell GUI, it boots fine! Only problem left is SDHC. I have updated the OP a couple of days ago to reflect this change in situation.

By the way, I have just uploaded everything here: https://github.com/neagix/wii-linux-ngx ... /tag/0.2.0

Just flash the disk image and give it a go

Tomorrow I will update documentation and release info. Btw, check out the README! I added a tool, baedit, to change bootargs from within the booted Wii Linux, it will be handy.

[Deltaresero]

I gave it a quick test and using just the image alone it appeared to hang using your BootMii files, but using my own, I got it to boot and have a display. Though after leaving it for about 5 minutes, I got a weird error on tty1 saying

Code: Select all

INIT: ID "TO" respawning too fast: disabled for 5 minutes

and it repeats every 5 minutes. Perhaps something wrong with your your "/etc/inittab"?

[neagix]

I gave it a quick test and using just the image alone it appeared to hang using your BootMii files, but using my own, I got it to boot and have a display.

Mmh..weird. I compiled armboot.bin from these sources: https://github.com/neagix/mini

It works fine here..any idea what it could be?

Though after leaving it for about 5 minutes, I got a weird error on tty1 saying

Code: Select all

INIT: ID "TO" respawning too fast: disabled for 5 minutes

and it repeats every 5 minutes. Perhaps something wrong with your your "/etc/inittab"?

Oh thanks for reporting, that's a minor annoyance though. You can just go to the second VT with Ctrl+Alt+F2 and login as usual.
That error is due to the login terminal I run on the ttyUSB0 serial which obviously you don't have connected, will fix it in next release.

Everything else working ok?

[Deltaresero]

Why are you using fat16 and ext3 instead of fat32 and ext4 or maybe jfs?
The way the network stuff is set up is a bit confusing. A typical user I assume would expect to be able to configure the network either in /etc/network/interfaces or using wpasupplicant and configuring /etc/wpasuppicant/wpasuppicant.conf which doesn't seem to exist nor is even looked at by what you have there.

Another minor annoyance I have not specific to your kernel or disc image is with how the OS and Wii System menu keep adjusting the clock on each other. I know before Debian Squeeze I didn't have this issue, and then part way through Wheezy while it was in Testing, it showed up. Perhaps it's how I'm configuring the timezones. As for the armboot binary, I don't really know.

So far from testing everything seems to running OK with the 3.14.16 kernel. It'd be REALLY great if at some point we could have someone take a look at that mainline SDHC driver and fix what's missing there so we can just use that one instead of this one from 2.6.32 rebased with the mainline one mostly reverted.

[neagix]

Why are you using fat16 and ext3 instead of fat32 and ext4 or maybe jfs?

FAT16 is needed by Bootmii, ext3 vs ext4 is not a big deal, just change it in fstab. ext3 in general is more compatible.

The way the network stuff is set up is a bit confusing. A typical user I assume would expect to be able to configure the network either in /etc/network/interfaces or using wpasupplicant and configuring /etc/wpasuppicant/wpasuppicant.conf which doesn't seem to exist nor is even looked at by what you have there.

wpasupplicant is installed, and as wrote in README there is whiite's wizard script in /root https://github.com/neagix/wii-linux-ngx ... g-to-wi-fi

Another minor annoyance I have not specific to your kernel or disc image is with how the OS and Wii System menu keep adjusting the clock on each other. I know before Debian Squeeze I didn't have this issue, and then part way through Wheezy while it was in Testing, it showed up. Perhaps it's how I'm configuring the timezones./quote]
Didn't notice this but I guess it should be possible to fix it easily. Issue in GH to track this?

So far from testing everything seems to running OK with the 3.14.16 kernel. It'd be REALLY great if at some point we could have someone take a look at that mainline SDHC driver and fix what's missing there so we can just use that one instead of this one from 2.6.32 rebased with the mainline one mostly reverted.

What it takes is: starting from my stable-v3.x (which contains your revert) start going upwards up to v3.16.1 (known one with SDHC broken), and identify which commit breaks it. I am slowly progressing on that one, I will eventually continue the bisect but if anyone else wants to pick it up just say it on the issue https://github.com/neagix/wii-linux-ngx/issues/1

Once that is identified (and hopefully fixed), one can go a bit forward on v4.x; not till the latest though, as v4.12 requires some more work on DMA.

[Deltaresero]

That's weird. I use Fat32 with BootMii and it's always worked fine on my end. Not a huge difference between ext3 and ext4, but I found it generally ran better on my system. Anyway, I figured out why your BootMii files weren't working for me and now I feel silly. You have it set to VIDEO=PROGRESSIVE and it seems my television needs VIDEO=NTSC.

wpasupplicant is installed, and as wrote in README there is whiite's wizard script in /root https://github.com/neagix/wii-linux-ngx ... g-to-wi-fi

I didn't notice the ReadMe got updated with that. I was thinking DHCP wired connections should work out of the box too, but it doesn't seem to. I'll take a look at that Whiite's network script here in a bit.