This service is available only in Japanese-language.

westonが起動されない問題について

作成者:仙波儀一郎 作成日:2020/6/11 (木) 21:26

下記のNXP製 i.MX8Mmini EVK用のYoctoイメージを使って、弊社で開発した基板上で起動させました。
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-1.0.0.xml
$ repo sync

$ DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b Build-xwayland-imx8mmevk

このとき、weston起動時に下記のようなメモリダンプが表示され、weston画面が表示されません。
下記のログでは、psコマンドを実行するとwestonは起動されています。
また、再起動するたびに、ログインする前に下記のログが出力されて、westonが強制終了される場合もあります。

NXP i.MX Release Distro 5.4-zeus imx8mmevk ttymxc1

imx8mmevk login: root
Last login: Wed Jun 10 09:12:17 UTC 2020 on tty7
root@imx8mmevk:~#
root@imx8mmevk:~#
[ 67.433954] Unable to handle kernel paging request at virtual address 000000020000007f
[ 67.441912] Mem abort info:
[ 67.444752] ESR = 0x96000005
[ 67.447845] Exception class = DABT (current EL), IL = 32 bits
[ 67.453802] SET = 0, FnV = 0
[ 67.456877] EA = 0, S1PTW = 0
[ 67.460039] Data abort info:
[ 67.462919] ISV = 0, ISS = 0x00000005
[ 67.466792] CM = 0, WnR = 0
[ 67.469780] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[ 67.476409] [000000020000007f] pgd=00000000651f1003, pud=0000000000000000
[ 67.483222] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 67.488792] Modules linked in:
[ 67.491847] Process weston (pid: 3284, stack limit = 0x(____ptrval____))
[ 67.498549] CPU: 0 PID: 3284 Comm: weston Not tainted 4.19.35-APS1G #58
[ 67.505160] Hardware name: Algosystem i.MX8MM APS1G board (DT)
[ 67.510991] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 67.515787] pc : gckKERNEL_FindDatabase+0x30/0x128
[ 67.520578] lr : gckKERNEL_FindHandleDatbase+0x34/0x78
[ 67.525712] sp : ffff000017993960
[ 67.529024] x29: ffff000017993960 x28: ffff800029f1cf80
[ 67.534335] x27: 0000000000000000 x26: 0000000000000000
[ 67.539646] x25: 0000000056000000 x24: 0000000000000010
[ 67.544957] x23: ffff0000179939d0 x22: 0000000000000cd4
[ 67.550268] x21: ffff000017993a28 x20: ffff7e0000c98d00
[ 67.555579] x19: 0000000000000000 x18: 0000000000000000
[ 67.560890] x17: 0000000000000000 x16: 0000000000000004
[ 67.566201] x15: 0000000000000000 x14: 0000ffffc414d978
[ 67.571512] x13: 000000000000002b x12: 000000000000002a
[ 67.576822] x11: 000000000000002a x10: 0000ffffb047fb10
[ 67.582133] x9 : 0000ffffc414d7a0 x8 : 0000000006d12470
[ 67.587444] x7 : 0000000006ce9f70 x6 : ffff000017993d98
[ 67.592755] x5 : ffff000017993d98 x4 : 0000000000000008
[ 67.598066] x3 : ffff0000179939d0 x2 : 00000000ffffffff
[ 67.603377] x1 : 00000001ffffffff x0 : ffff7e0000c98cc8
[ 67.608688] Call trace:
[ 67.611134] gckKERNEL_FindDatabase+0x30/0x128
[ 67.615577] gckKERNEL_FindHandleDatbase+0x34/0x78
[ 67.620366] gckVIDMEM_HANDLE_Lookup+0x48/0xd0
[ 67.624808] _ReleaseVideoMemory+0x38/0xb0
[ 67.628903] gckKERNEL_Dispatch+0x2d8/0x1560
[ 67.633171] gckDEVICE_Dispatch+0x68/0x170
[ 67.637265] drv_ioctl+0x124/0x218
[ 67.640667] do_vfs_ioctl+0xb8/0x890
[ 67.644240] ksys_ioctl+0x78/0xa8
[ 67.647553] __arm64_sys_ioctl+0x1c/0x28
[ 67.651476] el0_svc_common+0x84/0xf0
[ 67.655137] el0_svc_handler+0x2c/0x80
[ 67.658885] el0_svc+0x8/0xc
[ 67.661766] Code: f9001bf7 aa0303f7 f9403801 f9400400 (f9404021)
[ 67.667858] ---[ end trace d4be5a32ac3441dc ]---

Message from syslogd@imx8mmevk at Wed Jun 10 09:13:19 2020 ...
imx8mmevk kernel: [ 67.483222] Internal error: Oops: 96000005 [#1] PREEMPT SMP

Message from syslogd@imx8mmevk at Wed Jun 10 09:13:19 2020 ...
imx8mmevk kernel: [ 67.491847] Process weston (pid: 3284, stack limit = 0x(____ptrval____))

Message from syslogd@imx8mmevk at Wed Jun 10 09:13:19 2020 ...
imx8mmevk kernel: [ 67.661766] Code: f9001bf7 aa0303f7 f9403801 f9400400 (f9404021)
ther
spawn telnet rainmaker.wunderground.com 3000

telnet: bad address 'rainmaker.wunderground.com'
failed to telnet to weather server
root@imx8mmevk:~#
root@imx8mmevk:~#
[ 162.236404] random: crng init done
[ 162.239820] random: 7 urandom warning(s) missed due to ratelimiting
root@imx8mmevk:~#
root@imx8mmevk:~# ps -A
PID TTY TIME CMD
1 ? 00:00:02 systemd
2 ? 00:00:00 kthreadd
3 ? 00:00:00 rcu_gp
4 ? 00:00:00 rcu_par_gp
5 ? 00:00:00 kworker/0:0-cgroup_destroy
6 ? 00:00:00 kworker/0:0H-kblockd
7 ? 00:00:00 kworker/u8:0-events_unbound
8 ? 00:00:00 mm_percpu_wq
9 ? 00:00:00 ksoftirqd/0
10 ? 00:00:00 rcu_preempt
11 ? 00:00:00 rcu_sched
12 ? 00:00:00 rcu_bh
13 ? 00:00:00 migration/0
14 ? 00:00:00 cpuhp/0
15 ? 00:00:00 cpuhp/1
16 ? 00:00:00 migration/1
17 ? 00:00:00 ksoftirqd/1
18 ? 00:00:00 kworker/1:0-events_freezable
19 ? 00:00:00 kworker/1:0H-kblockd
20 ? 00:00:00 cpuhp/2
21 ? 00:00:00 migration/2
22 ? 00:00:00 ksoftirqd/2
23 ? 00:00:00 kworker/2:0-rcu_gp
24 ? 00:00:00 kworker/2:0H-kblockd
25 ? 00:00:00 cpuhp/3
26 ? 00:00:00 migration/3
27 ? 00:00:00 ksoftirqd/3
28 ? 00:00:00 kworker/3:0-events
29 ? 00:00:00 kworker/3:0H-kblockd
30 ? 00:00:00 kdevtmpfs
31 ? 00:00:00 netns
32 ? 00:00:00 kworker/u8:1-events_unbound
34 ? 00:00:00 rcu_tasks_kthre
35 ? 00:00:00 kworker/2:1-events
37 ? 00:00:00 kworker/u8:2-events_unbound
45 ? 00:00:00 kworker/1:1-cgroup_destroy
53 ? 00:00:00 kauditd
73 ? 00:00:00 kworker/3:1-memcg_kmem_cache
77 ? 00:00:00 kworker/0:1-events
81 ? 00:00:00 kworker/u8:3-events_power_efficient
626 ? 00:00:00 kworker/u8:4-events_unbound
630 ? 00:00:00 oom_reaper
631 ? 00:00:00 writeback
633 ? 00:00:00 kcompactd0
634 ? 00:00:00 ksmd
635 ? 00:00:00 khugepaged
636 ? 00:00:00 crypto
637 ? 00:00:00 kintegrityd
639 ? 00:00:00 kblockd
682 ? 00:00:00 ata_sff
709 ? 00:00:00 irq/59-bd718xx-
752 ? 00:00:00 watchdogd
840 ? 00:00:00 rpciod
841 ? 00:00:00 kworker/u9:0
842 ? 00:00:00 xprtiod
845 ? 00:00:00 cfg80211
888 ? 00:00:00 kswapd0
979 ? 00:00:00 nfsiod
1120 ? 00:00:00 kworker/3:2-memcg_kmem_cache
1153 ? 00:00:00 kworker/2:2-memcg_kmem_cache
1205 ? 00:00:00 kworker/3:3-mm_percpu_wq
1417 ? 00:00:00 spi1
1504 ? 00:00:00 ci_power_lost
1512 ? 00:00:00 ci_power_lost
1589 ? 00:00:00 cfinteractive
1605 ? 00:00:00 irq/35-mmc1
1610 ? 00:00:00 kworker/3:4-events
1611 ? 00:00:00 irq/36-mmc2
1615 ? 00:00:00 kworker/0:2-cgroup_destroy
1616 ? 00:00:00 kworker/0:3-mm_percpu_wq
1624 ? 00:00:00 galcore workque
1625 ? 00:00:00 kworker/0:4-pm
1626 ? 00:00:00 galcore_deamon/
1627 ? 00:00:00 galcore_deamon/
1648 ? 00:00:00 mmc_complete
1685 ? 00:00:00 kworker/0:1H-mmc_complete
1746 ? 00:00:00 ion_system_heap
1795 ? 00:00:00 scsi_eh_0
1796 ? 00:00:00 scsi_tmf_0
1797 ? 00:00:00 usb-storage
1832 ? 00:00:00 ipv6_addrconf
1835 ? 00:00:00 krfcommd
1836 ? 00:00:00 mmc_complete
1839 ? 00:00:00 kworker/3:1H-kblockd
1865 ? 00:00:00 kworker/2:1H-kblockd
1866 ? 00:00:00 kworker/2:2H
1867 ? 00:00:00 jbd2/mmcblk1p2-
1868 ? 00:00:00 ext4-rsv-conver
1874 ? 00:00:00 kworker/1:1H-kblockd
1883 ? 00:00:00 kworker/3:2H-kblockd
1884 ? 00:00:00 kworker/3:5-events
1897 ? 00:00:00 kworker/1:2H
1904 ? 00:00:00 kworker/0:2H
1914 ? 00:00:00 kworker/1:2-events
1917 ? 00:00:00 systemd-journal
2319 ? 00:00:00 kworker/2:3-events
2986 ? 00:00:00 systemd-udevd
3001 ? 00:00:00 systemd-timesyn
3153 ? 00:00:00 kworker/1:3
3183 ? 00:00:00 atd
3191 ? 00:00:00 crond
3192 ? 00:00:00 dbus-daemon
3204 ? 00:00:00 ofonod
3217 ? 00:00:00 rpcbind
3226 ? 00:00:00 syslogd
3231 ? 00:00:00 systemd-logind
3249 ? 00:00:00 connmand
3251 ? 00:00:00 klogd
3254 ? 00:00:00 systemd-network
3255 ? 00:00:00 avahi-daemon
3257 ? 00:00:00 rpc.statd
3260 ? 00:00:00 avahi-daemon
3267 tty1 00:00:00 agetty
3268 ttymxc1 00:00:00 login
3283 ? 00:00:00 wpa_supplicant
3284 tty7 00:00:00 weston <defunct>
3286 ? 00:00:00 systemd
3287 ? 00:00:00 (sd-pam)
3292 tty7 00:00:00 (sd-pam) <defunct>
3294 tty7 00:00:00 weston-keyboard
3336 tty7 00:00:00 weston-desktop-
3343 ? 00:00:00 bluetoothd
3344 ttymxc1 00:00:00 sh
3355 ttymxc1 00:00:00 ps
root@imx8mmevk:~#

U-BootとLinux KernelはYoctoのパッケージを使用せず別でビルドしています。
弊社基板はメモリサイズを1GByteにしており、U-BootとLinux Kernelでメモリサイズは変更しています。
起動ログの先頭は下記になります。
メモリサイズは正常に1GByteとして認識されています。
また、メモリが足りない可能性を考えて、Swapメモリも対応してみましたが
同じ結果でした。

weston起動時に表示されるメモリダンプについて何か考えられる原因はありますでしょうか？

U-Boot SPL 2019.04 (Jun 10 2020 - 21:04:12 +0900)
power_bd71837_init
DDRINFO: start DRAM init
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from MMC1

U-Boot 2019.04 (Jun 10 2020 - 21:04:12 +0900)

CPU: Freescale i.MX8MMQ rev1.0 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 62C
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM: 1 GiB
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Run CMD11 1.8V switch
OK
In: serial
Out: serial
Err: serial

BuildInfo:
- ATF 70fa7bc
- U-Boot 2019.04

Run CMD11 1.8V switch
switch to partitions #0, OK
mmc1 is current device
flash target is MMC:1
Run CMD11 1.8V switch
Net: FEC [PRIME]
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
Run CMD11 1.8V switch
switch to partitions #0, OK
mmc1 is current device
Run CMD11 1.8V switch
20234752 bytes read in 255 ms (75.7 MiB/s)
Booting from mmc ...
36702 bytes read in 7 ms (5 MiB/s)
## Flattened Device Tree blob at 43000000
Booting using the fdt blob at 0x43000000
Using Device Tree in place at 0000000043000000, end 000000004300bf5d

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 4.19.35-APS1G (asdusr@asdhost) (gcc version 8.3.0 (Debian 8.3.0-2)) #58 SMP PREEMPT Mon Jun 8 16:00:12 JST 2020
[ 0.000000] Machine model: Algosystem i.MX8MM APS1G board
[ 0.000000] earlycon: ec_imx6q0 at MMIO 0x0000000030890000 (options '115200')
[ 0.000000] bootconsole [ec_imx6q0] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.

yakuhito

2020/6/11 (木) 21:48

確認ですが
Using Device Tree in place at 0000000043000000, end 000000004300bf5d
と記載がありますが、別環境で構築されたターゲットボード向けに修正されたdtsからコンパイルされたdtbが書き込まれているのでしょうか？

仙波儀一郎

2020/6/12 (金) 08:53

はい、U-BootとKernel Imageおよび、dtbファイルは別途ソースコードをダウンロードしてコンパイルしました。

このやりかたは、まずいでしょうか？

yakuhito

2020/6/15 (月) 10:49

プロジェクトの初期段階において、カーネル関連の開発をYoctoProjectのbuild環境とは別に行うのは、レアケースでは
ありません。
DTSの記述はハードウェアの実装に合わせたものをお使いと思いますが、実装と合っておりますでしょうか？

なお、カスタムボード上での動作に関しましてはYoctoBBQの守備範囲を超えてしまいますので、弊社営業 sales@lineo.co.jp　
宛にご相談いただけると幸いです。

仙波儀一郎

2020/6/15 (月) 16:19

DTSについては、ハードウェアと合わせています。
変更した、LAN PHYやMIPI-DSI→LVDSブリッジおよび、オーディオデバイスについては動作しています。
GPUやVPUの記述については、EVKと違いはないと判断して、そのままにしています。

また、waylandとwestonを使用するのが今回はじめてなので、i.MX系で初めてGPU/VPUを使用する環境になります。
GPU/VPUへのアクセスがwaylandのグラフィックドライバから直接アクセスされたりするものであれば、
YoctoプロジェクトのU-BootやKernelで設定したメモリサイズを使って、ビルドされている可能性も考えていました。
そのメモリサイズが2GByteのままになっているために起こっている可能性はないでしょうか？

yakuhito

2020/6/16 (火) 11:43

弊社でrootfsとカーネルを別建てで開発する場合、kernel構築ではBSPで生成したツールチェインで構築を行っています。
以下で発生している状況と同じような現象の可能性もあります。
https://community.nxp.com/thread/501654

kernel/gcc のバージョンが同一の、i.mx-4.1.35-1.1.0 で一度確認されてみてはいかがでしょうか？

repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-warrior -m imx-4.19.35-1.1.0.xml

仙波儀一郎

2020/6/16 (火) 15:38

こちらでも、バージョンが異なることに気が付き、現在、imx-4.19.35-1.1.0で再度ビルド中です。
結果がわかりましたら、ご報告させていただきます。