<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div style="margin: 0;">I find that boot <span style="font-family: arial; white-space: pre-wrap;">with the 'rescue' option, then exit '</span><span style="font-family: arial; white-space: pre-wrap;">rescue</span><span style="font-family: arial; white-space: pre-wrap;">' mode, then I can login to the ttyPS0, as below</span></div><div style="margin: 0;"><br></div><div style="margin: 0;"><div style="margin: 0;">bash-4.4# exit // *here exit rescue mode*</div><div style="margin: 0;">exit</div><div style="margin: 0;">Reloading system manager configuration</div><div style="margin: 0;">Starting default target</div><div style="margin: 0;">[ 1708.910000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready</div><div style="margin: 0;">[ 1712.080000] macb e000b000.ethernet eth0: link up (100/Full)</div><div style="margin: 0;">[ 1712.080000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready</div><div style="margin: 0;">...</div><div style="margin: 0;">Build date: 2019-08-22 21:56</div><div style="margin: 0;"><br></div><div style="margin: 0;">Kernel 4.18.0-14480-gc4490f2dabc1 on an riscv64 (ttyPS0)</div><div style="margin: 0;">...</div><div style="margin: 0;">stage4 login: root</div><div style="margin: 0;">Password: </div><div style="margin: 0;">[root@stage4 ~]#</div></div><p style="margin: 0;"><br></p><div style="margin: 0;">But how boot directly normally.</div><div style="margin: 0;">Thanks all,</div><pre>At 2020-09-23 16:37:48, "ZhouPeng" <zhoupengwork01@163.com> wrote:
>Thank you very much. ' udevadm info -a /dev/ttyPS0' output:
>
>
>bash-4.4# udevadm info -a /dev/ttyPS0
>
>Udevadm info starts with the device specified by the devpath and then
>walks up the chain of parent devices. It prints for every device
>found, all possible attributes in the udev rules key format.
>A rule to match, can be composed by the attributes of the device
>and the attributes from one single parent device.
>
> looking at device '/devices/platform/soc/e0000000.serial/tty/ttyPS0':
> KERNEL=="ttyPS0"
> SUBSYSTEM=="tty"
> DRIVER==""
> ATTR{close_delay}=="50"
> ATTR{closing_wait}=="3000"
> ATTR{custom_divisor}=="0"
> ATTR{flags}=="0x10000000"
> ATTR{io_type}=="3"
> ATTR{iomem_base}=="0xE0000000"
> ATTR{iomem_reg_shift}=="0"
> ATTR{irq}=="2"
> ATTR{line}=="0"
> ATTR{port}=="0x0"
> ATTR{type}=="98"
> ATTR{uartclk}=="100000000"
> ATTR{xmit_fifo_size}=="64"
>
> looking at parent device '/devices/platform/soc/e0000000.serial':
> KERNELS=="e0000000.serial"
> SUBSYSTEMS=="platform"
> DRIVERS=="xuartps"
> ATTRS{driver_override}=="(null)"
>
> looking at parent device '/devices/platform/soc':
> KERNELS=="soc"
> SUBSYSTEMS=="platform"
> DRIVERS==""
> ATTRS{driver_override}=="(null)"
>
> looking at parent device '/devices/platform':
> KERNELS=="platform"
> SUBSYSTEMS==""
> DRIVERS==""
>bash-4.4# ls /dev/ttyPS0 -lh
>crw-rw---- 1 root dialout 254, 0 Jan 28 16:05 /dev/ttyPS0
>
>
>Thanks,
>
>On Wed, Sep 23, 2020, 15:34，"Mantas Mikulėnas" <grawity@gmail.com> wrote:
>
>
>On Wed, Sep 23, 2020, 09:21 ZhouPeng <zhoupengwork01@163.com> wrote:
>
>
>
>Thank you very much for you great suggestions.
>
>
>
>I chroot the rootfs and tried to the 3 methods in '/usr/lib/udev/rules.d' respectively:
>
>
>
>try 1) add a line of ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd" below the line of "ACTION=="remove", GOTO="systemd_end"" in file 99-systemd.rules
>
>try 2) add a line of ACTION!="remove", KERNEL=="ttyPS0", NAME="ttyPS0", TAG+="systemd" below the line of "ACTION=="remove", GOTO="systemd_end"" in file 99-systemd.rules
>
>try 3) replace the line "SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd" with "SUBSYSTEM=="tty", KERNEL=="ttyPS[0-9]|tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"", in file 99-systemd.rules.
>
>
>
>At least the 1st one *should* have worked, though NAME= seems wrong in the 2nd one...
>
>
>
>
>
>
>
>At the same time, I replace the line of "KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"" with "KERNEL=="ttyPS[0-9]|tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"".
>
>
>
>This line is irrelevant, since TAG+="systemd" is the important part – groups and modes shouldn't be the problem.
>
>
>
>
>
>
>
>
>
>But they didn't take any effect.
>
>
>
>Then at the same time, I do
>
>cp /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty@ttyPS0.service
>
>Edit /etc/systemd/system/serial-getty\@ttyPS0.service: replace "ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM" with "ExecStart=-/sbin/agetty --keep-baud 115200 %I $TERM"
>
>ln -s /etc/systemd/system/serial-getty@ttyPS0.service /etc/systemd/system/getty.target.wants/
>
>
>
>But there was still no effect. There is still boot failure logs like:
>
>[ *] (3 of 3) a start job is running for dev-ttyPS0.device (41s / 1min 30s)// **here**
>
>...
>
> [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
>
>...
>
>
>
>Yeah, the baudrate won't change anything if systemd doesn't even see the device in the first place. It doesn't even get to the point of launching agetty.
>
>
>
>
>
>
>
>By the way, Do I need to add some configuration to tiger executing something like 'mknod /dev/ttyPS0 c 248 0' for systemd or udev pls? If needed, where is the proper place to add this action pls?
>
>
>
>No. The kernel automatically creates device nodes (as long as /dev has a "devtmpfs" mounted); udev only applies modes/symlinks. The problem here is that udev doesn't properly inform systemd about the new device.
>
>
>
>
>
>
>
>>What does "udevadm info -a /dev/ttyPS0" output?
>
>I can not get a console from ttyPS0, so I can not run "udevadm info -a /dev/ttyPS0" in the target(xilinx pynq) board.
>
>
>
>Try booting with the 'rescue' option, this should directly create a root login prompt on the kernel console.
>
>
>
>
>
>Alternatively, try creating a simple .service that runs this command, then you'll find its output in the journal or in the boot console (depending on what StandardOutput= you set).
>
>
>
>
>
>
>
>
>
>Thanks all,
>
>At 2020-09-22 20:34:15, "Andrei Borzenkov" <arvidjaar@gmail.com> wrote:
>
>>On Tue, Sep 22, 2020 at 2:53 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>
>>>
>
>>> On Tue, Sep 22, 2020 at 1:46 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>
>>>>
>
>>>> On Tue, Sep 22, 2020 at 1:35 PM ZhouPeng <zhoupengwork01@163.com> wrote:
>
>>>> >
>
>>>> > Hi all,
>
>>>> >
>
>>>> > When I use Fedora image as rootfs on Xilinx PYNQ-Z2, I encountered the issue when use the /dev/ttyPS0.
>
>>>> > I think the issue is because systemd and udev on fedora can didn't detect ttyPS0 properly. Do I need to install any other package or do some special configuration?
>
>>>> >
>
>>>> > **systemd version the issue has been seen with**
>
>>>> > udevadm --version
>
>>>> > 237
>
>>>> > systemd-udev.riscv64 237-1.0.riscv64.fc28
>
>>>> >
>
>>>> >
>
>>>> > **Unexpected behaviour you saw**
>
>>>> > We can see ttyPS0 boots ok in the kernel boot period:
>
>>>> > [ 0.180000] console [ttyPS0] enabledat MMIO 0xe0000000 (irq = 2, base_baud = 6250000) is a xuartps
>
>>>> > [ 0.180000] console [ttyPS0] enabled
>
>>>> >
>
>>>> > But, when boot into systemd, it failed on dev ttyPS0:
>
>>>> > [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
>
>>>>
>
>>>> systemd only monitors for devices with "sysemd" tag. Tags are assigned
>
>>>> by udev rules. You should add rule to assign tag to ttyPS0. I have no
>
>>>> idea what it is, but something like
>
>>>>
>
>>>> ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd"Mantas
>
>>>>
>
>>>> should do it. Whether this should go upstream depends on how common
>
>>>> this device is.
>
>>>
>
>>>
>
>>> Well yes, but that should have been already covered by the existing upstream rules:
>
>>>
>
>>> 99-systemd.rules:12:SUBSYSTEM=="tty", KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", TAG+="systemd"
>
>>>
>
>>
>
>>Are you sure ttyPS0 has the "tty" subsystem?
>
>
</pre></div>