<phh>
I don't really know why hdmi is "incomplete"
<phh>
I think GPU has its dts mainlined, and you can build the module externally
<phh>
though for vpu, as for rk3288, it's still a no-go
<LongChair>
do forward ports bring the VPU ?
<LongChair>
ah no
<phh>
it doesn't work
<LongChair>
yeah, doesn't sound good
<phh>
I think rockchip is considering rebasing their 4.4 to 4.14, so hopefully this will get fixed
<LongChair>
yeah i bet this will take some time :)
<LongChair>
this is something different than mmind00 work right ?
<phh>
afaik mmind00 only works on mainline
hanetzer has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
micken has joined #linux-rockchip
<micken>
lo
<micken>
What do I need to do before I can use the CRU softreset?
<micken>
If I use it from linux I can reset various logics
<micken>
If I do it from uboot (and my application) I can't
leah2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 248 seconds]
leah2 has quit [Ping timeout: 240 seconds]
leah2 has joined #linux-rockchip
nighty- has joined #linux-rockchip
leah2 has quit [Ping timeout: 255 seconds]
lurchi_ is now known as lurchi__
sunxi_fan has joined #linux-rockchip
sunxi_fan has quit [Client Quit]
lurchi__ is now known as lurchi_
leah2 has joined #linux-rockchip
leah2 has quit [Ping timeout: 248 seconds]
lurchi_ is now known as lurchi__
<micken>
Forgot to mention it is RK3288
cnxsoft has quit [Quit: cnxsoft]
jelly-home is now known as jelly
lurchi__ is now known as lurchi_
JohnDoe_71Rus has joined #linux-rockchip
sunxi_fan has joined #linux-rockchip
muvlon has quit [Quit: Leaving]
wzyy2 has joined #linux-rockchip
nasuga has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ has quit [Remote host closed the connection]
wzyy2 has quit [Ping timeout: 264 seconds]
<mmind00>
LongChair phh: not sure if this needs an actual answer, but you are correct I really only work on and care about the real mainline kernel
aalm has joined #linux-rockchip
LargePrime has quit [Ping timeout: 248 seconds]
wzyy2 has joined #linux-rockchip
lurchi__ has joined #linux-rockchip
LargePrime has joined #linux-rockchip
vagrantc has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
nasuga has quit [Ping timeout: 248 seconds]
lurchi__ is now known as lurchi_
leah2 has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<phh>
did someone test CEC on mainline?
leah2 has quit [Ping timeout: 240 seconds]
<phh>
I've noticed dw-hdmi-cec landed in mainline with support for rockchip's alignment
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
leah2 has joined #linux-rockchip
<xevious>
I just built a desktop image using rockchip-linux/rk-rootfs-build and it's outputting this error when I try to start X: /usr/lib/xorg/Xorg: symbol lookup error: /usr/lib/xorg/modules/libglamoregl.so: undefined symbol: gbm_bo_ref
<vagrantc>
it seems like support for my veyron-speedy gets a little worse every new kernel version ... from kind of working to "rcu_sched self-detected stall on CPU" ...
<vagrantc>
well, i guess the improvement from 4.13 to 4.14 is that the stalled CPUs do still let me get to an initramfs prompt
<hanetzer>
vagrantc: hey. what bootloader you using?
<vagrantc>
hanetzer: libreboot
<vagrantc>
hanetzer: with depthcharge
<hanetzer>
dammit. if I could get that to work I'd use it, but no joy.
<vagrantc>
hanetzer: you've been working on a u-boot port? how's it going?
<vagrantc>
hanetzer: it's working just enough to be frustrating
<hanetzer>
no idea. unsure if I'm prepareing the spi flash image right.
<vagrantc>
i've got a 4.8 kernel that consistantly detects the eMMC with a patched .dtb ... but applying the same patch on newer versions doesn't work
<vagrantc>
and usb has issues, and wifi hangs the system
<vagrantc>
but some usb things work, like this rtl8152 usb adapter
aalm has joined #linux-rockchip
<vagrantc>
my ideal would be able to load u-boot from coreboot/libreboot ... so that i could test u-boot without risking bricking the device
<vagrantc>
or at least, near-term ideal
<hanetzer>
eh. you can restore it with very cheap hardware.
<phh>
vagrantc: afaik there is a reboot command to reboot to maskrom, and afaik, on rk3288 you can chainload u-boot from maskrom
<hanetzer>
phh: maskrom?
<phh>
hanetzer: bootrom?
<phh>
unless it's modified for chromebooks :s
<hanetzer>
ah.
<vagrantc>
which it might be
<vagrantc>
hanetzer: sure, just don't have the hardware on hand, would be nice to get some level of functionality testing before messing with it at that level
<hanetzer>
I've literally no idea whether or not I've prepared the spi flash u-boot image right :P
* vagrantc
wonders about ditching coreboot and switching back to the original firmware
<vagrantc>
and maybe trying to boot linux from that
<vagrantc>
hrm... can't even find that
<Ke>
what makes you think it's about the boot fw?
<vagrantc>
it's just something to try
<vagrantc>
at any rate...
<vagrantc>
apparently, the cpu stalls had something to do with the eMMC ... and after it gave up, it continued to boot
lurchi__ is now known as lurchi_
<vagrantc>
so i can at least boot to rootfs with microSD
<vagrantc>
and still, usb ethernet works fine ... usb wifi brings the machine to a crawl... never understood this
lurchi_ is now known as lurchi__
<mmind00>
vagrantc: might depend on the number of usb interrupts ... dwc2 is notorious for generating heaps of interrupts, so maybe with your usb-wifi there are even more
<mmind00>
vagrantc: and at least on lower cpu frequencies, dwc2 interrupts can easily overload the system
<vagrantc>
oh fun
<vagrantc>
plugging in the usb wifi triggered errors regarding mmcblk2 (the microSD card where the rootfs is)
<vagrantc>
at least it is not crashing to plug in the usb this time
<mmind00>
vagrantc: you might want to look at /proc/interrupts ... or try increasing the minimum scaling rate
<vagrantc>
i didn't have cpufreq running ... just installed cpufrequtils ... seems much more responsive now
lurchi__ is now known as lurchi_
<vagrantc>
and it's actually reading the eMMC fine now ...
<phh>
ok, so from a "standard" rk3288 device *(0xff730094)=0xef08a53c; *(0xff7601b0)=0xfdb9; reboots the device into maskrom, but it doesn't work on chromebook
<vagrantc>
on chromebook hardware, or from a chromebook os?
<vagrantc>
wifi doesn't handle supsend very well, and prevents proper poweroff ... but i *think* running "modprobe -r brcmfmac" and "modprobe brcmfmac" at the right times might be a workaround
<vagrantc>
that means i can actually try using this thing...