Open neagix opened 7 years ago
DeltaResero
commented
7 years ago It seems almost like the Wii isn't shutting down properly. Not sure if it's related or not, but I've noticed that when I boot into MINI from BootMii with the rebased patches I did and then restart, when I get back to the Wii Warning Heath and Safety Screen, I'm unable to sync my Wii Remotes normally forcing me to use the red sync bottom on both console and remote.
neagix
commented
7 years ago @DeltaResero oh yes, I noticed that too. It's happening every time, I didn't know it's a new bug from v2.6 kernels.
And that's also why I have set Bootmii to be booted directly through Priiloader, to avoid having to use the Wiimote.
Edit: Rather than not proper shutdown, could it be that the memory where bluetooth info is stored (perhaps in Starlet?) get corrupted? I am a Wii internals noob, so that's just a wild guess from me.
The way I thought we could fix this is either by disassembling the Bootmii GUI shell (too much work), or asking the original authors to release the source code or at least an example using the video. Or by just using some other ELF loader that initializes the video, then perhaps we can move those init bits either to MINI or even better to the kernel itself, as the v2.6 kernel didn't seem to need this video "handover" from Bootmii.
neagix
commented
7 years ago I am thinking that maybe the kernel changed the way it does I2C initialization and now it happens somehow after the framebuffer, so the framebuffer doesn't have the I2C client to the AVE chipset?
This should be relatively easy to verify.
neagix
commented
7 years ago @DeltaResero as you mentioned the cf imageblit speedup commit (ce63afebd79db8b0b7c085387311814e668c4bd7), I can confirm it does not affect this problem or the issues remaining in #6. I still think it's some I2C race condition e.g. frame buffer initialised before AVE is initialised
neagix
commented
7 years ago I added the kernel message; apparently it fails to request the memory, very strange. And that is always ignored..because memory is shared, I guess.
Also the other errors about AVE, always there even when this bug doesn't verify:
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.107659] gcn-vifb: Nintendo GameCube/Wii Video Interface (VI) driver - version 2.2
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.107670] gcn-vifb: options: tv=auto
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.109053] gcn-vifb: failed to request video memory at 01698000
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.109110] gcn-vifb: framebuffer at 0x01698000 mapped to 0xd4080000, size 1440k
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.110057] gcn-vifb: virtual framebuffer at 0xd41e9000, size 2880k
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.110065] gcn-vifb: could not get video format from AVE: -19
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.110070] gcn-vifb: NTSC 480iDCR
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.110075] gcn-vifb: unable to attach AVE: error -22
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.110093] gcn-vifb: mode is 576x432x16 (FOURCC colorspace = 0x0)
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.169748] Console: switching to colour frame buffer device 72x27
Aug 16 13:55:08 wii-linux-ngx kernel: [ 0.219713] fb0: gcn-vifb frame buffer deviceI think the problem is two-fold:
marcan
commented
7 years ago If you need anything from the BootMii UI just tag me and ask, though it seems the main issue is on the Linux side here. Obviously if you don't talk to AVE you won't get any video, especially on cold boot.
FWIW our initialization order is framebuffer first, AVE second. AVE is a purely passive device as far as the GPU is concerned; I also don't think AVE cares if its input changes, so initialization order may not matter, but the logical order is FB first, AVE second.
neagix
commented
7 years ago @marcan thanks for commenting, didn't know you were on Github. Yes I am narrowing down the problem and basically I believe the wii.dts file is not in good shape.
I think AVE stays initialized across a CPU reset, and that's why things work after hopping through the BootMii UI.
Look here (device with correspondent compatible field):
...
/hollywood/mini@0d000000/i2c-video virtual,i2c-gpio
/hollywood/mini@0d000000/i2c-video/audio-video-encoder@70 nintendo,wii-ave-rvl
...hollywood-pinintendo and hollywood-vinintendo don't seem right. At the moment I have no idea how this is happening..dt_stat script.
My current theory is that somehow the device doesn't get probed because either is taken by some other driver or doesn't match.
marcan
commented
7 years ago Where are you getting that dump from? That looks like it's concatenating multiple 'compatible' values. The real DTS looks like:
compatible = "nintendo,hollywood-pi",
"nintendo,flipper-pi";AVE is supposed to be nested under /hollywood/mini@0d000000/i2c-video FWIW
neagix
commented
7 years ago @marcan yeah, the device tree in procfs uses \0 as separator, that was why. I have edited the comment.
Yes, AVE is there in that path. It is really not getting a driver though (if I am not interpreting wrong):
# find /sys/devices/ -name uevent -exec grep -H video \{\} \;
/sys/devices/hollywood.0/d000000.mini/i2c-video.2/uevent:OF_NAME=i2c-video
/sys/devices/hollywood.0/d000000.mini/i2c-video.2/uevent:OF_FULLNAME=/hollywood/mini@0d000000/i2c-video
/sys/devices/hollywood.0/d000000.mini/i2c-video.2/uevent:MODALIAS=of:Ni2c-videoT<NULL>Cvirtual,i2c-gpio
/sys/devices/hollywood.0/c002000.video/uevent:OF_NAME=video
/sys/devices/hollywood.0/c002000.video/uevent:OF_FULLNAME=/hollywood/video@0c002000
/sys/devices/hollywood.0/c002000.video/uevent:MODALIAS=of:NvideoT<NULL>Cnintendo,hollywood-viCnintendo,flipper-viEdit: for the records, the device that should get the driver is /proc/device-tree/hollywood/mini@0d000000/i2c-video/audio-video-encoder@70
neagix
commented
7 years ago There is no /dev/i2c-0 and that explains why the AVE gets no device and no driver.
Regarding i2c, I put all my suspects on the i2c-gpio-of but I am really not that good to debug this. It's either a regression on the patches by @DeltaResero from v2.6 to v3.x, or a bug introduced through other commits by other kernel developers in the v3.x tree.
By the way, the only nodes without a device are those of IOS (makes sense when booting in MINI mode) and this one for the AVE, which instead should be there.
By reading around I have found that we could in theory change it to be a more explicit initialisation: http://elixir.free-electrons.com/linux/v3.15.10/source/Documentation/i2c/instantiating-devices
However, changing this now resembles more "shotgun debugging" than rather finding out why i2c simply stopped working.
Elsewhere I've read that the I2C might simply be not in the correct state, but I also want to exclude this as I believe MINI does all the correct initialisation (since it works with v2.6).
I have also checked the patches by @DeltaResero and they seem fine, the DTS specifies reg = <0x0d8000c0 0x40> and GPIOs 16,17
Starting from a completely shutdown Wii, with zImage to boot via default through mini:
Starting from a completely shutdown Wii, with Bootmii shell GUI selected to boot via default through mini:
It took a while to figure this out, but it's reproducible. ~The bug must be in the
tv=autodetection, combined with something that stays alive in GPU across reboots.~ Update: the bug is due to the fact/dev/i2c-0does not exist, so basically AVE is never probed.Update: Now I managed to grab the kernel messages relative to the framebuffer:
Note that the errors are identical when the graphics are correctly working.