Hi, I have now rebased our tree to v5.0-rc1. Was not very difficult. Just 3 or 4 almost obvious minor merge conflicts.
Unfortunately there is always something broken afterwards...
This time it is the display of the GTA04 :( Backlight works and can be controlled by "xset dpms" but the panel shows all white pixels. Pyra and BeagleBoneBlack + LCD both work this time.
Some first observations from initial tests: * Pyra: bluetooth uart does not respond (wifi works) * GTA04A4: backlight ok, display shows white pixels only * BBB+LCDC: display ok, backlight is always on (but does not respond to "xset dpms")
Other than this I have removed our dedicated w2sg00x4 driver in favor of the upstream SiRF driver. This removes two functions the dedicated driver did have: a) CONFIG_GNSS_DEBUG for testing if power-on/off really works b) "rfkill gps" to turn off the LNA but keep the w2sg active
It seems to have bug because I got this:
root@letux:~# cat /dev/gnss0 [ 272.211090] gnss gnss0: failed to runtime resume: -22 cat: /dev/gnss0: Invalid argument root@letux:~#
Finally, I have something important for the SGX driver with DDK1.9 AND DDK1.14. I have found a not too old description how to make it work on BBB:
https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston#File_powervr....
This already allowed me to identify some aspects I should take care of when debugging and trying to make our 1.14 driver work. The good thing is that this are instructions where we know that they work on a piece of hardware we have and can take it as a reference. Until it also works in our setup.
For the GTA04 and Pyra *we* are those who should know best and be able to tell others how to make it work...
Generally I would like to invite to test and report as many bugs as possible, ideally to the bug tracker.
BR, Nikolaus
On Mon, 18 Mar 2019 21:04:14 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I have now rebased our tree to v5.0-rc1. Was not very difficult. Just 3 or 4 almost obvious minor merge conflicts.
Unfortunately there is always something broken afterwards...
This time it is the display of the GTA04 :( Backlight works and can be controlled by "xset dpms" but the panel shows all white pixels. Pyra and BeagleBoneBlack + LCD both work this time.
Some first observations from initial tests:
- Pyra: bluetooth uart does not respond (wifi works)
- GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Regards, Andreas
Am 19.03.2019 um 12:52 schrieb Andreas Kemnade andreas@kemnade.info:
On Mon, 18 Mar 2019 21:04:14 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I have now rebased our tree to v5.0-rc1. Was not very difficult. Just 3 or 4 almost obvious minor merge conflicts.
Unfortunately there is always something broken afterwards...
This time it is the display of the GTA04 :( Backlight works and can be controlled by "xset dpms" but the panel shows all white pixels. Pyra and BeagleBoneBlack + LCD both work this time.
Some first observations from initial tests:
- Pyra: bluetooth uart does not respond (wifi works)
- GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Interesting. I did this:
iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3-gta04.dtsi iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3-gta04a4.dts iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3.dts iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap36xx.dts iMac:master hns$
So there are no obvious differences between dts...
I think we have to use the dtc to disassemble the binaries (sorted by node) and then diff.
BR and thanks, Nikolaus
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 19.03.2019 um 12:52 schrieb Andreas Kemnade andreas@kemnade.info:
On Mon, 18 Mar 2019 21:04:14 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I have now rebased our tree to v5.0-rc1. Was not very difficult. Just 3 or 4 almost obvious minor merge conflicts.
Unfortunately there is always something broken afterwards...
This time it is the display of the GTA04 :( Backlight works and can be controlled by "xset dpms" but the panel shows all white pixels. Pyra and BeagleBoneBlack + LCD both work this time.
Some first observations from initial tests:
- Pyra: bluetooth uart does not respond (wifi works)
- GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Interesting. I did this:
iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3-gta04.dtsi iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3-gta04a4.dts iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3.dts iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap36xx.dts iMac:master hns$
So there are no obvious differences between dts...
I think we have to use the dtc to disassemble the binaries (sorted by node) and then diff.
Hm...
Unless I did something wrong, the diff is empty!? Even the binaries do match:
iMac:master hns$ ls -l build/letux-5.0/device-trees/omap3-gta04a4.dtb -rw-r--r-- 1 hns staff 71513 8 Mär 21:35 build/letux-5.0/device-trees/omap3-gta04a4.dtb iMac:master hns$ ls -l build/letux-5.1-rc1/device-trees/omap3-gta04a4.dtb -rw-r--r-- 1 hns staff 71513 18 Mär 20:10 build/letux-5.1-rc1/device-trees/omap3-gta04a4.dtb iMac:master hns$ diff build/letux-5.0/device-trees/omap3-gta04a4.dtb build/letux-5.1-rc1/device-trees/omap3-gta04a4.dtb iMac:master hns$
Strange.
BR, Nikolaus
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 19.03.2019 um 12:52 schrieb Andreas Kemnade andreas@kemnade.info:
On Mon, 18 Mar 2019 21:04:14 +0100 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi, I have now rebased our tree to v5.0-rc1. Was not very difficult. Just 3 or 4 almost obvious minor merge conflicts.
Unfortunately there is always something broken afterwards...
This time it is the display of the GTA04 :( Backlight works and can be controlled by "xset dpms" but the panel shows all white pixels. Pyra and BeagleBoneBlack + LCD both work this time.
Some first observations from initial tests:
- Pyra: bluetooth uart does not respond (wifi works)
- GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Interesting. I did this:
iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3-gta04.dtsi iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3-gta04a4.dts iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap3.dts iMac:master hns$ git diff letux-5.0 letux-5.1-rc1 -- arch/arm/boot/dts/omap36xx.dts iMac:master hns$
So there are no obvious differences between dts...
I think we have to use the dtc to disassemble the binaries (sorted by node) and then diff.
Hm...
Unless I did something wrong, the diff is empty!? Even the binaries do match:
So maybe that is something in letux stuff.
Regards, Andreas
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
- GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I guess the problem is either the SPI interface to the panel or the pixel clock/pixel data.
I am currently running a bisect to find out more.
BR, Nikolaus
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
- GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I guess the problem is either the SPI interface to the panel or the pixel clock/pixel data.
I am currently running a bisect to find out more.
First result:
67e79a6dc2664a3ef85113440e60f7aaca3c7815 is the first bad commit
i.e.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
But what does this have to do with the GTA04 display and backlight power???
I fear a side-effect of an array out of bounds write like we did have a while ago.
Or I did make a mistake in reporting good/bad to git bisect. Maybe I should repeat.
Note this is using mainline linux (bisected) + letux/compile-fixes + letux/arm_defconfig + letux/Letux + letux/ubi-fs and nothing else. So it does not include many of the Letux hacks.
BR, Nikolaus
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
> * GTA04A4: backlight ok, display shows white pixels only
hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
So we could probably check
cat /sys/class/backlight/backlight/bl_power
after boot to automate the bisect (1 = bad, 0 = good).
I guess the problem is either the SPI interface to the panel or the pixel clock/pixel data.
I am currently running a bisect to find out more.
First result:
Here is a new result after repeating with git bisect start '--no-checkout' '--' 'arch/arm' 'include/' 'drivers/'
f90d64483ebd394958841f67f8794ab203b319a7 is the first bad commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
67e79a6dc2664a3ef85113440e60f7aaca3c7815 is the first bad commit
i.e.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
But what does this have to do with the GTA04 display and backlight power???
Same question for the new result... This time it is a different merge. In both cases a merge of subsystem updates and not a single patch. Strange.
I fear a side-effect of an array out of bounds write like we did have a while ago.
Or I did make a mistake in reporting good/bad to git bisect. Maybe I should repeat.
Note this is using mainline linux (bisected) + letux/compile-fixes + letux/arm_defconfig + letux/Letux + letux/ubi-fs and nothing else. So it does not include many of the Letux hacks.
So at the moment I have no good idea how to debug it. Maybe we should wait until v5.1-rc2 is out. Someone else might have a similar issue or a late fix is provided that is missing in v5.1-rc1.
BR, Nikolaus
Am 21.03.2019 um 07:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
>> * GTA04A4: backlight ok, display shows white pixels only > > hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok > 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
So we could probably check
cat /sys/class/backlight/backlight/bl_power
after boot to automate the bisect (1 = bad, 0 = good).
I guess the problem is either the SPI interface to the panel or the pixel clock/pixel data.
I am currently running a bisect to find out more.
First result:
Here is a new result after repeating with git bisect start '--no-checkout' '--' 'arch/arm' 'include/' 'drivers/'
f90d64483ebd394958841f67f8794ab203b319a7 is the first bad commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
67e79a6dc2664a3ef85113440e60f7aaca3c7815 is the first bad commit
i.e.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
But what does this have to do with the GTA04 display and backlight power???
Same question for the new result... This time it is a different merge. In both cases a merge of subsystem updates and not a single patch. Strange.
I fear a side-effect of an array out of bounds write like we did have a while ago.
Or I did make a mistake in reporting good/bad to git bisect. Maybe I should repeat.
Note this is using mainline linux (bisected) + letux/compile-fixes + letux/arm_defconfig + letux/Letux + letux/ubi-fs and nothing else. So it does not include many of the Letux hacks.
So at the moment I have no good idea how to debug it. Maybe we should wait until v5.1-rc2 is out. Someone else might have a similar issue or a late fix is provided that is missing in v5.1-rc1.
Some more observations (in failed state):
a) panel driver is loaded
root@letux:~# lsmod|fgrep td0 panel_tpo_td028ttec1 16384 3 omapdss_base 16384 5 connector_analog_tv,encoder_opa362,panel_tpo_td028ttec1,omapdrm,omapdss root@letux:~#
b) video cards are initialized
root@letux:~# ls -l /sys/devices/platform/omapdrm.0/drm/card0/card0-* /sys/devices/platform/omapdrm.0/drm/card0/card0-DPI-1: total 0 lrwxrwxrwx 1 root root 0 Mar 21 07:11 device -> ../../card0 -r--r--r-- 1 root root 4096 Mar 21 07:11 dpms -r--r--r-- 1 root root 0 Mar 21 07:11 edid -r--r--r-- 1 root root 4096 Mar 21 07:11 enabled -r--r--r-- 1 root root 4096 Mar 21 07:11 modes drwxr-xr-x 2 root root 0 Mar 21 07:06 power -rw-r--r-- 1 root root 4096 Mar 21 07:11 status lrwxrwxrwx 1 root root 0 Mar 21 07:11 subsystem -> ../../../../../../class/drm -rw-r--r-- 1 root root 4096 Mar 21 06:28 uevent
/sys/devices/platform/omapdrm.0/drm/card0/card0-SVIDEO-1: total 0 lrwxrwxrwx 1 root root 0 Mar 21 07:11 device -> ../../card0 -r--r--r-- 1 root root 4096 Mar 21 07:11 dpms -r--r--r-- 1 root root 0 Mar 21 07:11 edid -r--r--r-- 1 root root 4096 Mar 21 07:11 enabled -r--r--r-- 1 root root 4096 Mar 21 07:11 modes drwxr-xr-x 2 root root 0 Mar 21 07:06 power -rw-r--r-- 1 root root 4096 Mar 21 07:11 status lrwxrwxrwx 1 root root 0 Mar 21 07:11 subsystem -> ../../../../../../class/drm -rw-r--r-- 1 root root 4096 Mar 21 06:28 uevent root@letux:~#
c) the panel seems to be programmed through SPI
root@letux:/sys/bus/spi/drivers/panel-tpo-td028ttec1/spi4.0# for i in statistics/*; do echo $i $(cat $i); done statistics/bytes 202 statistics/bytes_rx 0 statistics/bytes_tx 202 statistics/errors 0 statistics/messages 48 statistics/spi_async 0 statistics/spi_sync 48 statistics/spi_sync_immediate 48 statistics/timedout 0 statistics/transfer_bytes_histo_0-1 0 statistics/transfer_bytes_histo_1024-2047 0 statistics/transfer_bytes_histo_128-255 0 statistics/transfer_bytes_histo_16-31 0 statistics/transfer_bytes_histo_16384-32767 0 statistics/transfer_bytes_histo_2-3 7 statistics/transfer_bytes_histo_2048-4095 0 statistics/transfer_bytes_histo_256-511 0 statistics/transfer_bytes_histo_32-63 0 statistics/transfer_bytes_histo_32768-65535 0 statistics/transfer_bytes_histo_4-7 41 statistics/transfer_bytes_histo_4096-8191 0 statistics/transfer_bytes_histo_512-1023 0 statistics/transfer_bytes_histo_64-127 0 statistics/transfer_bytes_histo_65536+ 0 statistics/transfer_bytes_histo_8-15 0 statistics/transfer_bytes_histo_8192-16383 0 statistics/transfers 48 statistics/transfers_split_maxsize 0 root@letux:/sys/bus/spi/drivers/panel-tpo-td028ttec1/spi4.0#
BR, Nikolaus
On Thu, 21 Mar 2019 07:05:18 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
>> * GTA04A4: backlight ok, display shows white pixels only > > hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok > 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
Well, if I do that on mainline, I get a working display. Not only black screen.
So we probably have a) some initilalisation race condition
or
b) some memory corruption.
Both are nasty.
Regards, Andreas
Hi Andreas,
Am 21.03.2019 um 07:18 schrieb Andreas Kemnade andreas@kemnade.info:
On Thu, 21 Mar 2019 07:05:18 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
> Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
>>> * GTA04A4: backlight ok, display shows white pixels only >> >> hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok >> 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
>
well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
Well, if I do that on mainline,
Hm. I am also doing that on mainline. Almost. Plus 4 patch sets which are not at all display related.
I have exactly these diffs to versions from linus/master:
iMac:master hns$ git diff --stat bisect Letux/README | 33 ++ arch/arm/configs/letux_defconfig | 6462 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ crypto/asymmetric_keys/Kconfig | 1 + drivers/mtd/ubi/io.c | 3 +- scripts/mod/file2alias.c | 2 + scripts/sortextable.c | 3 + security/selinux/include/classmap.h | 7 + 7 files changed, 6510 insertions(+), 1 deletion(-) iMac:master hns$
Besides letux_defconfig, most are to get the tree compiled (there are certain assumptions in upstream about the HOSTCC and its #include files which a Darwin host does not exactly fulfill).
The ubi patch is to silence issues with not well formatted NAND. The crypto diff is to select CONFIG_SYSTEM_TRUSTED_KEYRING (maybe this could be done directly in letux_defconfig without patching the Kconfig).
So how exactly are you "doing that on mainline"? omap2plus_defconfig or letux_defconfig? Device tree from linus/master or the letux one?
What I have not yet tried is to boot on GTA04A5.
I get a working display. Not only black screen.
So we probably have a) some initilalisation race condition
or
b) some memory corruption.
Both are nasty.
Indeed.
c) new compiler incompatibility
d) something incompatible in defconfig
BR, Nikolaus
Hi Andreas,
Am 21.03.2019 um 08:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Andreas,
Am 21.03.2019 um 07:18 schrieb Andreas Kemnade andreas@kemnade.info:
On Thu, 21 Mar 2019 07:05:18 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 19 Mar 2019 13:30:17 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
>> Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
>>>> * GTA04A4: backlight ok, display shows white pixels only >>> >>> hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok >>> 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
>> well, echo 0 >/sys/class/backlight/backlight/bl_power resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1
I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
Well, if I do that on mainline,
Hm. I am also doing that on mainline. Almost. Plus 4 patch sets which are not at all display related.
I have exactly these diffs to versions from linus/master:
iMac:master hns$ git diff --stat bisect Letux/README | 33 ++ arch/arm/configs/letux_defconfig | 6462 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ crypto/asymmetric_keys/Kconfig | 1 + drivers/mtd/ubi/io.c | 3 +- scripts/mod/file2alias.c | 2 + scripts/sortextable.c | 3 + security/selinux/include/classmap.h | 7 + 7 files changed, 6510 insertions(+), 1 deletion(-) iMac:master hns$
Besides letux_defconfig, most are to get the tree compiled (there are certain assumptions in upstream about the HOSTCC and its #include files which a Darwin host does not exactly fulfill).
The ubi patch is to silence issues with not well formatted NAND. The crypto diff is to select CONFIG_SYSTEM_TRUSTED_KEYRING (maybe this could be done directly in letux_defconfig without patching the Kconfig).
So how exactly are you "doing that on mainline"? omap2plus_defconfig or letux_defconfig? Device tree from linus/master or the letux one?
I have now tried:
git checkout v5.1-rc1 git merge letux/compile-fixes make omap2plus_defconfig
No change. Display is black and echo 0>bl_power makes it go white.
Next I'll check on GTA04A5.
And then I want to try the same starting with linux-next.
What I have not yet tried is to boot on GTA04A5.
I get a working display. Not only black screen.
So we probably have a) some initilalisation race condition
or
b) some memory corruption.
Both are nasty.
Indeed.
c) new compiler incompatibility
d) something incompatible in defconfig
BR, Nikolaus
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
Am 21.03.2019 um 10:03 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Andreas,
Am 21.03.2019 um 08:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Andreas,
Am 21.03.2019 um 07:18 schrieb Andreas Kemnade andreas@kemnade.info:
On Thu, 21 Mar 2019 07:05:18 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
> Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info: > > Hi, > > > On Tue, 19 Mar 2019 13:30:17 +0100 > "H. Nikolaus Schaller" hns@goldelico.com wrote: > >>> Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
>>>>> * GTA04A4: backlight ok, display shows white pixels only >>>> >>>> hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok >>>> 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen
Ah, I didn't read precisely: "black screen". I get this as well if I eliminate most Letux patch sets.
This means that one or two hacks are not yet upstream...
>>> > well, > echo 0 >/sys/class/backlight/backlight/bl_power > resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1 > > I think we are talking about different problems.
Looks so...
My main symptom is that I get a /dev/fb0, X server process is running, backlight is on, but the screen is completely white. And xset dpms force on/off can turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
Well, if I do that on mainline,
Hm. I am also doing that on mainline. Almost. Plus 4 patch sets which are not at all display related.
I have exactly these diffs to versions from linus/master:
iMac:master hns$ git diff --stat bisect Letux/README | 33 ++ arch/arm/configs/letux_defconfig | 6462 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ crypto/asymmetric_keys/Kconfig | 1 + drivers/mtd/ubi/io.c | 3 +- scripts/mod/file2alias.c | 2 + scripts/sortextable.c | 3 + security/selinux/include/classmap.h | 7 + 7 files changed, 6510 insertions(+), 1 deletion(-) iMac:master hns$
Besides letux_defconfig, most are to get the tree compiled (there are certain assumptions in upstream about the HOSTCC and its #include files which a Darwin host does not exactly fulfill).
The ubi patch is to silence issues with not well formatted NAND. The crypto diff is to select CONFIG_SYSTEM_TRUSTED_KEYRING (maybe this could be done directly in letux_defconfig without patching the Kconfig).
So how exactly are you "doing that on mainline"? omap2plus_defconfig or letux_defconfig? Device tree from linus/master or the letux one?
I have now tried:
git checkout v5.1-rc1 git merge letux/compile-fixes make omap2plus_defconfig
No change. Display is black and echo 0>bl_power makes it go white.
Next I'll check on GTA04A5.
No difference. Except that I had to disable the OneNAND to avoid this:
[ 3.175964] omap_hsmmc 480b4000.mmc: card claims to support voltages below defined range [ 3.203491] mmc1: new high speed SDIO card at address 0001 [ 3.210357] ubi0: scanning is finished [ 3.214172] ubi0: empty MTD device detected [ 3.219055] onenand_write_ops_nolock: verify failed -74 [ 3.224426] ubi0 error: ubi_io_write: error -74 while writing 1024 bytes to PEB 0:0, written 0 bytes [ 3.233642] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc1-00005-g70a8625-dirty #3541 [ 3.241943] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 3.248291] [<c011213c>] (unwind_backtrace) from [<c010caec>] (show_stack+0x10/0x14) [ 3.256072] [<c010caec>] (show_stack) from [<c0854db0>] (dump_stack+0xb8/0xd4) [ 3.263366] [<c0854db0>] (dump_stack) from [<c063e9b8>] (ubi_io_write+0x540/0x6c8) [ 3.270965] [<c063e9b8>] (ubi_io_write) from [<c063ec60>] (ubi_io_write_ec_hdr+0x120/0x184) [ 3.279388] [<c063ec60>] (ubi_io_write_ec_hdr) from [<c0644298>] (ubi_early_get_peb+0xcc/0x188) [ 3.288116] [<c0644298>] (ubi_early_get_peb) from [<c0633484>] (create_vtbl+0x94/0x25c) [ 3.296173] [<c0633484>] (create_vtbl) from [<c0634044>] (ubi_read_volume_table+0x80c/0xa48) [ 3.304656] [<c0634044>] (ubi_read_volume_table) from [<c0644440>] (ubi_attach+0xec/0x154) [ 3.312988] [<c0644440>] (ubi_attach) from [<c0637858>] (ubi_attach_mtd_dev+0x1e0/0x6b0) [ 3.321136] [<c0637858>] (ubi_attach_mtd_dev) from [<c0c44730>] (ubi_init+0x15c/0x230) [ 3.329101] [<c0c44730>] (ubi_init) from [<c0102fa8>] (do_one_initcall+0x48/0x204) [ 3.336730] [<c0102fa8>] (do_one_initcall) from [<c0c01128>] (kernel_init_freeable+0x26c/0x3a4) [ 3.345489] [<c0c01128>] (kernel_init_freeable) from [<c086d5c4>] (kernel_init+0x8/0x118) [ 3.353698] [<c086d5c4>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 3.361328] Exception stack(0xec8d7fb0 to 0xec8d7ff8) [ 3.366394] 7fa0: 00000000 00000000 00000000 00000000 [ 3.374603] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 3.382843] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 3.389739] ubi0: dumping 1024 bytes of data from PEB 0, offset 0 [ 3.395935] 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.409606] 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.423248] 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.436920] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.450592] 00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.464233] 000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.477905] 000000c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.491546] 000000e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.505218] 00000100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.518890] 00000120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.532531] 00000140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.546203] 00000160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.559875] 00000180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.573516] 000001a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.587188] 000001c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.600860] 000001e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.614501] 00000200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.628173] 00000220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.641815] 00000240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.655487] 00000260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.669158] 00000280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.682800] 000002a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.696472] 000002c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.710144] 000002e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.723785] 00000300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.737457] 00000320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.751129] 00000340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.764801] 00000360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.778472] 00000380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.792144] 000003a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.805786] 000003c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.819458] 000003e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.833587] onenand_write_ops_nolock: verify failed -74 [ 3.838867] ubi0 error: ubi_io_write: error -74 while writing 1024 bytes to PEB 1:0, written 0 bytes [ 3.848083] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc1-00005-g70a8625-dirty #3541 [ 3.856384] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 3.862731] [<c011213c>] (unwind_backtrace) from [<c010caec>] (show_stack+0x10/0x14) [ 3.870513] [<c010caec>] (show_stack) from [<c0854db0>] (dump_stack+0xb8/0xd4) [ 3.877777] [<c0854db0>] (dump_stack) from [<c063e9b8>] (ubi_io_write+0x540/0x6c8) [ 3.885406] [<c063e9b8>] (ubi_io_write) from [<c063ec60>] (ubi_io_write_ec_hdr+0x120/0x184) [ 3.893798] [<c063ec60>] (ubi_io_write_ec_hdr) from [<c0644298>] (ubi_early_get_peb+0xcc/0x188) [ 3.902557] [<c0644298>] (ubi_early_get_peb) from [<c0633484>] (create_vtbl+0x94/0x25c) [ 3.910614] [<c0633484>] (create_vtbl) from [<c0634044>] (ubi_read_volume_table+0x80c/0xa48) [ 3.919097] [<c0634044>] (ubi_read_volume_table) from [<c0644440>] (ubi_attach+0xec/0x154) [ 3.927398] [<c0644440>] (ubi_attach) from [<c0637858>] (ubi_attach_mtd_dev+0x1e0/0x6b0) [ 3.935546] [<c0637858>] (ubi_attach_mtd_dev) from [<c0c44730>] (ubi_init+0x15c/0x230) [ 3.943511] [<c0c44730>] (ubi_init) from [<c0102fa8>] (do_one_initcall+0x48/0x204) [ 3.951110] [<c0102fa8>] (do_one_initcall) from [<c0c01128>] (kernel_init_freeable+0x26c/0x3a4) [ 3.959869] [<c0c01128>] (kernel_init_freeable) from [<c086d5c4>] (kernel_init+0x8/0x118) [ 3.968109] [<c086d5c4>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 3.975708] Exception stack(0xec8d7fb0 to 0xec8d7ff8)
And then I want to try the same starting with linux-next.
I did:
git checkout next-20190321 git merge letux/compile-fixes git merge letux/ubi-fs make omap2plus_defconfig
Same symptoms. Which means we should not hope for a magic solution from linux-next.
So I did a cross-check:
git checkout v5.0 git cherry-pick letux-base..letux/compile-fixes # git merge would pull in v5.1-rc1 vi arch/arm/configs/omap2plus_defconfig # disable ONENAND make omap2plus_defconfig
And that fails as well! Strange.
So I did rebuild using git checkout letux-5.1-rc1 -- arch/arm/configs/letux_defconfig and now I have the display back!
This means that some CONFIG has an influence. Something which differs between omap2plus_defconfig and letux_defconfig.
What I have not yet tried is to boot on GTA04A5.
I get a working display. Not only black screen.
So we probably have a) some initilalisation race condition
Seems to be less plausible since I have exactly the same result on GTA04A4 and GTA04A5. And with v5.1-rc1 and ...
or
b) some memory corruption.
Both are nasty.
Indeed.
c) new compiler incompatibility
d) something incompatible in defconfig
I have also tried to find out what it means if git bisect reports a merge. The answers are not really unique. It depends... Especially if there are alternative histories in a tree it may happen that git bisect skips some commits or mixes up branches that were merged in. This might explain why I could not identify the offending commit and get a different result if I restrict the bisect to include/ arch/arm and drivers/
I could try to rebase v5.1-rc1 onto v5.0... This should resolve all merge commits and replace by plain commits in some sequence so that git bisect has a linear and unique history. It may work but it will more likely fail with merge conflicts. Anyways it is worth to try.
BR, Nikolaus
Am 21.03.2019 um 15:11 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 21.03.2019 um 10:03 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Andreas,
Am 21.03.2019 um 08:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Andreas,
Am 21.03.2019 um 07:18 schrieb Andreas Kemnade andreas@kemnade.info:
On Thu, 21 Mar 2019 07:05:18 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
HI,
Am 20.03.2019 um 16:31 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
> Am 20.03.2019 um 08:30 schrieb H. Nikolaus Schaller hns@goldelico.com: > > Hi, > >> Am 20.03.2019 um 08:19 schrieb Andreas Kemnade andreas@kemnade.info: >> >> Hi, >> >> >> On Tue, 19 Mar 2019 13:30:17 +0100 >> "H. Nikolaus Schaller" hns@goldelico.com wrote: >> >>>> Am 19.03.2019 um 13:16 schrieb H. Nikolaus Schaller hns@goldelico.com: > >>>>>> * GTA04A4: backlight ok, display shows white pixels only >>>>> >>>>> hmm, did a quick test with mainline: older dtb + 5.1-rc1 kernel = display ok >>>>> 5.1-rc1 kernel + dtb-5-1-rc1 (both mainline) = black screen > > Ah, I didn't read precisely: "black screen". I get this as well if I eliminate > most Letux patch sets. > > This means that one or two hacks are not yet upstream... > >>>> >> well, >> echo 0 >/sys/class/backlight/backlight/bl_power >> resolved that. Then I had a working display with mainline 5.1-rc1 + dtb-5.1-rc1 >> >> I think we are talking about different problems. > > Looks so... > > My main symptom is that I get a /dev/fb0, X server process is running, backlight > is on, but the screen is completely white. And xset dpms force on/off can > turn backlight on&off. But still only white pixels.
I have now checked and the symptoms are two facets of the same problem.
When doing my git bisect of linus/master plus adding only 4 of our letux patches, I get a black display in the error case which goes completely white when echoing to bp_power.
I never had the backlight staying black but display working.
But there remains some difference by adding the full letux patch set. I.e. some piece of code does have the same side effect as echo 0 >/sys/class/backlight/backlight/bl_power
Well, if I do that on mainline,
Hm. I am also doing that on mainline. Almost. Plus 4 patch sets which are not at all display related.
I have exactly these diffs to versions from linus/master:
iMac:master hns$ git diff --stat bisect Letux/README | 33 ++ arch/arm/configs/letux_defconfig | 6462 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ crypto/asymmetric_keys/Kconfig | 1 + drivers/mtd/ubi/io.c | 3 +- scripts/mod/file2alias.c | 2 + scripts/sortextable.c | 3 + security/selinux/include/classmap.h | 7 + 7 files changed, 6510 insertions(+), 1 deletion(-) iMac:master hns$
Besides letux_defconfig, most are to get the tree compiled (there are certain assumptions in upstream about the HOSTCC and its #include files which a Darwin host does not exactly fulfill).
The ubi patch is to silence issues with not well formatted NAND. The crypto diff is to select CONFIG_SYSTEM_TRUSTED_KEYRING (maybe this could be done directly in letux_defconfig without patching the Kconfig).
So how exactly are you "doing that on mainline"? omap2plus_defconfig or letux_defconfig? Device tree from linus/master or the letux one?
I have now tried:
git checkout v5.1-rc1 git merge letux/compile-fixes make omap2plus_defconfig
No change. Display is black and echo 0>bl_power makes it go white.
Next I'll check on GTA04A5.
No difference. Except that I had to disable the OneNAND to avoid this:
[ 3.175964] omap_hsmmc 480b4000.mmc: card claims to support voltages below defined range [ 3.203491] mmc1: new high speed SDIO card at address 0001 [ 3.210357] ubi0: scanning is finished [ 3.214172] ubi0: empty MTD device detected [ 3.219055] onenand_write_ops_nolock: verify failed -74 [ 3.224426] ubi0 error: ubi_io_write: error -74 while writing 1024 bytes to PEB 0:0, written 0 bytes [ 3.233642] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc1-00005-g70a8625-dirty #3541 [ 3.241943] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 3.248291] [<c011213c>] (unwind_backtrace) from [<c010caec>] (show_stack+0x10/0x14) [ 3.256072] [<c010caec>] (show_stack) from [<c0854db0>] (dump_stack+0xb8/0xd4) [ 3.263366] [<c0854db0>] (dump_stack) from [<c063e9b8>] (ubi_io_write+0x540/0x6c8) [ 3.270965] [<c063e9b8>] (ubi_io_write) from [<c063ec60>] (ubi_io_write_ec_hdr+0x120/0x184) [ 3.279388] [<c063ec60>] (ubi_io_write_ec_hdr) from [<c0644298>] (ubi_early_get_peb+0xcc/0x188) [ 3.288116] [<c0644298>] (ubi_early_get_peb) from [<c0633484>] (create_vtbl+0x94/0x25c) [ 3.296173] [<c0633484>] (create_vtbl) from [<c0634044>] (ubi_read_volume_table+0x80c/0xa48) [ 3.304656] [<c0634044>] (ubi_read_volume_table) from [<c0644440>] (ubi_attach+0xec/0x154) [ 3.312988] [<c0644440>] (ubi_attach) from [<c0637858>] (ubi_attach_mtd_dev+0x1e0/0x6b0) [ 3.321136] [<c0637858>] (ubi_attach_mtd_dev) from [<c0c44730>] (ubi_init+0x15c/0x230) [ 3.329101] [<c0c44730>] (ubi_init) from [<c0102fa8>] (do_one_initcall+0x48/0x204) [ 3.336730] [<c0102fa8>] (do_one_initcall) from [<c0c01128>] (kernel_init_freeable+0x26c/0x3a4) [ 3.345489] [<c0c01128>] (kernel_init_freeable) from [<c086d5c4>] (kernel_init+0x8/0x118) [ 3.353698] [<c086d5c4>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 3.361328] Exception stack(0xec8d7fb0 to 0xec8d7ff8) [ 3.366394] 7fa0: 00000000 00000000 00000000 00000000 [ 3.374603] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 3.382843] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 3.389739] ubi0: dumping 1024 bytes of data from PEB 0, offset 0 [ 3.395935] 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.409606] 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.423248] 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.436920] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.450592] 00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.464233] 000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.477905] 000000c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.491546] 000000e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.505218] 00000100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.518890] 00000120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.532531] 00000140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.546203] 00000160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.559875] 00000180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.573516] 000001a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.587188] 000001c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.600860] 000001e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.614501] 00000200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.628173] 00000220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.641815] 00000240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.655487] 00000260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.669158] 00000280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.682800] 000002a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.696472] 000002c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.710144] 000002e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.723785] 00000300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.737457] 00000320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.751129] 00000340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.764801] 00000360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.778472] 00000380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.792144] 000003a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.805786] 000003c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.819458] 000003e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................................ [ 3.833587] onenand_write_ops_nolock: verify failed -74 [ 3.838867] ubi0 error: ubi_io_write: error -74 while writing 1024 bytes to PEB 1:0, written 0 bytes [ 3.848083] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc1-00005-g70a8625-dirty #3541 [ 3.856384] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 3.862731] [<c011213c>] (unwind_backtrace) from [<c010caec>] (show_stack+0x10/0x14) [ 3.870513] [<c010caec>] (show_stack) from [<c0854db0>] (dump_stack+0xb8/0xd4) [ 3.877777] [<c0854db0>] (dump_stack) from [<c063e9b8>] (ubi_io_write+0x540/0x6c8) [ 3.885406] [<c063e9b8>] (ubi_io_write) from [<c063ec60>] (ubi_io_write_ec_hdr+0x120/0x184) [ 3.893798] [<c063ec60>] (ubi_io_write_ec_hdr) from [<c0644298>] (ubi_early_get_peb+0xcc/0x188) [ 3.902557] [<c0644298>] (ubi_early_get_peb) from [<c0633484>] (create_vtbl+0x94/0x25c) [ 3.910614] [<c0633484>] (create_vtbl) from [<c0634044>] (ubi_read_volume_table+0x80c/0xa48) [ 3.919097] [<c0634044>] (ubi_read_volume_table) from [<c0644440>] (ubi_attach+0xec/0x154) [ 3.927398] [<c0644440>] (ubi_attach) from [<c0637858>] (ubi_attach_mtd_dev+0x1e0/0x6b0) [ 3.935546] [<c0637858>] (ubi_attach_mtd_dev) from [<c0c44730>] (ubi_init+0x15c/0x230) [ 3.943511] [<c0c44730>] (ubi_init) from [<c0102fa8>] (do_one_initcall+0x48/0x204) [ 3.951110] [<c0102fa8>] (do_one_initcall) from [<c0c01128>] (kernel_init_freeable+0x26c/0x3a4) [ 3.959869] [<c0c01128>] (kernel_init_freeable) from [<c086d5c4>] (kernel_init+0x8/0x118) [ 3.968109] [<c086d5c4>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 3.975708] Exception stack(0xec8d7fb0 to 0xec8d7ff8)
And then I want to try the same starting with linux-next.
I did:
git checkout next-20190321 git merge letux/compile-fixes git merge letux/ubi-fs make omap2plus_defconfig
Same symptoms. Which means we should not hope for a magic solution from linux-next.
So I did a cross-check:
git checkout v5.0 git cherry-pick letux-base..letux/compile-fixes # git merge would pull in v5.1-rc1 vi arch/arm/configs/omap2plus_defconfig # disable ONENAND make omap2plus_defconfig
And that fails as well! Strange.
So I did rebuild using git checkout letux-5.1-rc1 -- arch/arm/configs/letux_defconfig and now I have the display back!
This means that some CONFIG has an influence. Something which differs between omap2plus_defconfig and letux_defconfig.
What I have not yet tried is to boot on GTA04A5.
I get a working display. Not only black screen.
So we probably have a) some initilalisation race condition
Seems to be less plausible since I have exactly the same result on GTA04A4 and GTA04A5. And with v5.1-rc1 and ...
or
b) some memory corruption.
Both are nasty.
Indeed.
c) new compiler incompatibility
d) something incompatible in defconfig
I have also tried to find out what it means if git bisect reports a merge. The answers are not really unique. It depends... Especially if there are alternative histories in a tree it may happen that git bisect skips some commits or mixes up branches that were merged in. This might explain why I could not identify the offending commit and get a different result if I restrict the bisect to include/ arch/arm and drivers/
I could try to rebase v5.1-rc1 onto v5.0... This should resolve all merge commits and replace by plain commits in some sequence so that git bisect has a linear and unique history. It may work but it will more likely fail with merge conflicts. Anyways it is worth to try.
As expected it runs into merge conflicts...
Seems as if we have an "evil merge" here:
https://github.com/git/git/blob/master/Documentation/git-bisect-lk2009.txt#L...
So we need new ideas to debug this issue. git bisect does not help...
BR, Nikolaus
Hi,
On Thu, 21 Mar 2019 15:55:12 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
As expected it runs into merge conflicts...
Seems as if we have an "evil merge" here:
https://github.com/git/git/blob/master/Documentation/git-bisect-lk2009.txt#L...
So we need new ideas to debug this issue. git bisect does not help...
hmm, backlight+display works out of the box with some 4.20 dtb here. That pattern seems to be stable. I am analyzing...
rmmod pwm_bl ; modprobe pwm_bl seems not to help to solve the bl_power = 4 issue
uname -r | qrencode -s 10 -o /tmp/ver.png fbpng /tmp/ver.png
seems to be enough to display the kernel version as a qrcode. zbarcam happily recognizes it. So if we need autotests here, I am prepared...
Regards, Andreas
Am 21.03.2019 um 18:48 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Thu, 21 Mar 2019 15:55:12 +0100 "H. Nikolaus Schaller" hns@goldelico.com wrote:
As expected it runs into merge conflicts...
Seems as if we have an "evil merge" here:
https://github.com/git/git/blob/master/Documentation/git-bisect-lk2009.txt#L...
So we need new ideas to debug this issue. git bisect does not help...
hmm, backlight+display works out of the box with some 4.20 dtb here.
Does it work with 5.0 for you (kernel + dtb)? Does 5.1-rc1 uImage work with 5.0 dtb? Do the binaries differ? For me there was no diff between 5.0 dtb and 5.1-rc1.
That pattern seems to be stable. I am analyzing...
rmmod pwm_bl ; modprobe pwm_bl seems not to help to solve the bl_power = 4 issue
uname -r | qrencode -s 10 -o /tmp/ver.png fbpng /tmp/ver.png
seems to be enough to display the kernel version as a qrcode. zbarcam happily recognizes it. So if we need autotests here, I am prepared...
Cool!!!
BR, Nikolaus
Am 18.03.2019 um 21:04 schrieb H. Nikolaus Schaller hns@goldelico.com:
- BBB+LCDC: display ok, backlight is always on (but does not respond to "xset dpms")
This seems to have a threefold reason: 1. there is no DT node for connecting the backlight to the panel driver 2. the CONFIG_PWM_TIEHRPWM driver is not configured 3. after proerly configuring, pwmss_probe() or ehrpwm_pwm_probe() is never called... and the pwm_bl finally fails with EPROBE_DEFER and no /sys/class/backlight is registered.
The result is that the PWM driver does not run and therefore no backlight pwm driver.
I now wonder if it ever did work... Probably not...
BR, Nikolaus
Am 19.03.2019 um 16:18 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 18.03.2019 um 21:04 schrieb H. Nikolaus Schaller hns@goldelico.com:
- BBB+LCDC: display ok, backlight is always on (but does not respond to "xset dpms")
This seems to have a threefold reason:
- there is no DT node for connecting the backlight to the panel driver
- the CONFIG_PWM_TIEHRPWM driver is not configured
- after proerly configuring, pwmss_probe() or ehrpwm_pwm_probe() is never called...
and the pwm_bl finally fails with EPROBE_DEFER and no /sys/class/backlight is registered.
Ah, I found it. Seems to be
https://elixir.bootlin.com/linux/v5.1-rc1/source/arch/arm/boot/dts/am33xx-l4...
status = "disabled";
for the epwmss@0 parent node. Therefore it does not probe it and look for the ehrpwm1 child node (which I already have enabled in the specific DTS).
So now I can focus on experimenting with the SGX drivers and user space on this device...
BR, Nikolaus
The result is that the PWM driver does not run and therefore no backlight pwm driver.
I now wonder if it ever did work... Probably not...
BR, Nikolaus
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
-
Andreas Kemnade -
H. Nikolaus Schaller