Hi Tony,

Am 09.10.2017 um 17:35 schrieb H. Nikolaus Schaller hns@goldelico.com:

Hi Tony, I just recognized that I forgot to CC to the mailing lists...

For the readers: Letux-4.14-rc* boots well on GTA04 but doesn't on Pyra or OMAP5EVM. I just get Starting Kernel... Going back to Letux-4.13.* it boots on all machines.

Another problem which also might need bisection is that the Panel on the Pandora shows only the blue RGB channel in Letux-4.14-rc* while it works in Letux-4.13.*.

So there are just ca. 13 bisect build & boot steps until I know more.

Well, I had to learn first that if I cherry-pick some patches on top of what git bisect good/bad proposes next, I have to remove them first before I do the next git bisect good/bad or git bisect tries to find out something about the cherry-picked patches...

Now after several days of work I have a result:

There are only 'skip'ped commits left to test. The first bad commit could be any of: d2b310b0234c20a656e2b9047b6f2a318ad39c35 fc23beb8a57723eecd04cd732e0722df72feaf70

Let's look into them:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...

Both have indeed something to do with OMAP3/4/5 UARTs.

So this explains why there is no console message after they are applied, i.e. between v4.1 and v4.14-rc1.

But it does not explain: * why it works on GTA04 (OMAP3) * why the kernel doesn't start at all (no LEDs blinking) on omap5432uevm (or Pyra)

To document what kernel I have been running on the omap5432evm:

1) any bisect of kernel.org between v4.13 (good) and v4.14-rc1 (bad) 2) cherry pick 90c4ae4e2c1da9f1eaf846136861af43d4c1ff34 to fix a potential compile issue (may fail if already applied by bisect - or not needed if you have a better cross compiler) 3) cherry pick two patches from Letux for helping my local HOSTCC to compile sortextable and some selinux stuff: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/le... They should not be necessary on different build hosts. 4) checkout http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/configs/letux... to get the letux defconfig which works for "good" on my setup (omap2plus_defconfig fails with my u-boot for all recent kernels) 5) make letux_defconfig

So with this information you should be able to confirm this problem on the omap5432evm.

Any ideas why it does break the EVM (and Pyra) that hard (no LEDs blinking)?

The commit description just talks about "there's no need to keep DEBUG_LL enabled", but not that it harms to have it enabled.

Note that letux_defconfig has CONFIG_DEBUG_LL=y by default for a long time and nobody did disable it so far.

I have finally tried with CONFIG_DEBUG_LL disabled and...

... I can boot letux-4.13-rc3

On both OMAP5432EVM and Pyra :)

So these offending patches should also enforce to disable CONFIG_DEBUG_LL on OMAP3/4/5 (all of them?). E.g. CONFIG_DEBUG_LL sould depend on !OMAP3 && !OMAP4 && !OMAP5 or so. Or the patches should explicitly depend on !CONFIG_DEBUG_LL. Or at least emit a #warning if CONFIG_DEBUG_LL is enabled.

Phew... That was quite challenging and time consuming to find out.

Anyways it was not a complete much waste of time, because I know two more bugs that need the same bisect approach: * Pandora display having blue channel only after going v4.13..v4.14-rc1 * Pandora WLAN stopped working between 4.6..4.7 - and even worse between v4.13..v4.14-rc1

BR, Nikolaus