I2C for AVE not detected #2
Comments
neagix
changed the title
|
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. |
|
@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? 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. |
|
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. |
|
@DeltaResero as you mentioned the cf imageblit speedup commit (ce63afe), 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 |
|
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: |
|
I think the problem is two-fold:
|
|
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. |
|
@marcan thanks for commenting, didn't know you were on Github. Yes I am narrowing down the problem and basically I believe the 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):
My current theory is that somehow the device doesn't get probed because either is taken by some other driver or doesn't match. |
|
Where are you getting that dump from? That looks like it's concatenating multiple 'compatible' values. The real DTS looks like: |
|
AVE is supposed to be nested under /hollywood/mini@0d000000/i2c-video FWIW |
|
@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 |
|
There is no Regarding i2c, I put all my suspects on the 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 |
neagix
changed the title
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 thetv=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.
The text was updated successfully, but these errors were encountered: