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. > >> >> 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
