[OpenWrt-Devel] mt7620a serial port driver ordering of nodes uart/uartlite vs ttyS0/ttyS1 patch

[John Crispin]

apparently our problem is not new and the existing solution is the
"linux,stdout-path" syntax

so  stdout-path = &uartf; should work (... maybe)

jonas just pointed this out to me



On 30/08/2014 11:37, Luis Soltero wrote:
> hm... it still seems that the board integrator should be able to determine the node name for the device.  Implementing a
> scheme based on base address still hard wires the node name to the port and does not provide the flexibility of changing
> it.    Absolutely depending on the load order is quirky... however knowing that gives you some flexibility in the naming.
>
> I think the real answer is to add a property that allows you to specify the order.  Then you can order the devices
> however you like.
>
> i worry that implementing something on the base address is actually worse than what we currently have.
>
> look forward to your thoughts.
>
> --luis
>
> On 8/30/14, 2:35 AM, John Crispin wrote:
>> Hi
>>
>> On Lantiq we derive the port numbering from the base addr that gets
>> used for early printk. i will implement a similar solution for ralink.
>> having to rely on the load order seems quirky.
>>
>> 	John
>>
>> On 29/08/2014 23:56, Luis Soltero wrote:
>>> Hello All,
>>>
>>> Most mt7620a routers defined in the target/linux/ramips/dts have
>>> exactly one serial port defined which is used for the console.  The
>>> serial port driver links this to node /dev/ttyS0.
>>>
>>> However.  one (and now 2) devices use the mt7620a serial port lines
>>> for use as a second real serial port (uart at 500 in the dts).
>>> Currently when when more than one serial port is defined  the boot
>>> sequence starts with the console attached to uartlite but as soon
>>> as the serial port driver driver is loaded it deactivates the
>>> console and assigns it to /dev/ttyS1 (which is the node created for
>>> uartlite).  So on these systems using the standard dts
>>> configuration the mt7620a enhanced uart is bound to /dev/ttyS0 and
>>> uartlite is bound /dev/ttyS1.
>>>
>>> This causes the console serial port to stop displaying output
>>> unless the following is added to the dts definition
>>>
>>> chosen { bootargs = "console=ttyS1,57600"; };
>>>
>>> which redefines the console to /dev/ttyS1... this configuration
>>> works fine.   However some (including me) find this very 
>>> irritating.  These few routers defining a second serial port differ
>>> from all the others in their definition of /dev/ttyS0 as the
>>> console.
>>>
>>> So... for consistency it seems that it would be much better for **
>>> ALL ** routers regardless of the number of serial ports define
>>> /dev/ttyS0 as the console port.
>>>
>>> The reason for the renumbering is due to the serial port driver to
>>> assign nodes on a first come first basis in the dts definition.
>>> Since in mt7620a.dtsi (included by most/all 7620a router board
>>> definitions) the definition for uart at 500 is before that for
>>> uartlite at 00.  So  uart gets assigned /dev/ttyS0 while uartlite gets
>>> /dev/ttyS1.  You can't fault the serial driver for doing it.  After
>>> all it really doesn't know for what purpose the serial port is to
>>> be used.
>>>
>>> A logical extension to the serial port dts properties would be to
>>> add a "node-name" or "node-order" or "node-number" property that
>>> would allow the integrator to specify the node number or the node
>>> name for the serial port. However these properties don't exist (or
>>> at least they were not obvious in either the source code or the
>>> documentation).  So... a simple "fix" for the ordering is to
>>> reorder the definitions in mt7620a.dtsi.
>>>
>>> This reordering affects exactly one mt7620a router in the dts
>>> definitions as of r42293 (NA930.dts).
>>>
>>> Attached you will find a patch which modifies both mt7620a.dtsi and
>>> NA930.dts assigning the console to /dev/ttyS0 for devices with more
>>> than one serial port.
>>>
>>> Note that a similar issue applies to the RT5350.  Although we are
>>> currently not working with that architecture I am happy to supply a
>>> patch if the community would like one.
>>>
>>> here is a snippet from the boot log of our mt7620a board showing a
>>> console happily bound to /dev/ttyS0 and the second serial port
>>> bound to /dev/ttyS1
>>>
>>> [    0.350000] Serial: 8250/16550 driver, 2 ports, IRQ sharing
>>> disabled [    0.370000] 10000c00.uartlite: ttyS0 at MMIO 0x10000c00
>>> (irq = 20) is a 16550A [    0.380000] console [ttyS0] enabled,
>>> bootconsole disabled [    0.380000] console [ttyS0] enabled,
>>> bootconsole disabled [    0.410000] 10000500.uart: ttyS1 at MMIO
>>> 0x10000500 (irq = 13) is a 16550A
>>>
>>>
>>> --luis
>>>
>>>
>>>
>>>
>>> _______________________________________________ openwrt-devel
>>> mailing list openwrt-devel at lists.openwrt.org 
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel