01:28 <ullbeking> 18:27 <robmur01> TBH I'm surprised there isn't a networking hat for NanoPi M4 with PoE and extra PCIe network port(s)...

01:28 <ullbeking> r1, r2, and r4 seem to be the models with > 1 NIC

01:40 <vagrantc> what kernel modules does the pinebook-pro need beyond CONFIG_BATTERY_CW2015 for battery support?

17:15 <TomTheDragon> going to give armbian with a mainline kernel another shot on rockpi4, previously it wouldn't bring the display up on startup. anyone have that issue when using HDMI->VGA adapter?

17:22 <robmur01> no display is a common symptom of pretty much anything that isn't a standard HDTV mode - the HDMI driver is very aggressive at rejecting modes that don't match the set of exact pixel/TMDS clock rates it knows about

17:25 <TomTheDragon> robmur01: is there a way of making the driver a little less... persnickety? or forcing a mode on boot?

17:26 <TomTheDragon> because not handling 1024x768@60 (or even 640x480)... is kind of seeming like a glaring issue

17:26 <TomTheDragon> especially when the rockchip driver works just fine

17:28 <robmur01> there have been attempts, e.g. https://lore.kernel.org/dri-devel/20200922203107.2932-1-vicencb@gmail.com/

17:29 <robmur01> the downstream kernel just has bigger lists of hard-coded numbers ;)

17:31 <TomTheDragon> so that's the only difference? not hard to add a bunch of hard-coded numbers but probably pretty hard to get upstrewamed

17:34 <robmur01> depending on how flexible your adapter/monitor is, another thing would be to try overriding the EDID to advertise the mode you want with an amenable clock rate, provided your hardware can actually handle it

17:34 <TomTheDragon> main reason I want upstream kernel is for the panfrost driver - having a full GL means being able to run most 3d apps (Firefox WebGL, etc)

17:34 <TomTheDragon> robmur01: have heard there's a way to modify the edid through some kind of i2c, but haven't figured it out. and don't really want to brick my adapters.

17:35 <TomTheDragon> is there a list of supported modelines somewhere?

17:39 <robmur01> not as such - the magic tables are up the top of dw_hdmi-rockchip.c, but beyond standard VESA modes clock rates only mean clock rates ;)

17:41 <TomTheDragon> hmm

17:42 <TomTheDragon> pretty sure this monitor/adapter supports most of the standard VESA modes though

17:43 <robmur01> FWIW overriding the EDID is a pure software thing - I think there might be both command-line and sysfs methods - it's just a question of how picky the receiver/scaler/whatever on the other end is

17:44 <robmur01> (in terms of whether it'll be able to hold sync and display something or just give up)

17:45 <TomTheDragon> right. would be nice if I had some way of debugging what signal, if any at all, is being sent.

17:48 <robmur01> IIRC from testing the original RK3328 display patches, some of the standard modes do happen to match up, e.g. I think 800x600 was OK (at least on my old Iiyama)

17:49 <robmur01> one of the drm_debug flags will let you see which modes were found and whether they were pruned or not

17:50 <robmur01> DRM_UT_KMS (0x4)

17:52 <TomTheDragon> ah, thanks.

17:57 <TomTheDragon> I take it that requires a complete kernel recompile to actually enable the debugging?

18:04 <robmur01> it's usually just a module parameter to drm - not sure if it even can be compiled out completely

23:35 <westernsemico> Has anybody had any luck with uboot on rk3399-gru-kevin (the Samsung Chromebook Plus)?

23:35 <westernsemico> I tried https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip

23:35 <westernsemico> Communication with the crosec over SPI is flaky... didn't work at first, enabled some debugging printouts and it worked a bit (enough to turn on the backlight and recognize the keyboard), then the cros_ec_spi got stuck again

23:36 <westernsemico> emmc works, which is the main reason I'm interested in it (currently using coreboot but I have to flash the kernel into SPI because coreboot on kevin-gru has no support for any other storage)

23:37 <westernsemico> putting the kernel in SPI flash is problematic, because there's only (barely) room for one kernel, so kernel upgrades have no fallback... if I flash a bad kernel I have to open the case and hunt down an SPI clip to unbrick the laptop. Not very mobile.

23:38 <westernsemico> anyways the uboot fork I linked above is able to read a ~20M uncompressed kernel image off of emmc (awesome!) but attempting to booti/bootm it prints the final uboot message "loading the kernel" (or something similar) and then gets stuck.

23:40 <westernsemico> I've given up hope on petitboot-style kexec-loading because of the screen-flicker problem, which appears to be totally unique to this particular device (gru-kevin)... that issue doesn't seem to have attracted the attention of anybody with enough signed NDAs to fix it, so I think kexec on gru-kevin is just permanently broken.

23:42 <westernsemico> Since coreboot (on gru-kevin) and kevinboot can't access mass storage, and linux-as-a-bootloader-via-kexec causes screen flashing in the post-kexec kernel, the only remaining option appears to be uboot.

23:44 <westernsemico> Unfortunately the cros_ec_spi.c in uboot appears to have serious robustness issues. Comparing it to the same code in the linux kernel shows that there are a ton of error/edge-case checks missing from the one in uboot. It probably works on a few specific devices with a few specific versions of the EC firmware.

23:44 <westernsemico> Ok, sorry about the monologue, but that's where things stand.

23:45 <mps> westernsemico: np, I tried long ago but without luck

23:49 <mps> I have to find time to try to fix emmc crash after resume from suspend-to-ram

23:49 <westernsemico> If there has been any further work on this, or if somebody (with credible credentials) wants to work on this for a bounty, please contact adam at <my nick> dot com. The bounty deliverable would be, basically, "readable patches to uboot which allow it to load a linux kernel from emmc on rk3399-gru-kevin, and also allow it to communicate robustly with cros_ec_spi so the keyboard doesn't get

23:49 <westernsemico> stuck shortly after booting". I can escrow the bounty with an independent third party if desired.

23:49 <westernsemico> mps, wow, thanks for replying!

23:50 <westernsemico> mps, I have been using s2ram for the last 1.5yrs on my gru-kevin (it is my daily driver) and it is rock solid. Never any emmc crashing.

23:50 <westernsemico> Have you tried different versions of the ATF? I found that s2ram is EXTREMELY sensitive to which one you use.

23:50 <mps> westernsemico: what kernel you use

23:50 <westernsemico> Let me go find the version I am using.

23:50 <westernsemico> mps, I have been using eballetbo's patches against various kernels from 5.6 up through 5.10.10, all with zero problems.

23:50 <westernsemico> I flash coreboot+kernel+initramfs into the SPI and boot from that.

23:51 <mps> hmm, I tried with these patches. but not much

23:51 <westernsemico> what are you using as your bootloader? the bootloader supplies ATF, and s2ram is implemented 90% in ATF.

23:51 <mps> I don't have SPI flasher device so I'm out of this option

23:52 <mps> I use just kernel partition

23:52 <westernsemico> Oh yeah, that will never work. You need to replace bootloader, and it is in the SPI flash.

23:53 <westernsemico> You know it's not hard to flash the SPI on gru-kevin, right? Remove seven screws from the back of the case, pop off the back panel, and use an SOP-8 clip. It's not something you want to do regularly, but it isn't hard to do it once after you first buy the laptop. After that (once you've reflashed with a clip) you can do further reflashes from software, on the laptop.

23:53 <westernsemico> For future reference, to get s2ram working you **MUST** use exactly this version of the Arm Trusted Framework (ATF): https://github.com/ARM-software/arm-trusted-firmware/commit/3cb74922d02bbf64c8dbcaae7093f7b94d72c948

23:53 <mps> but I didn't had emmc issues with chromeos kernels, 4.4.x iirc

23:54 <westernsemico> The ATF is bundled into the bootloader, which is always taken from SPI flash.

23:54 <westernsemico> ChromeOS kernels are derived from linux, but very very different from linux.

23:55 <mps> yes, I know, I built them locally and dd-ed to partition

23:55 <westernsemico> ChromeOS developers have deadlines to hit in terms of being able to ship working laptops, so they often have to commit stuff that isn't up to the quality standards of the mainline kernel. The stuff that ends up in mainline gets there slower, but is of higher quality and maintainability. Note that often the same people do both (the ChromeOS and mainline commits) but simply are given a lot

23:55 <mps> actually I think to hack mmc driver to fix this

23:55 <westernsemico> more time and less deadline pressure for the mainline stuff.

23:56 <mps> but never find enough time

23:57 <westernsemico> Personally I think that using an SPI clip to reflash (once) is less effort and less risk than messing around with the emmc driver. I wouldn't want my storage to get corrupted if I messed up the hack.

23:57 <mps> I reported few bugs to kernel devs but just one is fixed

23:57 <westernsemico> Hey, you've had better luck than me. I have given up on the flashing-screen-after-kexec bug ever getting fixed.

23:58 <westernsemico> I think kexec on arm64 is basically considered to be unsupported.

23:58 <mps> I don't have big 'pressure', it works quite fine with ssd disk over usb

23:58 <westernsemico> Even with irqchip.gicv3_nolpi=1

23:59 <westernsemico> mps, yeah, but it's a laptop... if your root filesystem is on a USB device you can't really disconnect the device... doesn't that make your laptop a lot more awkward to put in a backpack or briefcase?

23:59 <westernsemico> Plus I worry about those USB-C connectors breaking.