09:12 <architt> Hi, can anyone recommend a good Wifi+BT chip that's known to work well with RK3399, and has good upstream support?

09:15 <inode> mmind00: where/who do i submit patches to?

09:18 <inode> mmind00: also, which branch of the mainline kernel are patches expected to be applied to?

09:21 <eballetbo[m]> mmind00: ooi, do you have the display working on Scarlet?

09:59 <inode> maybe i should be asking whether i should be creating a patch against the master branch of linux-next rather than master of linux?

10:29 <nlhowell> can anyone provide hints about whitescreening booting mainline on asus c201 (rk3288)?

10:30 <nlhowell> I have read hints that it is mmc-related, and might be fixed by modifying my dts

10:31 <vagrantc> i've got it booting with the linux-libre-arm-veyron kernel in GNU Guix

10:32 <vagrantc> it sometimes hangs, but at least i see output when it does

10:32 <vagrantc> not that there's any useful error displayed...

10:33 <nlhowell> vagrantc: thanks! i will look there

10:36 <vagrantc> running the OS off of microSD ... and it *seems* to have slightly higher success rate if i leave the microSD unplugged while it boots and guix spits out "waiting for FOO" until inserted.

10:36 <nlhowell> I see

10:37 <vagrantc> tinkered with warm boot vs. cold boot and reboots and such and seems slightly more reliable from a cold boot after it's warmed up a bit... but it's all pretty ad-hoc trial and error and not very systematic

10:38 <vagrantc> fully power it off, but after it was running for a while such that it's still a little warmer than ambient

10:38 <nlhowell> there were some kernel devs interested in mainline support at one time, I remember some mmc-related patches floating around; does anyone know if they lost interest?

11:09 <vagrantc> i think the very patch that fixed it for some people broke it for others, if it's the one i'm remembering

11:13 <nlhowell> are the other arm chromebooks in a similar position?

11:13 <nlhowell> i have a c101-pa (rk3399, google codename gru-bob) I could use, if it doesn't have the same problem

11:16 <vagrantc> i'magine that would be a more capable machine regardless

11:17 <nlhowell> yes, but it would affect how I prioritise it

11:25 <mmind00> inode: after doing "git format-patch -1" you can use scripts/get_maintainer.pl $patchfile to get the list of recipients ... and then "git send-email" to send the patch away

11:26 <mmind00> inode: just take torvalds/master (or linux-next) as base ... special branches as base are only really necessary when you're working on always changing code ... the rk3229 is pretty quiet normally

11:26 <mmind00> eballetbo[m]: yep ... with the Innolux display

11:28 <mmind00> eballetbo[m]: i.e. there are two scarlet variants with displays from either Innolux or Kingdisplay ... Kingdisplay should also be in the kernel now though

11:30 <mmind00> nlhowell: I do regularly boot-test on a veyron-pinky (development model, nfsroot) and more seldom on a veyron-jerry (kernel+rootfs on microsd) ... and at least the pinky booted up to a graphical login prompt recently

11:32 <nlhowell> mmind00: I am on -speedy; any suggestions on how to debug?

11:34 <mmind00> nlhowell: hmm easiest way would be to use the "uart-on-usb-pins" ... aka the soc can disable one usb-port and output the uart2 signals on its D+ and D- pins

11:35 <mmind00> nlhowell: so it would require a serial adapter, a spare usb cable you can cut open and something to connect both

11:35 <nlhowell> well, I have a soldering iron; other things I can acquire

11:35 <nlhowell> > <mmind00> nlhowell: hmm easiest way would be to use the "uart-on-usb-pins" ... aka the soc can disable one usb-port and output the uart2 signals on its D+ and D- pins

11:36 <nlhowell> how do i tell the soc to do that? by hardware?

11:36 <mmind00> nlhowell: https://patchwork.ozlabs.org/patch/573454/

11:37 <mmind00> nlhowell: by adding "rockchip.usb_uart" to the kernel commandline

11:37 <nlhowell> great, thanks :)

11:37 <atopuzov[m]> nlhowell: nlhowell I have good experience running the kernel from urjaman (https://github.com/urjaman/arch-c201) https://urja.dev/linux-c201/ (5.1 also seems to work very well). Whitescreen is just an issue if you have the right drivers compiled in. The hanging part is related to eMMC (there is an explanation in PKGBUILD for linux-c201 which patches deal with eMMC). For a long time I have been running linux-armv7

11:37 <atopuzov[m]> (mainline) from arch from an SD card with a patch to DTB to disable the eMMC (you don't have access to the eMMC) but some of the required drivers for the display are compiled as modules so you still get a flash of white screen.

11:38 <nlhowell> i see

11:40 <atopuzov[m]> I was never able to get debug output from the usb-uart during boot, oddly enough when the system is up It works (eg. I have enabled getty on ttyS2 and I'm able to log in trough it)

11:41 <nlhowell> atopuzov[m]: that doesn't sound encouraging :/

11:42 <nlhowell> atopuzov[m]: do you happen to know which drivers *are* required for display?

11:42 <urjaman> nlhowell: the rockchip PWM driver, the rockchip DRM driver, and the eDP output part of that DRM driver i think

11:43 <atopuzov[m]> nlhowell: https://github.com/SolidHal/PrawnOS/wiki/Using-the-debug-usb-uart-serial-on-the-Asus-C201 but i think you need to reverse the rx/tx from what they have written

11:43 <urjaman> not sure if that list is complete, but i missed the PWM driver once and that caused a white screen i think

11:43 <nlhowell> > <urjaman> nlhowell: the rockchip PWM driver, the rockchip DRM driver, and the eDP output part of that DRM driver i think

11:43 <nlhowell> thanks!

11:44 <urjaman> oh and simple panel

11:47 <urjaman> atopuzov[m]: yeah and currently I'm running the 5.1.1 i have in linux-test (whoops i hadnt pushed the PKGBUILD for that... but now i have) and it seems fine to me

11:48 <urjaman> ... aha apparently arch-arm got to 5.1 12 hours ago, maybe i should update the linux-c201 one again :)

11:50 <urjaman> the testing kernel config is relatively slimmed down to build faster for me (but just so you know, it might not have the driver for your favorite usb widget or whatever enabled if I dont have the same widget :P)

11:50 <atopuzov[m]> urjaman thx! i will try it out. ATM i'm in the process of getting ChromeOS restored so I can get your videwine hack working ;-)

11:50 <nlhowell> lol

11:51 <atopuzov[m]> urjaman: I had to already add support for ecryptfs ;-)

11:51 <urjaman> atopuzov[m]: i think you can just make the recovery USB stick and read it off the rootfs on that

11:53 <urjaman> no need to actually install the ChromeOS

12:07 <atopuzov[m]> urjaman oh nice :)

12:10 <urjaman> chromeos rootfs' have their feature flags "massaged" such that the kernel will refuse to mount them rw, but just mount -o ro is enough to be able to read them from linux

12:10 <urjaman> just if you didnt know already

12:49 <inode> mmind00: thanks