Re: Nonterministic hang during bootconsole/console handover on ath79

[Gabor Juhos]

2016.03.24. 4:17 keltezÃssel, Peter Hurley Ãrta:
> On 03/23/2016 07:09 PM, Matthias Schiffer wrote:
>>>> autoconfig_16550a() is doing all kinds of weird checks to detect different
>>>> hardware by writing a lot of register values which are documented as
>>>> reserved in the AR7242 datasheet (there's a leaked version going around
>>>> that can be easily googled...), no idea if any of those are problematic.
>>>> Just setting UPF_FIXED_TYPE as suggested by Peter would avoid that code
>>>> altogether.
>>>
>>> That's just a debugging patch and not appropriate for permanent use,
>>> the reason being that this uart is _not_ 16550 compatible (or even 16450
>>> compatible).
>>>
>>> The three options for 8250 driver support for this part are:
>>> 1. Similar to the debugging patch, set UPF_FIXED_TYPE but set port type
>>>    to PORT_8250 instead. This will lose FIFO support so 115K won't be
>>>    possible and likely neither will 38400.
>>>
>>> 2. Set UPF_FIXED_TYPE but define a new PORT_* value and add support for
>>>    this PORT_* value to uart_config array, uapi headers, and anywhere
>>>    the scratch register is used.
>>>
>>> 3. As with 2. above but don't set UPF_FIXED_TYPE and add a probe function
>>>    that detects ports of this type to autoconfig(). I don't recommend this
>>>    method.
>>>
>>> This requirement is independent of fixing prom_putchar_ar71xx().
>>>
>>
>> I can send patches for all of this, and I think that 2. would be the nicest
>> solution. I've noticed though that include/uapi/linux/serial_core.h is
>> experiencing a little "overflow": PORT_MAX_8250 has grown just below the
>> first non-8250 entry.
> 
> Ugh. Thanks for noting this.
> 
>> Should I just add the new entry at the bottom (and
>> thus grow the uart_config array by ~85 unused entries)? What about
>> PORT_MAX_8250 (used at least in drivers/tty/serial/8250/8250_of.c)?
> 
> None of the above, unfortunately. Ok, plan B.
> 
> I need to clean off a dusty series that adds probe steering and
> bugs pass-thru for 8250 sub-drivers and platform data. Then add a
> UART_BUG_NOSCR to indicate a uart does not have a scratch register
> (like this one). Then for this uart, set UPF_FIXED_TYPE and type to
> PORT_16550A, with UART_BUG_NOSCR flag.

Introducing the UART_BUG_NOSCR flag for this UART is pointless in my opinion,
because it does have a scratch register in fact. Even if it is not listed in the
datasheet of the SoCs, it exists.

I have tested that from the bootloader on the Netgear WNDR3700 board which uses
the AR7161 SoC:

ar7100> md.l 0xb802001c 1
b802001c: 00000000    ....
ar7100> mw.l 0xb802001c a5
ar7100> md.l 0xb802001c 1
b802001c: 000000a5    ....
ar7100> mw.l 0xb802001c 5a
ar7100> md.l 0xb802001c 1
b802001c: 0000005a    ...Z
ar7100>

The same test is on the TL-WR842ND v1 board (AR7241 SoC):

ar7240> md.l b802001c 1
b802001c: 00000000    ....
ar7240> mw.l b802001c a5
ar7240> md.l b802001c 1
b802001c: 000000a5    ....
ar7240> mw.l b802001c 5a
ar7240> md.l b802001c 1
b802001c: 0000005a    ...Z
ar7240>

And on the TL-WR841N v8 board (AR9341 Soc):

wasp> md.l b802001c 1
b802001c: 00000000    ....
wasp> mw.l b802001c a5
wasp> md.l b802001c 1
b802001c: 000000a5    ....
wasp> mw.l b802001c 5a
wasp> md.l b802001c 1
b802001c: 0000005a    ...Z
wasp>

Although i did not test it on other SoCs, but i assume that the behaviour is the
same on those.

-Gabor