**** BEGIN LOGGING AT Tue May 14 02:59:57 2019 May 14 08:22:59 https://www.oesf.org/forum/index.php?showtopic=35764 May 14 08:23:24 having this issus, try to empty the battery, plug back and still having this issue May 14 08:23:27 help May 14 14:06:50 greguu: TheKit: btw is jasu camping around here ? May 14 17:12:34 Marex, he seems to have interest or something else happened and didn't respond to kernel mailing list regarding his patches May 14 17:12:41 *to have lost interest May 14 17:31:05 TheKit: too bad :) May 14 17:31:58 TheKit: I'm shuffling between multiple topics myself May 14 18:07:31 Marex, did you attempt to get the framebuffer? I saw simplefb commited for use with Qualcomm boards May 14 18:09:14 TheKit: nope, I was busy with other stuff May 14 19:51:23 mw 0xbdff0000 0xffffffff 100000 does the trick setting aproximately half of screen white May 14 20:59:28 TheKit: so the display is XRGB8888 at 0xbdff0000 ? May 14 21:00:27 yes, but I'm confused about size May 14 21:00:29 lk says [414] FB base = 0xbdff0000, FB size = 0x1f90000 (33095680) May 14 21:01:27 [716] [LK_DDP/OVL]ovl0, layer=0, source=memory, off(x=0, y=0), dst(0, 0, 1080, 2160),pitch=4352,fmt=eBGRA8888, addr=bdff0000, keyEn=0, key=0, aen=1, alpha=255 May 14 21:06:37 TheKit: isn't that something about mali driver being utter pile of screaming garbage ? May 14 21:07:13 TheKit: last time I touched mali (but that's mali 4xx, not Tyyy), they used plain old double-buffering when rendering May 14 21:08:00 TheKit: the GPU rendered at sizeof(framebuffer) offset and when it was done, the swap was just a matter of updating the FB address -sizeof(framebuffer) ... then GPU rendered to offset 0 , repeat May 14 21:08:29 TheKit: that's why the size of framebuffer the kernel allocated at that point was twice the size of the actual FB May 14 21:08:57 ok, then it is just the matter of finding the actual displayed offset May 14 21:09:49 TheKit: it could also be that the 32 MiB above is used for multiple planes (the scanout engine might support overlays or whatnot, each with it's own FB) May 14 21:10:11 that would actually make sense, since the print above indicates RGBA , A meaning Alpha channel (Transparency) May 14 21:10:29 yes, that's supported by hwcomposer in Android May 14 21:12:06 and I doubt it's supported by wayland/weston, which decided to do everything using GPU May 14 21:12:18 which, I guess, is easy and great, but also not power efficient May 14 21:47:48 TheKit: I think we need to get the right-side USB going , then the development can start in earnest , since it'd allow tftpboot+nfsboot May 14 21:50:46 ... for which we need i2c to program the TUSB300 May 14 21:50:57 ... for which we need DMA, to do the I2C transfers, joy May 14 21:51:44 but the i2c block has it's own DMA, all right, this might be doable May 14 21:52:50 hmmmmm, can the debian image for gemini kexecboot a new linux kernel image ? I guess not ... it'd be helpful to be able to fiddle with it May 14 22:02:28 is CONFIG_KEXEC enough to enable this? but I suppose it is up to the booted kernel to deal with running hw state May 14 22:15:49 iirc it's CONFIG_KEXEC, yes May 14 22:16:02 zgrep KEXEC /proc/config.gz indicates that nope, it's not enabled May 14 22:16:37 TheKit: I am mostly interested in what it does to the TUSB and the i2c , since decoding it out of the vendorkernel sources is errorprone May 14 22:16:48 being able to verify what the VK does with a printk would be nice May 14 22:17:12 I will enable it and trigger rebuild on Jenkins May 14 22:17:44 TheKit: oh, is that debian image your doing ? May 14 22:19:04 the main maintainer is adam_b, but I am involved as well (mostly with hybris parts) May 14 22:23:16 TheKit: did you consider switching to panfrost instead of the blobs ? May 14 22:24:01 well, gnight May 14 22:24:26 it is not feasible without mainline kernel, as Panfrost/MESA are designed against DRM/GEM stack in kernel May 14 22:24:33 good night May 14 22:25:57 oops, CONFIG_KEXEC it is not available in 3.18 for arm64, it was added only in 4.8 May 14 22:26:52 Ugh May 14 22:27:13 The VK is older than I expected **** BEGIN LOGGING AT Wed May 15 01:32:39 2019 May 15 01:36:42 Marex, TheKit, re kexecboot, there is an early rebase to kernel 3.18-rc2 for the kexec arm64 patch set May 15 01:37:50 https://lwn.net/Articles/620975/ May 15 01:38:19 not sure if this would be worth investigating. if the android kernel has fbdev support one could build a kexecboot kernel **** BEGIN LOGGING AT Wed May 15 01:42:14 2019 **** BEGIN LOGGING AT Wed May 15 01:52:50 2019 **** BEGIN LOGGING AT Wed May 15 02:02:22 2019 **** ENDING LOGGING AT Wed May 15 02:59:57 2019