[Letux-kernel] [Tinkerphones] No video on Pandora after letux kernel boot
H. Nikolaus Schaller
hns at goldelico.com
Thu Dec 2 19:23:50 CET 2021
> 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>:
>>> 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
>>> 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.
>> 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
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...
More information about the Letux-kernel