Open GoogleCodeExporter opened 8 years ago
Okay, now that it's fixed by making the IOS let go of Bluetooth before
switching, it's now the keyboard (and possibly all of USB) that gets stuck
Original comment by maxternal
on 6 Aug 2013 at 9:10
Okay, NOW we got the USB working.
the problem is that the Bluetooth and USB problems were only really valid for
the v2.6 kernel.
The v3.X kernels have ALWAYS just black screened when using this loading method
... and this last fix didn't change that.
It also automatically resets after 180 seconds just like the v2.6 kernel did
what it couldn't mount the root filesystem BUT the v3.X kernels don't have the
verbose output on screen to let us know what exactly is going wrong this time.
Original comment by maxternal
on 4 Sep 2013 at 1:42
The 3.x kernels that I patched all have "quiet" by default in the bootargs in
the "arch/powerpc/boot/dts/wii.dts" unlike the 2.6.x kernels. Just edit the
wii.dts file prior to compiling or edit the binary with a hex editor and put a
character (such as "_") in the empty space between "quiet" and the following
argument. I've added two MINI zImages with debug output enabled below. If the
2.6.34 one works, than it means that eventually I might be able to locate the
issue with git bisect. The 3.0.101 also was compiled with panic output enabled
and logging level set to 1 (most verbose) and should give the most useful
output of the two.
Original comment by deltares...@zoho.com
on 5 Dec 2013 at 5:30
Actually, with those two (on my Wii, at least) the 3.0.101 kernel just resets
back to the Wii menu and the 2.6.34 one is also a black screen BUT it does
reset the console after the standard 3 minute wait.
Original comment by maxternal
on 16 Dec 2013 at 9:39
It seems there was a bug in the outdated version of Debian causing input values
in bash to differ from what was being processed in bash. In this case, it was
1 input = 3 processed according to the logs; therefore those images are MINI
instead of IOS. Instead can someone test whether this one works too (I
combined the debugging from 3.0.101 with 2.6.34.14. Also, thanks for testing
those images Maxternal. I removed the images. If this doesn't work on WiiU
using both methods as I'm assuming it won't, than that will narrow it down to
about 1/10 of the commits that could be the cause.
Original comment by deltares...@zoho.com
on 17 Dec 2013 at 2:30
Attachments:
ok, a little correction to my previous statement:
my last statement was trying them with no filesystem ... WITH a file system the
2.6.34-debug one boots fine when done normally and when the no--bootmii method
is used it get's to here http://imageshack.com/scaled/large/13/q5zi.jpg (that's
all it ever shows on the screen and then resets the console after 3 minutes
with that on the screen)
The 3.0.101 and the newest 2.6.34.14 one, maybe I'm not extracting them
correctly (the packed folder structure of the working 2.6 one seems different)
but they both seem to have an extra header of some sort (which is why it resets
immediately because it doesn't recognize the file format on them) and when I
strip that off with a hex editor it gives me an unexpected end of file error
when loading it.
Original comment by maxternal
on 18 Dec 2013 at 3:10
Well, at least now we know that it initializes and makes it to runlevel 2 which
should help track down the issue a bit easier. As for the extra header, I'm
not sure what's causing that, though if I had to guess; I would assume it was
something done early on when I was first learning how forward port the patches.
The extra header is currently also likely in all the later 3.X kernels too.
Original comment by deltares...@zoho.com
on 25 Dec 2013 at 3:08
Original issue reported on code.google.com by
maxternal
on 17 Jul 2013 at 9:37