msm8660/tenderloin video artifacts

[mboudr35]

Good day!

I seem to be running into some video artifacts during boot on my HP TouchPad when using the msm8660 branch.
I'm using the kernel configuration provided in the wiki of this repo.

I've recorded a demonstration video viewable here.
(This is a recording for a build from my own tree here, where I've cherry-picked your a5f9a06 and e820bd2 commits. I've enabled the simple framebuffer to get the bootup log to display. The result is nearly identical to what I get with your tree. My kconfig for my tree here)

Have you witnessed anything similar?
Cheers!

[flto]

Hi,

No, I don't remember seeing something like that. Have you tried my msm8660 branch as-is? If it works with that, it would reduce the number of possbilities.

If there is interest I could do a rebase of my branch (assuming my touchpad still works).

[flto]

Sorry, I read it too quickly, so it is broken with my tree too then?

[mboudr35]

Yes, I did experience something very similar with your tree.
Only change I made was to patch with this to get the build to succeed

[flto]

I just built my tree and booted it on my touchpad (after it charged enough to boot), it works without glitches. I also notice my display is rotated 180 degrees compared to your video (usb port comes out from the left.. it is flipped compared to bootloader/TWRP) , maybe the display hardware is not the same? (its been a long time since I looked at HP touchpad stuff, maybe there were 2 different possible displays?)

[mboudr35]

I suppose it could be the case that there's differing display hardware, though I've not noticed any indication of such in the older 3.4 kernel board code. I am able to get graphical output to work with TWRP, so I don't think anything on my end is broken.

Are you aware of any UART/serial console ports on the device? Maybe something is being logged but the screen bugs out before it's displayed

[mboudr35]

Something else I've noticed is that on reboots, the artifact "halo" persists for a few seconds then slowly fades away. I'd expect that the framebuffer region is wiped on reboots so don't think I can call it a memory write bug, but I'm not sure I'd really call it burn-in either (not even sure if that's possible with this panel type)

[flto]

FYI, I've just pushed a rebased msm8660 branch (on top of latest upstream), and updated my config file too. Seems mesa (latest master branch) is a bit broken on Adreno 220 though, so rendering things with the GPU is a bit funky (I've only been testing Adreno 200), I might fix it at some point.

(this won't help with your problem though)

[mboudr35]

Not too sure if this would have anything to do with it... Which toolchain are you using?
I'm on Fedora 32, so I've tried the arm-none-eabi compiler packaged there (gcc 9.2).
Also given the Linaro/ARM builds for 8.3 and 9.2 targeting arm-linux-gnueabihf a shot with no dice

[mboudr35]

Gave the latest stable debian a shot (seems to be what you're using based off your defconfig header) with no luck, so that rules my previous post out.
Is yours a 32GB model? If there is a hardware difference I wonder if it's tied to that

[flto]

Mine is a 16GB model, so I guess it could be related to that.