**** BEGIN LOGGING AT Wed May 11 02:59:56 2022 **** ENDING LOGGING AT Wed May 11 06:11:35 2022 **** BEGIN LOGGING AT Wed May 11 11:14:15 2022 May 11 15:10:15 Herrie: I've reproduced your ppp build failure with linux-pinephonepro, will have a look May 11 16:05:29 JaMa: Ah good it's reproducable :) May 11 16:12:24 it's caused by https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=b0f8d8a4c063936b50d3ec7c066b29157b3c3544 I probably didn't build ppp since then and didn't realize that ppp uses fitimage while pp doesn't May 11 16:18:17 pp failed in u-boot which I think I've fixed already but don't really remember, let me check the irc log May 11 16:19:59 2022-02-22.log:23:08 < JaMa> will check tomorrow, u-boot is also failing to build now for pp May 11 16:44:40 u-boot issue is caused by https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=0ea02ca5c1fc4e15f640b1c26c0a5ce34fc08c05 May 11 17:05:49 Tofe: do you remember some details about what you did in u-boot.bbappend? May 11 17:06:20 https://github.com/webOS-ports/meta-pine64-luneos/pull/32 should fix both issues, but not tested in runtime May 11 17:28:38 JaMa: Thnx May 11 17:55:51 JaMa: let me have a look May 11 17:57:51 JaMa: look like I integrated ATF, added the boot script, tweaked a bit the boot args for the kernel May 11 17:58:41 after a while I also integrated the Crust binary output May 11 18:02:18 Tofe: so the UBOOT_ENV_SUFFIX was mostly set to let u-boot.inc to automatically install it with install -m 644 ${WORKDIR}/${UBOOT_ENV_BINARY} ${D}/boot/${UBOOT_ENV_IMAGE}, right? May 11 18:02:36 and then you had to make it happen with manual mkimage + adding it to FILES May 11 18:02:55 JaMa: Got PPP image ready here for kirkstone now, flashing and will test soon May 11 18:03:18 JaMa: yes, I picked the easiest one May 11 18:04:21 FWIW: in older version of PR I've also removed UBOOT_ENV setting from pp.conf (as it's the default, but it's only in uboot-config.bbclass which is too late, so I've returned UBOOT_ENV to pp.conf May 11 18:05:01 There's absolutely no issue changing this kind of thing, as long as we match the corresponding boot partition content May 11 18:05:19 I haven't tried in runtime :) May 11 18:05:41 JaMa: if there's an image lying around, I can flash it and try May 11 18:05:47 and there might be one more issue for pp (possibly independent) May 11 18:05:54 | ERROR: A native program mkfs.ext4 required to build the image was not found (see details above). May 11 18:05:57 | May 11 18:05:59 | Please make sure wic-tools have e2fsprogs-native in its DEPENDS, build it with 'bitbake wic-tools' and try again. May 11 18:06:34 doesn't it look like an issue in wic-tools recipe ? May 11 18:06:40 haven't finished whole image because of ^^ May 11 18:07:09 the dependency is there by default, might be related to 22.04 host, but don't see the exact error from wic yet May 11 18:07:26 "details above" not helpful :) May 11 18:07:30 ah, or we're missing wic-tools in our image RDEPENDS, but that would be weird May 11 18:07:55 (well, DEPENDS) May 11 18:08:08 https://pastebin.com/nfk2JPUj May 11 18:08:18 DEPENDS should be added magically from FSTYPES May 11 18:08:30 and it doesn't fail like this on ppp build May 11 18:08:36 will debug a bit more May 11 18:10:01 Surprising error yes May 11 18:11:09 https://pastebin.com/jkTrDPCi mkfs.ext4 is just missing in pp and is in rss-native for ppp May 11 18:12:00 maybe just bad race-condition from running out of disk space recently May 11 18:12:14 Well I can try PP build here May 11 18:12:27 PPP doesn't boot, serial doesn't give much useful for now May 11 18:20:03 JaMa: AFAIK for PPP we shouldn't be using FitImage. I toyed with it for a bit, but couldn't get it to work May 11 18:20:23 So you're fix might not be the one we're looking for May 11 18:20:28 it's set through meta-rockchip May 11 18:20:52 and I believe it was set the same in honister, let me check May 11 18:21:31 It could be my memory is faulty. I just remember I tried to get a fitImage (kernel + initramfs integrated) and it didn't work, so I went back to old way May 11 18:21:46 Could be there were some leftovers in recipe somehow May 11 18:21:51 luneos-honister/webos-ports $ bitbake-getvar -r linux-pinephonepro KERNEL_CLASSES May 11 18:21:54 # May 11 18:21:57 # $KERNEL_CLASSES [3 operations] May 11 18:21:59 # set /OE/build/luneos-honister/webos-ports/meta-rockchip/conf/machine/include/rk3399.inc:14 May 11 18:22:02 # "kernel-fitimage" May 11 18:22:05 # set /OE/build/luneos-honister/webos-ports/openembedded-core/meta/conf/documentation.conf:247 May 11 18:22:08 # [doc] "A list of classes defining kernel image types that kernel class should inherit." May 11 18:22:11 # set? /OE/build/luneos-honister/webos-ports/openembedded-core/meta/classes/kernel.bbclass:161 May 11 18:22:14 # " kernel-uimage " May 11 18:22:16 # pre-expansion value: May 11 18:22:19 # "kernel-fitimage" May 11 18:22:21 KERNEL_CLASSES="kernel-fitimage" May 11 18:22:24 yes, the same in honister, just not failing because of extra check introduced in kirkstone May 11 18:23:09 JaMa: OK then not booting might be due to something else May 11 18:23:14 Let me first charge up the batteries a bit May 11 18:23:23 Wouldn't be the first time that's the issue May 11 18:23:36 Tofe: If you're interested I have Kirkstone PP image for you May 11 18:23:48 Ah wait too quick May 11 18:23:55 Herrie: it didn't fail for you like for me? May 11 18:24:02 ERROR: _exec_cmd: install -m 0644 -D /mnt/5ba5d474-0b2d-49d6-a5a6-9de20c3ac967/kirkstone/webos-ports/tmp-glibc/deploy/images/pinephone/initramfs-uboot-image-pinephone.rootfs.cpio.gz.u-boot /mnt/5ba5d474-0b2d-49d6-a5a6-9de20c3ac967/kirkstone/webos-ports/tmp-glibc/work/pinephone-webos-linux/luneos-dev-image/1.0-r0/tmp-wic/boot.2/initramfs-uboot-image-pinephone.uboot returned '1' instead of May 11 18:24:02 0 May 11 18:24:02 | output: install: cannot stat '/mnt/5ba5d474-0b2d-49d6-a5a6-9de20c3ac967/kirkstone/webos-ports/tmp-glibc/deploy/images/pinephone/initramfs-uboot-image-pinephone.rootfs.cpio.gz.u-boot': No such file or directory May 11 18:24:49 is this latest kirkstone of meta-pine? May 11 18:24:56 Not sure need to check May 11 18:25:19 I think you're mising https://github.com/webOS-ports/meta-pine64-luneos/commit/83631351def58089d731854025040aa0b6d5f8ff I've merged yesterday May 11 18:26:05 Seems your fix wasn't there May 11 18:26:08 Yeah I guess so May 11 18:26:11 Fixed that now May 11 18:26:20 New try May 11 18:28:25 I have the same issue now ;) May 11 18:28:31 I might have a fix May 11 18:28:44 | Please make sure wic-tools have e2fsprogs-native in its DEPENDS, build it with 'bitbake wic-tools' and try again. May 11 18:28:49 interestingly ppp also doesn't set WKS_FILE, so that might be the reason why it doesn't fail May 11 18:29:07 I'm adding e2fsprogs-native to WKS_FILE_DEPENDS in pp.conf May 11 18:29:10 I thought we have WKS from meta-rockchip May 11 18:29:58 I.e.: https://git.yoctoproject.org/meta-rockchip/tree/wic/rockchip.wks?h=kirkstone May 11 18:29:58 ah, maybe you have, I was only grepping meta-pine May 11 18:30:11 I recall using that May 11 18:31:57 meta-rockchip/conf/machine/include/rockchip-wic.inc doesn't have e2fsprogs-native in WKS_FILE_DEPENDS, something else might be going on May 11 18:43:15 strange this is in meta-rockchip master https://git.yoctoproject.org/meta-rockchip/commit/conf/machine/include/rockchip-wic.inc?id=3d640e324637b7ffa657ac317003e393df369d71 but not yet in kirkstone May 11 18:43:35 and you're seeing it with kirkstone already, right? not using langdale like me? May 11 19:01:06 maybe it's 22.04 specific after all somehow May 11 19:01:22 but anyway I've added the fix to the PR May 11 19:03:43 JaMa: it's really weird how lvgl is packaged today in meta-oe May 11 19:04:06 with the pre-defined config? May 11 19:04:11 yes; not sure how I'm supposed to adapt it for my own configuration May 11 19:04:33 right now, it just takes the template and actiates the defaults May 11 19:05:03 but with lvgl, we're always supposed to adapt the bit depth, the theme, the resolution, etc May 11 19:05:09 there was PACKAGECONFIG for something, right? I guess the intention was to add PACKAGECONFIGs for things people usually change in template May 11 19:06:22 or possibly just force own config from bbappend May 11 19:06:32 I don't see any PACKAGECONFIG in this case May 11 19:06:45 I was thinking about LVGL_CONFIG_LV_MEM_CUSTOM variable May 11 19:08:13 JaMa: Yeah on Kirkstone here May 11 19:09:05 JaMa: I guess I'll just add things in a bbappend, and include my lv_conf and lv-drivers_conf somehow May 11 19:09:22 lvgl is supposed to work as a MACHINE_ARCH in the spirit anyway May 11 19:10:07 Huawei doesn't seem to care about PACKAGE_ARCH :0 May 11 19:11:46 yup, but if used as-is, there's no way I can used lv-drivers on fbdev, as only wayland is active by default May 11 19:14:01 JaMa/Tofe: PP Kirkstone build now here May 11 19:14:02 if it's too much hassle and you don't see a way how to make the shared recipe usable, just leave lvgl in meta-pine (possibly with a comment in recipe explaining why the one in meta-oe isn't usable and needs to be overlayed) May 11 19:15:22 JaMa: I think I'll manage; but MACHINE_ARCH will be needed for sure May 11 19:15:29 https://git.openembedded.org/openembedded-core/commit/?id=66a6b2080e4a65632c5dc02c8ef0cbe01d5b5082 was the root cause of wic issue, will update commit message in PR May 11 19:15:54 Herrie: nice ! it's shared as usual ? May 11 19:16:07 and this commit is also in kirkstone now, so ppp should probably fail to build as well (until the fix in meta-rockchip is picked to kirkstone) May 11 19:17:27 Tofe: I'm uploading it now, should be there in a few mins: luneos-dev-image-pinephone-kirkstone.wic.gz May 11 19:17:56 Herrie: you built ppp with kirkstone already, right? can you check what meta-rockchip revision you had? May 11 19:19:17 aha, layers.conf says master not kirkstone yet, so you had the fix which is in master only, will ping trevor May 11 19:19:28 to fix that before switching the branch in webos-ports-setup May 11 19:19:56 JaMa: Yeah I guess I was building master May 11 19:20:01 Anyway PPP doesn't boot for now May 11 19:21:28 Tofe: Image should be there now May 11 19:25:55 Herrie: can you also put the bmap file ? May 11 19:26:15 Herrie: can you try to swap kernel built from honister to see if it boots fine after that? May 11 19:27:29 Tofe: Gimme a second May 11 19:28:14 JaMa: I'll need to copy a file (which is included locally with the bbappend) to the source tree *before* bitbake does do_configure:prepend in lvgl, what best option do I have ? do_unpack:append ? May 11 19:28:24 Tofe: luneos-dev-image-pinephone-0-0.rootfs.wic.bmap May 11 19:28:29 perfect ! May 11 19:28:59 JaMa: Need to see how to do that since I'm flashing the image with BalenaEtcher, not sure how to just swap the kernel May 11 19:35:42 Tofe: another do_configure:prepend should work from .bbappend May 11 19:36:03 JaMa: but it might be executed too late May 11 19:36:18 I think it will prepend the prepend, so it should be fine May 11 19:36:43 okay, in that case, it's all good :) May 11 19:38:07 if it doesn't work or if your config is close to the template, then you can just add a patch for template and leave do_configure:prepend as-is May 11 19:38:16 Herrie: PP boots, but sound isn't working; also UI is slow, probably meaning we lack GLES acceleration May 11 19:39:09 JaMa: that's a tempting solution May 11 19:39:12 that might actually be better for documenting what was changed in the template and why - while forcing to adjust the .patch whenever new lvgl is in meta-oe and we might need to re-evaluate the config May 11 19:39:37 yes, I like that too May 11 19:40:05 if it fails to patch it will be obvious what to do while we might not notice that we're missing something from updated template in some future version May 11 19:41:59 there were quite a few changes in mesa in oe-core in kirkstone, we might be missing some PACKAGECONFIG for pp which used to be enabled in honister May 11 19:44:39 web apps don't work apparently, but that could be related to the lack of proper gles too May 11 19:45:38 Tofe: I see the same in Qemu May 11 19:45:47 With regards to webapps May 11 19:45:51 So probably something else May 11 19:45:57 ah, yes May 11 19:45:58 Or mesa somehow as well May 11 19:46:56 fwiw I thought that I've built all MACHINEs with kirkstone recently and it was in february (and only some machines later in april), it's terrible how quickly the time flies.. May 11 19:48:03 but there shouldn't be too many dangerous changes since then as kirkstone was already in stabilization May 11 19:48:40 well, my PP boots, so the worst is avoided :) May 11 19:48:57 PPP doesn't yet, but well... May 11 19:49:11 will check qemu tomorrow, now need to do more benchmarks to see if my chipset cooler mod helps with temperatures May 11 19:56:07 Tofe: This is my qemu log: https://pastebin.ubuntu.com/p/H6jpmpCcRV/ May 11 19:56:49 is it the same as https://pastebin.ubuntu.com/p/gMDjjqMskK/ from yesterday? May 11 19:57:43 Well a new boot, but yet May 11 19:57:46 yes May 11 19:57:50 different boot time, but the same image, right? May 11 19:57:55 Yes May 11 19:58:18 Let me check logs of Honister for something obvious May 11 19:59:23 there were issues with vboxvideo in kirstone before, but IIRC Tofe already replaced it with wmgfx May 11 19:59:34 right May 11 19:59:59 There's a lot of these in kirkstone that I don't see in Honister logs: May 11 20:53:21 qemux86-64 WebAppMgr[1302]: [] [pmlog] wam.log ERROR {} E[1302:1331:u_channel_manager.cc(746)] "ContextResult::kFatalFailure: Failed to create shared context for virtualization.\n" May 11 19:59:59 May 11 20:53:21 qemux86-64 webapp-mgr.sh[1302]: [1302:1331:0511/205321.319643:ERROR:gpu_channel_manager.cc(746)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. May 11 19:59:59 May 11 20:53:21 qemux86-64 webapp-mgr.sh[1302]: [1302:1331:0511/205321.319719:ERROR:shared_image_stub.cc(460)] SharedImageStub: unable to create context May 11 19:59:59 May 11 20:53:21 qemux86-64 webapp-mgr.sh[1302]: [1302:1331:0511/205321.319757:ERROR:gpu_channel.cc(449)] GpuChannel: Failed to create SharedImageStub May 11 20:00:35 May 11 20:53:21 qemux86-64 WebAppMgr[1302]: [] [pmlog] wam.log FATAL {} F[1302:1413:e/wayland/display.cc(318)] "The browser process has attempted to start the GPU process in software rendering mode. Software rendering is not supported in Ozone-Wayland, so this is fatal. Usually this error occurs because the GPU process crashed in hardware rendering mode, often due to failure to initialize May 11 20:00:35 EGL. To debug the GPU process, start Chrome with --gpu-startup-dialog so that the GPU process pauses on startup, then attach to it with 'gdb -p' and run the command 'signal SIGUSR1' in order to unpause it. If you have xterm then it is easier to run 'chrome --no-sandbox --gpu-launcher='xterm -title renderer -e gdb --eval-command=run --args''\n" May 11 20:18:43 Herrie: the issue is probably earlier than that, in the gles wmgfx initialization or so May 11 20:24:50 Tofe: Here's a recent Honister log from qemu: https://pastebin.ubuntu.com/p/CBt68T3CJS/ May 11 20:30:52 I just see "Available shader model: Legacy" and there are less details on the screen initialization, but otherwise it's very similar May 11 20:44:57 Tofe: It seems it's a bit more verbose in Kirkstone somehow in terms of logging **** ENDING LOGGING AT Thu May 12 02:59:57 2022