<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
If i am understanding correctly this something added to chosen to
bind the console to a specific uart... as in <br>
<br>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<title>The Device Tree: Plug and play for Embedded Linux</title>
/dts-v1/; /{<br>
#address-cells = <1>; #size-cells = <1>;<br>
compatible = "xlnx,zynq-zed"; interrupt-parent = <&gic>;<br>
model = "Xillinux for Zedboard"; <br>
aliases {<br>
serial0 = &ps7_uart_1; <br>
};<br>
chosen {<br>
bootargs = "consoleblank=0 root=/dev/mmcblk0p2 rw rootwait
earlyprintk"; <br>
linux,stdout-path = "/axi@0/uart@E0001000";<br>
}; <br>
<br>
but does not solve the problem of binding a specific uart to a node
name. i.e. uartline ==> /dev/ttyS0 and uart ==> /dev/ttyS1<br>
<br>
interestingly the aliases {} in this example catches my attention.
maybe the ordering is handled by aliases{}?<br>
<br>
hm... maybe some experimentation is in order here. <br>
<br>
--luis<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/30/14, 6:07 AM, John Crispin
wrote:<br>
</div>
<blockquote cite="mid:5401A26A.4050705@openwrt.org" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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@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@500 is before that for
uartlite@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 <a class="moz-txt-link-abbreviated" href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
openwrt-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
openwrt-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="120">--
Luis Soltero, Ph.D., MCS
Director of Software Development, CTO
Global Marine Networks, LLC
StarPilot, LLC
Tel: +1.865.379.8723
Fax: +1.865.681.5017
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:lsoltero@globalmarinenet.net">lsoltero@globalmarinenet.net</a>
Web: <a class="moz-txt-link-freetext" href="http://www.globalmarinenet.net">http://www.globalmarinenet.net</a>
Web: <a class="moz-txt-link-freetext" href="http://www.redportglobal.com">http://www.redportglobal.com</a>
Web: <a class="moz-txt-link-freetext" href="http://www.starpilotllc.com">http://www.starpilotllc.com</a>
</pre>
</body>
</html>