> Am 02.12.2021 um 19:23 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
>
> Hi Grond,
>
>> Am 01.12.2021 um 05:23 schrieb Grond <gron...@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 <gron...@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@tinkerphones.org
> http://lists.goldelico.com/mailman/listinfo.cgi/community
> http://www.tinkerphones.org
_______________________________________________
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org
