Python Help - Second ILI9341 Display White After Pi Update

[obsidianspider]

It looks like I'm not the first one to notice the BCM2835 issue. Even our RetroPie team has noticed it.

[obsidianspider]

After running the Raphnet fix, the CPU is once again reporting as BCM2835, so that's the issue, apparently the kernel coders have decided to correctly report the chip, which ultimately is a good thing, but it breaks this Adafruit script. Now to try to fix it again on the new image.

[obsidianspider]

Sure enough, fixing the GPIO module to tell it that it's a BCM2835 resulted in the same garbled image. Which tells me that something else is looking for that BCM2709 and is freaking out because it can't find it.

Oh well, at least I'm getting somewhere.

Time to pop the original SD card back in.

[obsidianspider]

I can't seem to tell if the issue is with the new kernel, or another piece in the Adafruit libraries that is somehow misidentifying the SOC.

I can see this being a bigger problem going forward too, because in doing a search for BCM2709 on my machine I see that Adafruit's retrogame also uses BCM2709 to determine GPIO layout.

I wonder if this is something I should bring up on Github? I'm not even sure how to do that exactly.

[obsidianspider]

I sent a message via the feedback link on Adafruit's site, but not sure if that will do anything.

[obsidianspider]

I also put a message up over at the Adafruit forums since Github says to try there first .

[herb_fargus]

@obsidianspider just throwing this out there but might be mutually beneficial if adafruit were willing to work on a module with us for inclusion with the setup script (more people would probably buy their hardware if there was an "easier" setup) I've been meaning to make a handheld (one day!)

[obsidianspider]

@herb_fargus This particular library wouldn't help with a handheld as it's just for static images, but they do have others that are used in their handheld kids/projects for enabling TFTs and also their Retrogame library (which I plan to use with a Pi 3 if I can get the 3 trimmed down enough to fit).

If I didn't need the "Northwest Fix" I'd reimage my spare SD card again, and be done with it, but I think that's shortsighted, because eventually that BCM2835 identifier will find its way into "regular" updates and then all kinds of stuff is going to break, as BuZz pointed out in that Github thread.

I'm hopeful someone will figure out what's going on with that garbled output, but I don't know if the updated kernel is causing issues, if the libraries Adafruit is using is doing something weird, or if my code modification to cause the platform to be detected as a Pi is to blame.

I don't know enough about Python, programming, hardware, or Linux to fully grasp this, but I'm sure as heck learning a lot as I've been digging into the issue.

[obsidianspider]

More confirmation that there's likely something up with SOC identification. When I was updating my Genesis Pi I noticed that the kernel was updated to 20170303, so I figured I'd update my Super Famicom Pi just to see what happens. Sure enough, after applying the new kernel, the SOC is once again identifying as BCM2709 and the screen is working correctly. That darn "Northwest" problem is back again though, so I'm going to try re-running the fix and see how that goes. If I knew where in the kernel source the SOC hardware identification was located I'd just change it, but I don't know where to look.

[obsidianspider]

It's working!

I reapplied the Raphnet kernel patch. The CPU is once again showing as BCM2835, but my screen's output is fixed! It looks like the 20170303 version of the kernel fixed the issue.

I'm really going to think twice about updating the software on my now working Super Famicom Pi.