[systemd-devel] Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)
Hi, I'm recently testing booting my RK3399 boards with the following boot sequence: U-boot -> systemd-boot (EFI payload) -> kernel Which provides much more flex than plain extlinux conf from U-boot. (More choice, easier to write config, runtime kernel change). So far "kernel" and "initramfs" key work fine. But I notice that "devicetree" key is not working properly. The Uboot fdt search path doesn't include "/dtbs" which is used by my distro, and my entry config specify the device-tree file like this: titleManjaroARM boot from nvme linux/Image devicetree/dtbs/rockchip/rk3399-rockpro64.dtb initrd/initramfs-linux.img optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7 Thus if systemd-boot doesn't load the correct device-tree, kernel will use the default fdt passed from Uboot, which is already out-of-date and can cause problems for the upstream kernel I used. Unfortunately, with above config, after booting the kernel, the fdt is the fallback one from Uboot, not loading the proper one specified by systemd-boot config. The proof I went is checking the opp table. I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom dtb which uses op1 tables. But the kernel only sees a very out-of-dated fdt, which some opp is even invalid. How could I continue debugging the missing link? Like what systemd-boot needs to load the device-tree? Or U-boot EFI environment lacks certain facility to support systemd-boot? Thanks, Qu
Re: [systemd-devel] Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)
On 2021/9/17 19:45, Lennart Poettering wrote: On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote: Hi, I'm recently testing booting my RK3399 boards with the following boot sequence: U-boot -> systemd-boot (EFI payload) -> kernel Which provides much more flex than plain extlinux conf from U-boot. (More choice, easier to write config, runtime kernel change). So far "kernel" and "initramfs" key work fine. But I notice that "devicetree" key is not working properly. The Uboot fdt search path doesn't include "/dtbs" which is used by my distro, and my entry config specify the device-tree file like this: titleManjaroARM boot from nvme linux/Image devicetree/dtbs/rockchip/rk3399-rockpro64.dtb initrd/initramfs-linux.img optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7 Thus if systemd-boot doesn't load the correct device-tree, kernel will use the default fdt passed from Uboot, which is already out-of-date and can cause problems for the upstream kernel I used. Unfortunately, with above config, after booting the kernel, the fdt is the fallback one from Uboot, not loading the proper one specified by systemd-boot config. The proof I went is checking the opp table. I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom dtb which uses op1 tables. But the kernel only sees a very out-of-dated fdt, which some opp is even invalid. How could I continue debugging the missing link? Like what systemd-boot needs to load the device-tree? Or U-boot EFI environment lacks certain facility to support systemd-boot? Did you see this: https://github.com/systemd/systemd/pull/19417 Confirmed this pull fixes the problem. I only need to wait for next release to get it from my distro. Awesome! Thanks, Qu (and maybe this: https://github.com/systemd/systemd/pull/20601) maybe that addresses your issues? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Systemd-boot not properly loading device tree, when loaded by U-boot (ARM64, tested on RK3399)
On 2021/9/17 19:45, Lennart Poettering wrote: On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote: Hi, I'm recently testing booting my RK3399 boards with the following boot sequence: U-boot -> systemd-boot (EFI payload) -> kernel Which provides much more flex than plain extlinux conf from U-boot. (More choice, easier to write config, runtime kernel change). So far "kernel" and "initramfs" key work fine. But I notice that "devicetree" key is not working properly. The Uboot fdt search path doesn't include "/dtbs" which is used by my distro, and my entry config specify the device-tree file like this: titleManjaroARM boot from nvme linux/Image devicetree/dtbs/rockchip/rk3399-rockpro64.dtb initrd/initramfs-linux.img optionsconsole=ttyS2,150 root=/dev/arm_nvme/root rw loglevel=7 Thus if systemd-boot doesn't load the correct device-tree, kernel will use the default fdt passed from Uboot, which is already out-of-date and can cause problems for the upstream kernel I used. Unfortunately, with above config, after booting the kernel, the fdt is the fallback one from Uboot, not loading the proper one specified by systemd-boot config. The proof I went is checking the opp table. I have replaced the "/dtbs/rockchip/rk3399-rockpro64.dtb" with a custom dtb which uses op1 tables. But the kernel only sees a very out-of-dated fdt, which some opp is even invalid. How could I continue debugging the missing link? Like what systemd-boot needs to load the device-tree? Or U-boot EFI environment lacks certain facility to support systemd-boot? Did you see this: https://github.com/systemd/systemd/pull/19417 (and maybe this: https://github.com/systemd/systemd/pull/20601) Awesome! Let me try these PRs and report back! Thanks for the super-fast mention! Qu maybe that addresses your issues? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] mate desktop user service file
在 12/04/2014 04:56 PM, arnaud gaboury 写道: mate-settings-daemon might expect to be run from within an X-session. These errors look like DISPLAY= isn't set, which is reasonable because systemd starts programs from a clean environment. As mentioned in my post, $DISPLAY is correctly set and is in systemctl environment. The command is run inside the X session After more tests, I realized two variables were missing: -$XAUTHORITY In an effort to group runtime variables in one place, I set XAUTHORITY=/run/user/1000/Xauthority. So adding Environment=XAUTHORITY=/run/user/1000/Xauthority solved this issue. -$DBUS_SESSION_BUS_ADDRESS For reasons I ignore (far from being a dbus expert), the $DBUS_SESSION_BUS_ADDRESS as returned by the $systemctl --user show-environment did not work for mate-settings-daemon. Instead, mate is looking for this file to connect to dbus : ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 (machine.id-display). This file has the following content: DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736 DBUS_SESSION_BUS_PID=8268 DBUS_SESSION_BUS_WINDOWID=16777217 So adding EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 solved the issue. I am now with this service file: ~/.config/systemd/user/mate-settings-daemon.service - [Unit] Description=Mate settings daemon [Service] Type=daemon Environment=XAUTHORITY=/run/user/1000/Xauthority EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 ExecStart=/usr/lib/mate-settings-daemon/mate-settings-daemon [Install] WantedBy=wm.target it works and does what I am expecting (mate-settings are started without any mate session being started). - gabx@hortensia ➤➤ ~ % systemctl --user status mate-settings-daemon ● mate-settings-daemon.service - Mate settings daemon Loaded: loaded (/home/gabx/.config/systemd/user/mate-settings-daemon.service; disabled) Active: active (running) since Thu 2014-12-04 09:34:39 CET; 9min ago Main PID: 5664 (mate-settings-d) CGroup: /user.slice/user-1000.slice/user@1000.service/mate-settings-daemon.service └─5664 /usr/lib/mate-settings-daemon/mate-settings-daemon Just to mention, the default 1.8.1 mate, will autostart mate-setting-daemon according to its file in /etc/xdg/autostart/mate-settings-daemon.desktop: -- [Desktop Entry] Type=Application Name=MATE Settings Daemon Exec=/usr/lib/mate-settings-daemon/mate-settings-daemon OnlyShowIn=MATE; X-MATE-Autostart-Phase=Initialization X-MATE-Autostart-Notify=true X-MATE-AutoRestart=true -- So the problem does not involve systemd at all... Thanks, Qu Anyway, you really should talk to the mate developers to ask them It is done, but still waiting for any hint... Now my new questions: It seems to me my setting is a dirty hack. I can't understand the content of ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0. - $ myps dbus . 154:gabx 1424 1 0 Nov29 ?00:00:00 dbus-launch --autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax --close-stderr . --- Why this autolaunch ? Why is the DBUS_SESSION_BUS_ADDRESS in this file set to /tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736 when $systemctl --user show-environment returns DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket ? I am left with two adresses, which sounds to me confusing and weird. Why is mate-settings-daemon listening to the adress in ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 and not to the one provided by systemctl ? Even if my setup works, I would like to understand this story of two dbus seesion adresses. Thank you for any explanation to light my lantern. Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
