02:59 <alyssa> Mostly because if there's doubt, the bug is kernels fault, by definition

03:02 <alyssa> ...Now my kernel isn't even booting

03:02 <alyssa> 2 steps forward.

03:06 <alyssa> Last time I had this because of module stuff ... now I have no modules in the kernel, oy

03:23 <alyssa> Linux, darling, why are we recompiling.. everything?

03:46 <alyssa> Hit Ctrl-U, screen goes black immediately, never turns back on, no I/O per the USB light... grr

09:01 <CrystalGamma[m]> hi everyone, I want to port coreboot to the RK3399-based RockPro64, but I'm currently stuck on DRAM initialization … coreboot (and U-Boot for that matter) currently consumes an array of opaque data written to memory controller MMIO space, which differs between DDR3 and LPDDR4 and between frequencies. Apparently my board uses LPDDR4 though, for which I haven't been able to find any corresponding initializatio

09:01 <CrystalGamma[m]> parameters. Does anyone of you know how to get that data beyond reverse engineering the rockchip DDR blob? (which I am totally willing to do if necessary, but might need a partner that writes a clean-room reimplementation for upstreaming)

09:07 <ccaione> @alyssa same on my C201 (rk3288) with the latest mainline. Black screen and no activity.

09:54 <mmind00> ccaione: hmm at least on 5.2-rc1 I did get output when testing on my farm (rk3399-kevin + rk3288-pinky + but with nfsroot)

09:55 <ccaione> mmind00: no such luck. Are you using multi_v7_defconfig ?

09:56 <mmind00> ccaione: interesting question, config is based on multi_v7 but then "evolves" during builds by just manually enabling options I need over time

09:57 <ccaione> mmind00: do you mind sharing it somewhere? I'll test it right away :)

09:59 <mmind00> ccaione: from make savedefconfig: https://bpaste.net/show/24eb7ed84879 (5.2-rc2, but with camera stuff I'm currently working on)

10:00 <ccaione> thanks. Trying it ..

10:00 <mmind00> ccaione: and at least kevin just came up with it (kernel with initramfs in the FIT image)

10:00 <mmind00> so graphics is a module there

10:01 <ccaione> FWIW I'm using the archlinux ARM rootfs on SD/USB, no initramfs + `console=ttyS2,115200n8 earlyprintk=ttyS2,115200n8 console=tty1 init=/sbin/init root=PARTUUID=%U/PARTNROFF=1 rootwait rw noinitrd`

10:19 <ccaione> @mmind00 no luck. I need to spend some more time on this. Otherwise could you please share you `kpart` file for the pinky? The C201 should be speedy but I'm confident that they should be similar enough

10:20 <mmind00> ccaione: I'm doing tftp + nfsroot on my boardfarm, so no kpart here

10:21 <mmind00> ccaione: one thing I remember running into in the past is kernel image size

10:21 <mmind00> ccaione: so you might want to check how big your kernel image actually is (and possibly switch to xz or whatever)

10:21 <ccaione> good hint. The other option is kill depthcharge and just try to use u-boot

10:44 <EmilKarlson> so far alsa has only worked for me with aplay

10:44 <EmilKarlson> and speaker-test

14:39 <alyssa> mmind00: Good to know it's not entirely broken then :)

14:44 <mmind00> alyssa: yep, though my setup is not thaat helpful to people actually using their devices productively ;-)

14:44 <alyssa> mmind00: Any idea on what could've changed, though?

14:45 <alyssa> Linux next 20190509 is working. 20190531 is not. Not in the mood to bisect. :P

14:46 <mmind00> alyssa: at least good to know that the gap between good-bad is not that big ... can you check your kernel image size for both? I remember coreboot having issues if the image is over some size limit

14:48 <alyssa> mmind00: It's comparable..

14:48 <alyssa> New one should be a lot smaller, even

14:50 <mmind00> ok, then not the size

17:36 <dianders> @alyssa / @ccaione: you're trying to boot 5.2-rc1 on rk3288? Yeah, no bueno. You need the thermal revert.

17:36 <dianders> $ git log --oneline v5.2-rc1..linux/master -- drivers/thermal/rockchip_thermal.c

17:36 <dianders> 0f5ee062d87e Revert "thermal: rockchip: fix up the tsadc pinctrl setting error"

17:37 <urjaman> did it get into rc3?

17:37 <urjaman> (because i just booted that fine on my C201 :P)

17:37 <dianders> urjaman: yeah, it's in rc3

17:38 <dianders> Ah, trying to read the discussion above closer. Sounds as if it was linuxnext that wasn't booting for folks...

17:42 <urjaman> and i think alyssa was having trouble on RK3399 (if it matters)

17:43 <dianders> Ah. When I boot next-20190603 on rk3288-veyron-jerry I get a use-after-free right away. :-P

18:22 <EmilKarlson> alyssa: you are not talking about the spi crash?

18:23 <EmilKarlson> I am unable to locate the relevant parts of the discussion

19:00 <urjaman> https://urja.dev/veyron-spi.txt does this look like the SPI thing or is this something different?

19:00 <urjaman> (not fun losing the keyboard mid-type ... luckily i could ssh in to get that log)

19:01 <EmilKarlson> urjaman: yes, that's it

19:02 <EmilKarlson> you can revert c9ba7a16d0f1d2b1e70d47296eca5f612c753825, if you are in a hurry, will be reverted later on

19:04 <EmilKarlson> I am amazed people can miss this, as about 90% of channel content is me flooding about the issue to the extent I am limited by my vdsl2 connection

19:07 <EmilKarlson> I guess the problem is that I am not addressing all people individually

19:08 <urjaman> i'm usually not reading the chatter here if it's longer than a screenful (and i wasnt looking at kernel things for a couple of weeks)

19:11 <urjaman> (anyways i did the revert so nobody else hits it from my testing branch :P)

19:52 <alyssa> dianders: RK3399, but maybe also applies

19:52 <alyssa> EmilKarlson: SPI crash?

19:54 <dianders> alyssa: I've seen the SPI crash for sure. I never spent too much time debugging but I was under the impression that it was understood.

19:54 <urjaman> nobody reads anything here it seems :D

19:54 <dianders> In general when I see linuxnext crash I don't spent too much time debugging since I could spent all my days debugging then. :-P

19:55 <dianders> I skim things here sometimes, but it can be hard to follow a given conversation thread. ...or maybe my brain is just too feeble...

20:08 <urjaman> oh btw dianders ... just saying, i wouldnt mind commit a5c0fa44e9c18223a6651f2697e97b223a693c3a (in 5.2) ending up in chromeos 4.19 before it ends up on my other C201 ...

20:09 <dianders> urjaman: Ah, that was on my list to look at. I'll double-check with seanpaul but from the description I don't see why we couldn't pick it.

20:10 <dianders> urjaman: do you have any sample image where it's easy to see the banding?

20:10 <urjaman> http://www.lagom.nl/lcd-test/gradient.php has a pretty good gradient

20:11 <urjaman> that's what i used as my quick test

20:15 <urjaman> http://www.lagom.nl/lcd-test/img/gradient-h.png (if you want to just grab the image :P)

20:43 <dianders> urjaman: wow, gradients look _way_ better.

20:49 <urjaman> yeah i know :), and thanks for all the gerrit work :P (wasnt expecting that many emails that quickly)

20:57 <dianders> urjaman: thanks for reminding me about the commit (and posting it). Hope the emails aren't too spammy. It seemed like you were interested in it so I CCed you on the bug. ...and gerrit CCs you automatically.

20:58 <urjaman> yeah no problem

22:41 <alyssa> dianders: What tree do you recommend I track? torvalds/linux?

22:41 <alyssa> I'm not wed to the most recent, as long as the Panfrost driver is there (and it was merged for 5.2 afaik)

22:42 <dianders> alyssa: I'm not sure. Torvalds is definitely more stable in general. It doesn't hurt to try linuxnext but just don't be terribly surprised if it doesn't always boot.

22:42 <alyssa> Fair enough :)

22:43 <dianders> You could try "git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git" and that's usually pretty good, but at the moment it doesn't boot for me due to the thermal thing.