**** BEGIN LOGGING AT Sun Jun 10 03:00:05 2018 Jun 10 14:46:34 moin Jun 10 14:46:53 I got my gemini today - nice device with good keyboard :-) Jun 10 14:47:17 even better than I thought Jun 10 14:52:38 It becomes addicting :) Good on you for it arriving! Jun 10 14:53:49 Anyone look into Devuan distro? Apparently they have a ARM build -- https://devuan.org/os/debian-fork/ascii-stable-announce-060818 Jun 10 14:54:38 Supports desktop GUI's like XFCE, KDE, MATE, Cinnamon, LXQt and others... Jun 10 15:11:29 TallTim: we'd need to search for and get rid of hard-coded sysctl calls, but the "linux" is really fragile at the moment Jun 10 15:11:57 just a full-screen chroot on Android, basically Jun 10 15:13:00 kilobyte I see, just threw it out there to see if it was worth it. Cheers. Jun 10 15:13:24 would be nice to get rid of systemd, yeah Jun 10 15:14:09 I used to be enthralled with QNX, but that is way too minimal and nothing is built for it really. Jun 10 15:15:34 TallTim: the gemini dev community so far seems so small I don't see the point in more than one distro, of course others will do as they please, but I'd encourage any willing hands to work together... Jun 10 15:15:50 doesn't seem like a priority right now, though: Android's use of uids/gids prevents almost any use of chroots/containers (so no using Gemini as a porterbox or even basic containery stuff), hacks to make it talk to Android are fragile Jun 10 15:16:48 Fair play, adam_b_ - I just like keeping an eye out in the space for distros and such. I realize that Gemini's team is stressed to support their backers. Jun 10 15:17:10 well the gemini team is little involved beyond android Jun 10 15:17:17 kilobyte - A ways to go, absolutely. Jun 10 15:17:24 like, installing one of core xfce components makes 'n' and 'b' keys not work even if xfce is only installed (haven't bisected the set to find which one), etc Jun 10 15:17:45 its 'us' who hang out here who are doing the gemian stuff Jun 10 15:17:47 Oh, interesting. Shame, I like the compact XFCE layout. Jun 10 15:18:01 Well, I appreciate you guys Jun 10 15:18:44 removing kde parts despite no declared dependency gives you blank screen + mouse; etc Jun 10 15:19:13 yeah, _someone_ needs to do the work Jun 10 15:19:18 I'd be fine with basic ASCII-split screen or something. I know you can get that kind of functionality from command line Jun 10 15:19:34 I don't know too much about the android uid/gids - but could it the worth to throw the android things in a namespace so the uids doesn't clutter the "main" os environment? Jun 10 15:19:41 so would I! Jun 10 15:20:42 so you guys don't like lxqt to the extent of refusing to use it Jun 10 15:20:49 mifritscher: can't: the uids are hardcoded and required for things like network to do (Android uses them for what would be better done via capabilities) Jun 10 15:21:38 adam_b_: not really, lxqt is okayish too... but xfce not working is merely one of many symptoms of a wider disease Jun 10 15:22:45 well my take is get one line of usable debian all the way through Jun 10 15:22:52 the core problem is Mediatek folks not documenting their precioussss "intellectual property", thus you don't have free drivers Jun 10 15:22:54 yes - so could the android libs/drivers thrown into a namespace so they see there uids they want? Jun 10 15:23:18 yeah, but Debian starts at base system, which is lacking Jun 10 15:23:44 mifritscher: kernel-wise yes, but you can't edit the blobs Jun 10 15:24:28 but the blobs could be run in a namespace as well? or, if there are in kernel space, a tiny wrapper for simulating the uids they need? Jun 10 15:24:55 which drivers are the main culprits (ie: only in binary form)? Mali beig the big example? Jun 10 15:25:00 *being Jun 10 15:25:05 that could be done, yeah -- but it's not the only problem Jun 10 15:25:18 you don't need Mali for basic functionality Jun 10 15:25:35 (is there somewhere a overview of the current driver/blob status and problems?) Jun 10 15:26:07 for me this device is not the zero blobs device, for that you need puri.sm Jun 10 15:27:07 on x86 without nvidia/etc drivers you see a blank screen, on arm pushing framebuffer to LCD ("display engine") is a separate part of the chip from 3D acceleration Jun 10 15:28:10 so without Mali you don't have GL or hw encoding of video calls, but you can live without those Jun 10 15:28:25 adam_b: I've no problems with blob per se, but the overview could e.g. have some insights how "problematic" is to work with them (what do they need as infrastructure etc.). firmware blobs are e.g. not critical (if they are allowed to distribute etc:) Jun 10 15:29:02 adam_b_: have been trying to build the debian buster rootfs but no matter how many packages i remove multistrap always fails with 1 error after cleanup, i am using the buster branch of https://github.com/gemian/gemian-multistrap-config Jun 10 15:29:22 Aix_: I'm running the buster branch... Jun 10 15:29:33 so, are there any other blobs (ignoring "loading & forget" firmware)? ril is often a problem Jun 10 15:29:41 I ignore the errors and just run the other script Jun 10 15:29:56 perhaps we would need a "sunxi for mediatek^^ Jun 10 15:31:19 mifritscher: sunxi as in Allwinner is as hostile to users as Mediatek, but folks like Icenowy did all the work Jun 10 15:31:34 adam_b_: but shouldn't multistrap be publishing the img file ? or would the rootfs simply be /.stowaways/debian/ path ? Jun 10 15:31:37 Humble question, anyone get the xeffyr/termux-x stuff running under Termux? I managed to solve the openssl apt-get issue, but not sure how to proceed. Not as talented as you guys :) Jun 10 15:32:17 Aix_: well I'm running it on the device, so it makes me that stowaway folder and then I just boot the other kernel that loads from that stowaway Jun 10 15:32:36 kilobyte: ? sunxi did a lot of mainlining stuff? (http://linux-sunxi.org/Linux_mainlining_effort) Jun 10 15:33:14 (ok, I meant this site, not the architecture) Jun 10 15:33:23 mifritscher: that's a group of users (Icenowy, anarsoul, wens, ...) without any help from Allwinner the company Jun 10 15:33:29 yep Jun 10 15:33:53 I thought sunxi is the name of this group, but it seems to be the name of the architecture at first) Jun 10 15:34:23 so we need a linux-mt.org *g* Jun 10 15:35:04 "x" stands as a wildcard: general-purpose chips from Allwinner are named sun4i, sun8i, etc Jun 10 15:35:34 Aix_: I've only just got buster to a vaguely usable level in the last few days, its still rebooting on every device close which makes it not something you'd want as your every day booting so best in a stowaway Jun 10 15:35:35 adam_b_: oh.. i was running on the device as well ok seems i can get to that part.. i was searching for a img file generation issue as multistrap was always ending with a error, ill run the scripts and try booting from the other kernel Jun 10 15:37:53 ah, ok :-) Jun 10 15:38:43 so, is there a community (also other devices) which tries to mainline drivers for mediatek? Jun 10 15:40:31 for the x20 there seems to be some effort ( https://www.oesf.org/forum/index.php?showtopic=34744 ). I'm afraid that the efforts for the mediatek are quite split atm Jun 10 15:40:38 mifritscher: it sounded like some work had been done in that area, but that as mediatek seem to have different branches for each of their chips within themselves the wildcard part dosn't applie so well for us Jun 10 15:42:38 yes, but the good thing is: we have at least code (so "documentation"), so developing a mainlined driver is far more easy than creating one from scratch ;-) I think it is more a job of organizing - and heavily cleaning up the code Jun 10 15:43:26 yea MonkeyOfDoom has started on the led drivers Jun 10 15:44:18 btw, is there already some sort of hw analysis, e.g. whether there are internal usb/uart/jtag connectors? Jun 10 15:45:29 yesterday NeKit was here talking about a soldering iron job to get to a uart under a bit of plastic, see logs Jun 10 15:45:30 there are uart headers but you need to solder them yourself which is not an easy task Jun 10 15:45:31 great @led drivers :-) can the x27 at least be booted somehow (aka: it boots to a shell which is accessible on some way (uart, usb etc.) or is there nothing yet? Jun 10 15:46:04 ah, great @uart :-) Jun 10 15:47:04 I'm afraid that many infos "get lost" in the irc log or in the forums - I think a wiki would be useful... (I could provide one, but the github's one should be enough as well, shouldn't it?) Jun 10 15:47:35 yea I'm using the github one (linked from the gemian repo) Jun 10 15:47:55 its world writable (for github account holders) Jun 10 15:48:05 but still its mostly me that enters things Jun 10 15:48:07 you mean the https://github.com/gemian/gemini-keyboard-apps/wiki one? Jun 10 15:48:13 yep Jun 10 15:48:33 yes, that is a very good start Jun 10 15:50:36 perhaps it would be an idea to have a "mainline status" and a hardware/debug page? Sadly I know nothing about the status :-(, but I would help organising it. Jun 10 15:51:10 there is a debugging page, needs the new info from yesterday added Jun 10 15:51:46 yeah, it has the software side :-) Jun 10 15:52:16 and yea I'm also mostly lacking the info on mainline status, but if you want to start a page on that go for it Jun 10 15:53:58 one useful link for that would be the LED work - https://github.com/mdgem/kernel-3.18-geminipda Jun 10 15:57:32 mifritscher, it's zero basically Jun 10 15:58:01 https://github.com/freedomtan/X20-96-board/wiki/booting-mainline-kernel - it should be possible to boot to UART though Jun 10 15:59:41 which would be a nice start :-) Jun 10 16:00:22 what could be possible next step though? Jun 10 16:01:12 https://github.com/gemian/gemini-keyboard-apps/wiki/LinuxMainlining :-) Jun 10 16:01:18 storage, usb? Jun 10 16:02:16 ok, the first next step should be GPIO (if not already working) Jun 10 16:03:11 initial SoC support for 6797 was accepted in mainline Jun 10 16:03:57 maybe you could send an email to #linux-mediatek to ask for some overview of what is there and what could be reused from their efforts for other SoCs? Jun 10 16:04:34 yes, that was my intention behind linux-mt.org ;-) Jun 10 16:04:52 like mt7623 and mt8173 Jun 10 16:05:44 linux-mt.org? Jun 10 16:06:11 just like linux-sunxi.org ;-) Jun 10 16:07:20 some interesting bits even within current (4.18) merge window Jun 10 16:08:23 I'm trying to get a overview Jun 10 16:09:02 stuff new for 4.18 seems limited to sound and phone calls, though Jun 10 16:13:08 yeah, https://mtk.bcnfs.org/ :-) Jun 10 16:14:02 basic support came in 4.12,4.13 Jun 10 16:15:00 but it had not be tried to boot that with gemini I guess? Jun 10 16:18:44 it had not been, but I can try it if needed dts changes are understood Jun 10 16:19:04 https://patchwork.kernel.org/patch/10448605/ Jun 10 16:20:36 https://patchwork.kernel.org/project/linux-mediatek/list/ - it's interesting to see mt6797-related patches from MediaTek devs though Jun 10 16:23:03 you are afraid that the memory is mapped somewhere else on the gemini? Jun 10 16:23:25 (looking at the very minimal dtb) Jun 10 16:24:00 I just don't know anything about inner hardware workings, unfortunately Jun 10 16:26:40 this dtb only describes the uart and there memory is mapped to. With a bit of luck this can be even derived from a dmesg Jun 10 16:27:02 or maybe from current kernel's dtb? Jun 10 16:27:19 if it is using dtb :-) Jun 10 16:27:43 it is Jun 10 16:28:10 https://github.com/gemian/gemini-linux-kernel-3.18/blob/master/arch/arm64/boot/dts/aeon6797_6m_n.dts Jun 10 16:28:51 hehe, it seems to have the same memory entry :-) Jun 10 16:29:47 so you could yust start with the minimal dtb Jun 10 16:31:11 what about UART? Jun 10 16:31:43 I get output from lk bootloader (before handover to kernel) Jun 10 16:32:08 just try - if it isn't working then play with uart1 Jun 10 16:32:26 uart seems to be an identifier of the hardware uart number Jun 10 16:33:08 luckily the bootloader ist open source, so perhaps I can find the number... Jun 10 16:34:32 Android kernel is booting with console=ttyMT0,921600n1 Jun 10 16:35:30 but you don't see that stuff? Jun 10 16:36:02 I didn't try with mainline yet Jun 10 16:36:53 I meant with the android kernel Jun 10 16:37:59 it boots with printk.disable_uart=1, but I see Android shell prompt after boot is finished Jun 10 16:38:13 ah Jun 10 16:39:05 hmm, if I unterstand the code from the bootload right it defaults to UART2 (https://github.com/dguidipc/gemini-lk/blob/master/lk/platform/mt6797/uart.c) . so if you see nothing with uart1 in the dtb, try uart2 ;-) Jun 10 16:43:58 no example defconfig, it seems Jun 10 16:45:01 could you use the defconfig from the Mediatek X20 Development Board ? Jun 10 16:47:32 I didn't see such either Jun 10 16:48:11 but it seems some MediaTek-related drivers get enabled in generic arm64 defconfig Jun 10 16:48:30 oh, this one - https://github.com/freedomtan/patches-mainline-x20-96board/blob/4.9-rc1/freedom_defconfig Jun 10 17:22:32 hehe, this defconfig simply makes a console on _all_ uarts *g* Jun 10 17:23:17 (in the defualt cmdline) **** ENDING LOGGING AT Mon Jun 11 03:00:02 2018