search

crowell / gbadev

Automatically exported from code.google.com/p/gbadev
0 stars 0 forks source link

no-bootmii-IOS code is making linux v3.X black screen #9

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I can only assume this is because the IOS isn't shut down properly and leaving 
unsolved issues with Bluetooth (not turning it off or something of that nature) 
that would usually taken care of automatically when reloading the IOS the 
normal way.

Original issue reported on code.google.com by maxternal on 17 Jul 2013 at 9:37

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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