**** BEGIN LOGGING AT Wed Feb 05 03:00:09 2020 Feb 05 19:01:57 JPEW: what image do you usually build for the tinker board, as in - what format? I see there are two classes, a gpt image and an update-image, but building the "rockchip-basic-image" recipe which does not include those classes spits out an ext4 and a wic file Feb 05 20:38:09 Jin^eLD: wic Feb 05 20:38:33 Jin^eLD: It should be generated by default if you don't otherwise override it Feb 05 20:39:29 I figured it out in the meantime, indeed wic is the image with all the partitions and so on Feb 05 20:39:35 console seems to be configured to a different port by default though Feb 05 20:39:53 JPEW: do you know if it actually needs this big number of partitions? Feb 05 20:43:26 Jin^eLD: The SoC doesn't require that they be actual partitions if thats what you mean Feb 05 20:43:36 It's just looking at those offsets Feb 05 20:44:08 so you can't partition it freely the way you want it as you'd normally do on some other hw? where you just define your partitions on emmc and tell u-boot where your rootfs is? Feb 05 20:44:26 Jin^eLD: Ya, for whatever reason the serial console is on a different set of pins from the Raspberry Pi Feb 05 20:45:42 Jin^eLD: You can, as long as idbloader.img and u-boot.bin are at those specific offsets Feb 05 20:46:04 ah, so only those two are important and the rest can be whatever you wish, ok cool, thx Feb 05 20:46:30 I get a bit incosistent results when booting at the moment but I was able to boot the compiled image once, I think I need to connet to another serial Feb 05 20:46:32 Jin^eLD: Correct, at least AFAIK. I haven't actually tried not having partitions Feb 05 20:46:55 Jin^eLD: Ya the serial port is annoying, but that' Feb 05 20:47:05 oh no, I am not against partitoins, but for my use case I need two rootfs partitions for a fallback rootfs update scenario and one data partition Feb 05 20:47:09 thats the one the u-boot maintainers chose, so I made it match Feb 05 20:47:31 Jin^eLD: Ya, once your in u-boot you can make it do whatever you need Feb 05 20:47:39 cool Feb 05 20:47:59 The default u-boot looks for a boot.script or extlinux.conf on the first partition marked as "active" Feb 05 20:48:37 I would *highly* recommend writing a boot script to do what you want, its quite flexible and means you don't have to change u-boot Feb 05 20:48:50 And I was wrong, it's boot.scr not boot.script :) Feb 05 20:50:48 :) Feb 05 20:51:06 I think I anyway will need to write an own uboot script because I am planning to use it with swupdate Feb 05 20:51:21 so u-boot will have to decide which of the two rootfs'es to boot and stuff like that Feb 05 20:54:46 my flashing of emmc somehow went wrong though, Feb 05 20:54:48 did it from the PC Feb 05 20:55:12 spl: mmc init failed with error: -95 Feb 05 20:55:12 is what I am getting Feb 05 20:55:20 at least now I see it after finding the uart2 pins :) Feb 05 20:59:16 I am a bit confused that it does not show me the mmc anymore when I connect it to the notebook, i.e. for reflashing Feb 05 21:08:10 JPEW: the wic has everything on it right, i.e. I should be able to simply dd it to /dev/mmcblk0 when I'm booted from sdcard and it should be fine? Feb 05 21:08:31 I don't seem to be able to boot from mmc and not sure why Feb 05 21:08:52 same yocto image dumped on the sdcard + setting sdcard jumper - boots Feb 05 21:10:09 I guess that's not a yocto problem anymore so I won't bother you with that :) Feb 05 21:13:02 I have a question about external modules and .symvers Feb 05 21:13:56 reading the module.bbclass, if a DEPENDS is named kernel-module-*, its .symvers is added to the extra_symbols search path ( https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass#n12 ) Feb 05 21:15:01 but e.g. in case of the example of the hello-mod, the package isn't named kernel-module-hello, but hello-mod, so the DEPENDS would contain hello-mod, not "kernel-module-hello" ( https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb ) Feb 05 21:16:40 this can be worked around by adding a PROVIDES += "kernel-module-hello" to hello-mod, and then the DEPENDS would contain a kernel-module line Feb 05 21:18:04 but then it would add ${STAGING_INCDIR}/kernel-module-hello/Module.symvers to the search path, which doesn't exist, as it is installed at ${STAGING_INCDIR}/hello-mod/Module.symvers https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass#n65 Feb 05 21:18:45 is this a bug, or am I reading/holding something wrong? Feb 05 21:42:53 JPEW: hmm, when I falsh the .wic to emmc of the tinker - it won't boot, is there any additional configuration or option I need to set (currently built the image with "nodistro") or what could I be missing? https://paste.ee/p/N5C2s Feb 05 21:43:07 I can get into UMS mode via Armbian and flash the emmc this way Feb 05 21:43:23 but booting yocto only worked from the sd-card Feb 05 21:54:46 JPEW: so, with armbian flashed into emmc it tries to boot... console stops at "Starting kernel", so that means u-boot was able to find something and attempted to load it Feb 05 21:54:57 with the Yocto image I get what you see above in the paste.ee Feb 05 21:55:27 I am wondering if the yocto image is missing something in the u-boot configuration or where I should be digging? does it work in your board when you flash it to emmc? Feb 05 22:20:22 denix: can you elaborate on the rationale for the two weston patch reverts in meta-arago's zeus branch? I'm trying to work out if we need them for AGL or not... Feb 05 22:20:52 smurray: link? Feb 05 22:21:02 just a sec Feb 05 22:22:26 denix: patch 0001/0002: http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-distro/recipes-graphics/wayland/weston_7.0.0.bbappend;h=fc448b42948360c75d10b9ffedb2d7b01964e4ed;hb=zeus Feb 05 22:23:36 denix: the commit that adds those just says "HACK: weston: revert EGL_KHR_partial_update changes that require EGL 1.5", which I'm not graphics stack savvy enough to understand the consequences of Feb 05 22:24:35 denix: weston 7.0.0 compiles for me for dra7 w/o them, so I figured I'd come to the source ;) Feb 05 22:25:30 smurray: ok, got it, here's the commit - http://arago-project.org/git/?p=meta-arago.git;a=commitdiff;h=5ab873a1b06648286711ec2b9acb849b07a5443c Feb 05 22:26:46 denix: yeah. Is that avoiding a runtime issue wrt EGL not being 1.5? Feb 05 22:30:29 smurray: we used to have GLES/EGL binary blobs for our SGX-based platforms that predate 1.5 standard Feb 05 22:31:09 smurray: when weston updated to 7.0, it started using some EGL 1.5 extensions that we didn't have, hence needed to disable those in Septamber Feb 05 22:31:49 denix: ah, okay. So e.g. BBB would be affected? Feb 05 22:32:11 smurray: at the same time we were looking at updating SGX blobs to support 1.5 version. that got merged in early November - http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=5ac0ca6ea079a90b0c65e8233953bfb9cde2b6d1 Feb 05 22:32:46 denix: okay, so a bit of a historical artifact Feb 05 22:33:06 so, right now we do support 99% of EGL 1.5 standard in our SGX blobs. that explains why you can build weston 7.0 w/o those reverts from September :) Feb 05 22:33:18 heh, okay, thanks Feb 05 22:33:51 dare I ask the historical reason behind the weston patching being in meta-arago instead of meta-ti? Feb 05 22:35:32 smurray: I try really hard to keep meta-ti BSP as clean as possible (Yocto compliance and such). weston patching was always rather hacky and questionable, hence I kept it away Feb 05 22:35:56 denix: okay, cool Feb 05 22:37:11 smurray: thanks for raising this question - this means I can now revert those reverts :) Feb 05 22:37:22 denix: heh Feb 05 22:38:34 denix: btw, a couple of the patches that are commented out do seem to compile for me in AGL (0003-Weston-Fix-virtual-keyboard-display-issue-for-QT5-ap.patch and 0004-Weston-Fix-touch-screen-crash-issue.patch) Feb 05 22:39:59 smurray: nice, thanks for testin! I didn't have time to that myself when upgrading from weston 5.0 to 7.0 :) Feb 05 22:41:13 denix: the bbappend and patches that were copied to AGL are pretty stale at this point, I'm going to refresh off of what's in meta-arago for zeus and retest Feb 05 22:42:22 denix: heh, I'm guessing ti-ipc-rtos is completely not parallelized? taking forever to build Feb 05 22:42:23 smurray: btw, you may be slightly ahead of us - we are still ramping up zeus and a lot of things are still disabled. e.g. SGX is not yet fully merged to 5.4 kernel Feb 05 22:43:20 smurray: yeah, I know! it kills me to watch it compile on my 56-threaded server! :) Feb 05 22:43:39 denix: heh, original threadripper here, but same Feb 05 22:44:17 smurray: do you still use your beefy NUC when traveling? Feb 05 22:44:43 denix: yeah, though am usually careful to make sure it has recent sstate before leaving home Feb 05 22:46:11 denix: thanks for the heads up re the state of SGX. ATM, the plan is to getting AGL dra7 at least compiling to keep CI happy, we do have access to a couple of boards to try booting it up and see what happens Feb 05 22:49:33 smurray: sounds good, please keep me posted - it's always nice to get feedback from "early adopters", as real customers will only get to try it much later in the year... Feb 05 22:49:52 denix: okay, will do Feb 05 22:50:21 denix: heh, whew, ti-ipc-rtos is done, probably like 55 min Feb 05 22:52:35 heh :) I'll see if I can beat those guys into submission in order to make it paraller-safe... last time they said it was easier to fly to the moon... :) Feb 05 23:11:07 denix: lol Feb 06 02:32:29 Jin^eLD: i just tried a clean build of tinker-board, flashed, and it booted fine Feb 06 02:33:07 Jin^eLD: by the way, i believe eMMC is when it's soldered directly onto the board, the tinker-board doesn't have any eMMC, just removable uSD card (i.e. MMC) Feb 06 02:33:18 Jin^eLD: https://pastebin.com/EX1FbnyG **** ENDING LOGGING AT Thu Feb 06 02:59:57 2020