[Letux-kernel] 4.14-rc* on Pyra/OMAP5EVM

[H. Nikolaus Schaller]

> Am 10.10.2017 um 21:43 schrieb Tony Lindgren <tony at atomide.com>:
> 
> Hi,
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [171010 12:29]:
>> 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/?id=d2b310b0234c20a656e2b9047b6f2a318ad39c35
>> 	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc23beb8a57723eecd04cd732e0722df72feaf70
>> 
>> 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)
> 
> Hmm OK that explains, sorry to hear about wasting time on this :(
> 
> The 8250 based DEBUG_LL uart will maintain the .config values for UART address
> etc. So just disable CONFIG_DEBUG_LL in all your configs and use the earlycon
> instead. DEBUG_LL is not portable across machines and should be only selected
> if nothing else helps.
> 
> $ grep "config DEBUG_UART_" arch/arm/Kconfig.debug
> config DEBUG_UART_PL01X
> config DEBUG_UART_8250
=y
> config DEBUG_UART_PHYS
=0x49020000
> config DEBUG_UART_VIRT
=0xfb020000
> config DEBUG_UART_8250_SHIFT
=2
> config DEBUG_UART_8250_WORD
> config DEBUG_UART_8250_PALMCHIP
> config DEBUG_UART_8250_FLOW_CONTROL

The others were not set. I don't remember when and why they were set...

> You probably enabled these for GTA04, and those addresses will hang early
> on anything else.

Yes, that is well possible. And explains why OMAP3 did still work...

Anyways I think DEBUG_LL should be disabled or at least warned when
compiling for OMAP5.

Still the best thing is that I have it working again on Pyra. So I can
continue with some more hardware tests. We plan to replace the tca6424
(same as on EVM) with a pcal6524. It is already tested that the pcal
can be operated as compatible="ti,tca6424" but the pcal has some better
interrupt management which should be enabled in the driver and the
DTS for the pyra should be updated as well. Now I can start to test
such things (not with starting to maintain an older kernel...).

BR,
Nikolaus