[Letux-kernel] [Tinkerphones] No video on Pandora after letux kernel boot

H. Nikolaus Schaller hns at goldelico.com
Thu Dec 2 19:35:38 CET 2021



> Am 02.12.2021 um 19:23 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi Grond,
> 
>> Am 01.12.2021 um 05:23 schrieb Grond <grond66 at riseup.net>:
>> 
>> On Thu, Nov 25, 2021 at 10:05:17AM +0100, H. Nikolaus Schaller wrote:
>>> Hi Grond,
>>> 
>>> 
>>>> Am 25.11.2021 um 01:16 schrieb Grond <grond66 at riseup.net>:
>> [snip]
>>>> 
>>>> Hmm. That's odd. I was able to get kernels to boot (both the ones that
>>>> came from the makesd script and my own custom-built ones), but the only
>>>> way I was able to tell that anything was running was the heartbeat LED
>>>> flashing. The LCD screen was never initialized.
>>> 
>>> Some ideas:
>>> - use letux_defconfig (omap2plus_defconfig is incomplete)
>>> - kernel may not find the modules in /lib/modules
>> 
>> I did use letux_defconfig. The issue seems to have been the pvrsrvkm
>> module.
> 
> Yes.
> 
>> 
>>> 
>>>> I've ordered a Pandora
>>>> serial adapter to try and debug the problem, but in the meantime, what
>>>> kernel did you get to boot? I built and tried letux-5.4.160
>>>> (7c7255c3463641b8f699472f9114b0435dbfe707) and whichever 5.4.160 kernel
>>>> is currently installed via makesd (probably the same git revision).
>>> 
>>> I just did build 5.4.161 (13796081373dda954bb3bb59403fc70708cbbcff).
>>> 
>>> It gets stuck for ca. 20 seconds and later reports a NULL pointer issue in
>>> the pvrsrvkm. But after a minute I get a display.
>> 
>> I also ran into a null-pointer deference issue in pvrsrvkm. However, in
>> my case it was causing the LCD not to get used (because when I
>> blacklisted pvrsrvkm, the LCD came up exactly as expected). It's also
>> worth mentioning that the LCD was actually getting initialized, however
>> the pvrsrvkm issue was somehow keeping the kernel from running a console
>> on the framebuffer (the key error message was
>> "detected unhandled fb_set_par error").
> 
> Ah, I think it is only if we compile the pvrsrvkm 1.17. It is configured by default
> for all ARM versions. Maybe the omap3530 version is broken while omap4 and
> omap5 works better.

Please try to change defconfig to 1.14.366696

> 
>> 
>>> 
>>> Maybe you can try 5.15.y? There, the pvrsrvkm issue is solved.
>> 
>> This also worked quite well. Though the fact that kernels can only be
>> booted with DTBs from their own build is definitely a trap for the
>> unwary :)
> 
> Well, there is a rule that DTBs should never be changed since they
> describe hardware... And hardware is always the same.
> 
> But in practise there are differences in how the description looks like
> or drivers may fix bugs by adding and handling new properties. So
> an old DTB doesn't fix it...
> 
>> 
>>> 
>>> But there is a known bug with the bandgap sensor inside the omap3530 (600 MHz).
>>> And something about an I2C bus timeout which hasn't been seen on dm3730 (1 GHz)
>>> based devices. 
>>> 
>> 
>> Is there any more detail on these issues anywhere?
> 
> Basically I see after a while:
> 
> ti-soc-thermal 48002524.bandgap: eocz timed out waiting high
> 
> and / or (not directly related)
> 
> [ 2061.283721] omap_i2c 48060000.i2c: timeout waiting on XUDF bit
> 
> The first one may be a Silicon bug - at least what the OMAP maintainer
> thought. He recommended to turn it off. On the other hand I know
> that it did work quite well in kernels at least before 4.0.
> 
> The second one comes from i2c3 where the bq27500 fuel gauge and the nubs
> are connected to. In fact for me the nubs stop working as soon as this
> message appears.
> 
> It may be either a protocol or a speed error. Or something in the drivers
> of these chips which make them block the bus. Or even a power management
> issue in the bandgap and i2c controllers on the omap3530 SoC.
> 
> In both cases I have planned (but not found time) to experiment with
> different older kernels to find out in which kernel release it appeared
> first. Then we may have to git bisect to understand. This is quite time-consuming...
> 
> BR,
> Nikolaus
> 
> _______________________________________________
> Community mailing list
> Community at tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org



More information about the Letux-kernel mailing list