ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
indy has quit [Ping timeout: 260 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
stikonas has quit [Remote host closed the connection]
indy has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
<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)...
<ullbeking> r1, r2, and r4 seem to be the models with > 1 NIC
<vagrantc> what kernel modules does the pinebook-pro need beyond CONFIG_BATTERY_CW2015 for battery support?
kaspter has joined #linux-rockchip
vstehle has quit [Ping timeout: 240 seconds]
field^Mop has quit [Ping timeout: 265 seconds]
chewitt_ has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
kevery has quit [Quit: kevery]
shailangsa has quit [Ping timeout: 246 seconds]
chewitt has joined #linux-rockchip
chewitt_ has quit [Ping timeout: 256 seconds]
kevery has joined #linux-rockchip
shailangsa has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
vagrantc has quit [Quit: leaving]
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-rockchip
vstehle has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
chewitt has quit [Quit: Adios!]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #linux-rockchip
ldevulder__ is now known as ldevulder
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
kevery1 is now known as kevery
matthias_bgg has joined #linux-rockchip
kaspter has quit [Ping timeout: 265 seconds]
camus1 has joined #linux-rockchip
camus1 is now known as kaspter
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
robmur01 has joined #linux-rockchip
warpme_ has joined #linux-rockchip
stikonas has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
psydruid has quit [Quit: Bridge terminating on SIGTERM]
Ke has quit [Quit: Bridge terminating on SIGTERM]
nergzd723 has quit [Quit: Bridge terminating on SIGTERM]
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #linux-rockchip
psydruid has joined #linux-rockchip
midnight has quit [Ping timeout: 240 seconds]
midnight has joined #linux-rockchip
field^Mop has joined #linux-rockchip
lopsided98 has quit [Ping timeout: 260 seconds]
nergzd723 has joined #linux-rockchip
Ke has joined #linux-rockchip
lopsided98 has joined #linux-rockchip
archetech has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
stikonas has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
stikonas has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
chewitt has joined #linux-rockchip
shailangsa has quit [Ping timeout: 260 seconds]
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 260 seconds]
sssb54 has joined #linux-rockchip
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
kevery1 has joined #linux-rockchip
shailangsa has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
shailangsa has quit [Ping timeout: 272 seconds]
shailangsa has joined #linux-rockchip
vagrantc has joined #linux-rockchip
<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?
matthias_bgg has quit [Ping timeout: 244 seconds]
ldevulder has joined #linux-rockchip
ldevulder__ has joined #linux-rockchip
<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
ldevulder_ has quit [Ping timeout: 264 seconds]
ldevulder has quit [Ping timeout: 256 seconds]
<TomTheDragon> robmur01: is there a way of making the driver a little less... persnickety? or forcing a mode on boot?
<TomTheDragon> because not handling 1024x768@60 (or even 640x480)... is kind of seeming like a glaring issue
<TomTheDragon> especially when the rockchip driver works just fine
ldevulder__ has quit [Remote host closed the connection]
ldevulder__ has joined #linux-rockchip
<robmur01> the downstream kernel just has bigger lists of hard-coded numbers ;)
<TomTheDragon> so that's the only difference? not hard to add a bunch of hard-coded numbers but probably pretty hard to get upstrewamed
<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
<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)
<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.
<TomTheDragon> is there a list of supported modelines somewhere?
<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 ;)
<TomTheDragon> hmm
<TomTheDragon> pretty sure this monitor/adapter supports most of the standard VESA modes though
<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
ldevulder__ is now known as ldevulder
<robmur01> (in terms of whether it'll be able to hold sync and display something or just give up)
<TomTheDragon> right. would be nice if I had some way of debugging what signal, if any at all, is being sent.
<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)
<robmur01> one of the drm_debug flags will let you see which modes were found and whether they were pruned or not
<robmur01> DRM_UT_KMS (0x4)
<TomTheDragon> ah, thanks.
<TomTheDragon> I take it that requires a complete kernel recompile to actually enable the debugging?
<robmur01> it's usually just a module parameter to drm - not sure if it even can be compiled out completely
ldevulder has quit [Quit: Leaving]
chewitt has quit [Quit: Zzz..]
archetech has quit [Quit: Konversation terminated!]
robmur01 has quit [Quit: Leaving]
alpernebbi has quit [Quit: alpernebbi]
macc24 has quit [Ping timeout: 240 seconds]
macc24 has joined #linux-rockchip
macc24 has quit [Ping timeout: 265 seconds]
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
mraynal has quit [Quit: WeeChat 3.0]
westernsemico has joined #linux-rockchip
<westernsemico> Has anybody had any luck with uboot on rk3399-gru-kevin (the Samsung Chromebook Plus)?
<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
mraynal has joined #linux-rockchip
<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)
<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.
<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.
<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.
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
<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.
<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.
<westernsemico> Ok, sorry about the monologue, but that's where things stand.
<mps> westernsemico: np, I tried long ago but without luck
<mps> I have to find time to try to fix emmc crash after resume from suspend-to-ram
<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
<westernsemico> stuck shortly after booting". I can escrow the bounty with an independent third party if desired.
<westernsemico> mps, wow, thanks for replying!
<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.
<westernsemico> Have you tried different versions of the ATF? I found that s2ram is EXTREMELY sensitive to which one you use.
<mps> westernsemico: what kernel you use
<westernsemico> Let me go find the version I am using.
<westernsemico> mps, I have been using eballetbo's patches against various kernels from 5.6 up through 5.10.10, all with zero problems.
<westernsemico> I flash coreboot+kernel+initramfs into the SPI and boot from that.
<mps> hmm, I tried with these patches. but not much
<westernsemico> what are you using as your bootloader? the bootloader supplies ATF, and s2ram is implemented 90% in ATF.
<mps> I don't have SPI flasher device so I'm out of this option
<mps> I use just kernel partition
<westernsemico> Oh yeah, that will never work. You need to replace bootloader, and it is in the SPI flash.
<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.
<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
<mps> but I didn't had emmc issues with chromeos kernels, 4.4.x iirc
<westernsemico> The ATF is bundled into the bootloader, which is always taken from SPI flash.
<westernsemico> ChromeOS kernels are derived from linux, but very very different from linux.
<mps> yes, I know, I built them locally and dd-ed to partition
<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
<mps> actually I think to hack mmc driver to fix this
<westernsemico> more time and less deadline pressure for the mainline stuff.
<mps> but never find enough time
<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.
<mps> I reported few bugs to kernel devs but just one is fixed
<westernsemico> Hey, you've had better luck than me. I have given up on the flashing-screen-after-kexec bug ever getting fixed.
<westernsemico> I think kexec on arm64 is basically considered to be unsupported.
<mps> I don't have big 'pressure', it works quite fine with ssd disk over usb
<westernsemico> Even with irqchip.gicv3_nolpi=1
<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?
<westernsemico> Plus I worry about those USB-C connectors breaking.