Hi Rafał,
On 2021-01-21 16:57, zajec5 at gmail.com (Rafał Miłecki) wrote:> On
21.05.2017 22:22, Rafał Miłecki wrote:
On 14 March 2017 at 07:37, Rafał Miłecki <zajec5 at gmail.com> wrote:
My current DTS file contains following entry:
bootargs = "console=ttyS0,115200"
and it works in a following way:
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 9.320212] procd: - early -
[ 9.323174] procd: - watchdog -
[ 9.924724] procd: - ubus -
[ 9.986055] procd: - init -
Please press Enter to activate this console.
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root at LEDE:/#
If I enable "ttylogin" in /etc/config/system it works quite similarly (just
asks for a login):
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 9.362481] procd: - early -
[ 9.365550] procd: - watchdog -
[ 9.983522] procd: - ubus -
[ 10.044877] procd: - init -
Please press Enter to activate this console.
LEDE login:
LEDE login: root
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root at LEDE:~#
My problem appears when I drop bootargs and use:
stdout-path = "/chipcommonA/serial at 0300:115200";
instead (which is a non-deprecated DTS solution).
In such case I can't login anymore:
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 9.340180] procd: - early -
[ 9.343141] procd: - watchdog -
[ 9.944758] procd: - ubus -
[ 10.006092] procd: - init -
Do you know what's the reason for this? Can we have a proper console support
while using upstream preferred syntax for the stdout-path?
Please note entering failsafe mode it not affected by this.
Since noone got idea how to handle this, I added workaround as for now
in commit 0a05fbd135663 ("bcm53xx: add support for TP-LINK Archer C5
V2")
https://git.lede-project.org/?p=source.git;a=commit;h=0a05fbd1356631a1f903adcd63ffb05550537667
You can find it in the 320-ARM-dts-BCM5301X-Add-serial-to-the-bootargs.patch
I hit this problem again while working on the bcm4908 target. This time I
debugged it. It's caused by the procd's askconsole(). That function requires
console device (e.g. ttyS0) to be specified in cmdline's console.
I don't know how to fix it. Reading "stdout-path" from "chosen" will return
"serial0:115200n8". Then it's possible to read "serial0" alias which points
to some DT node (e.g. /bus at ff800000/serial at 640).
The problem I have is that my /bus at ff800000/serial at 640 doesn't reference
/dev/ttyS0 anyhow.
Last year I've also encountered that problem and reached exactly the
same conclusion.
I wanted to (and would still like to) add support for "stdout-path" to
askconsole(), but I didn't know how to handle that nicely, so I ditched
it and forgot about it.
Now you mention it, I had a look at it again briefly. Anyway, we need a
way to translate DTS node to actual device for the deprecated "label"
property of gpio-led...
https://github.com/openwrt/openwrt/pull/3437
Maybe we can make use of sysfs here, but this seems a little bit
complicated and I'm not sure if this always returns the right answer.
root@OpenWrt:/# cat /sys/firmware/devicetree/base/chosen/stdout-path; echo
serial0:115200n8
root@OpenWrt:/# cat /sys/firmware/devicetree/base/aliases/serial0; echo
/ocp@f1000000/serial@12000
root@OpenWrt:/sys/class/tty# find /sys/class/tty/*/device/of_node
/sys/class/tty/ttyS0/device/of_node
root@OpenWrt:/sys/class/tty# readlink -f /sys/class/tty/ttyS0/device/of_node
/sys/firmware/devicetree/base/ocp@f1000000/serial@12000
Or perhaps can we just use /dev/console here? It seems to be linked to
the actual serial port, but I don't know if this applies to all devices...
So this is just my guess, sorry if this does not really help you.
Thanks.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel