Am 10.10.2017 um 21:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
- H. Nikolaus Schaller hns@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/?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)
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