<dr1337>
hi guys, would you happen to know if th rk312x series of chips has a newer u-boot version than 2014?
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-rockchip
dr1337_ has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
nasuga has quit [Ping timeout: 256 seconds]
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stdint has joined #linux-rockchip
<stdint>
dr1337, no
dr1337_ has joined #linux-rockchip
erc has left #linux-rockchip [#linux-rockchip]
AF04FB9290474265 has quit [Ping timeout: 265 seconds]
jkstrick_ has joined #linux-rockchip
jkstrick has quit [Ping timeout: 260 seconds]
AF04FB9290474265 has joined #linux-rockchip
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dr1337_ has joined #linux-rockchip
jkstrick has joined #linux-rockchip
jkstrick_ has quit [Ping timeout: 245 seconds]
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dr1337_ has joined #linux-rockchip
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 265 seconds]
cnxsoft1 is now known as cnxsoft
dr1337_ has joined #linux-rockchip
wadim_ has joined #linux-rockchip
dr1337_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dlezcano has joined #linux-rockchip
dr1337_ has joined #linux-rockchip
dr1337_ has quit [Client Quit]
dlezcano has quit [Ping timeout: 256 seconds]
dlezcano has joined #linux-rockchip
premoboss has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
nighty-- has quit [Quit: Disappears in a puff of smoke]
nighty has quit [Ping timeout: 256 seconds]
<afaerber>
mmind00: hi. I notice that a couple RK3399 options are showing up in v4.9-rc1 - shouldn't they be limited to arm64?
<mmind00>
afaerber: I guess that depends :-) Like the innosilicon usbphy is actually used on non-rk3399 socs as well (like the 32bit 3036 and the rk3228/rk3229) just missing glue and fixups for them
<afaerber>
mmind00: I mainly noticed stuff with RK3399 literally in the name ;)
<mmind00>
afaerber: others like the pcie stuff might probably not have a arm32 life in the future
<afaerber>
config/armv7hl/default:# CONFIG_SND_SOC_RK3399_GRU_SOUND is not set
<afaerber>
config/armv7hl/default:# CONFIG_ARM_RK3399_DMC_DEVFREQ is not set
<mmind00>
afaerber: yeah ok ... if it has 3399 in the name one may want to limit it
<mmind00>
afaerber: although for the gru-sound thing it's merely in name only ... i.e. all the other options in that file also are quite machine-specific
stdint has quit [Ping timeout: 260 seconds]
<wens>
my chromebook still refuses to boot a mainline kernel :(
<phh>
which one?
<phh>
I could boot my c201 with mainline kernel/original chrome os bootloader
<phh>
though I had to drop ramdisk
<wens>
c201
<wens>
i can boot the kernel from arch linux's image
<wens>
w/ original chrome os bootloader
<phh>
what happens when you try to boot it?
<phh>
did you change the kernel config? personly I set every rockchip option to built-in
<wens>
phh: screen goes dark
<phh>
ok, have you got rockchip drm as built-in?
<phh>
(btw i
<wens>
yes
<phh>
(i've tested on 4.8.1/4.8.2)
<wens>
also wondering if my FIT image is to blame , or the signing step :/
<phh>
nope, if it was either of those, you would get BEEP
<phh>
not black screen
<phh>
I'd say you need to enable more stuff from menuconfig
<phh>
perhaps try to get arch linux's defconfig, and use it?
<wens>
yeah, i tried getting a debian kernel to boot, got a beep
<phh>
with debian's ramdisk or without?
<wens>
phh: arch linux's kernel is the chromeos kernel, rebuilt with CONFIG_VT it seems
<wens>
phh: with ramdisk
<phh>
oh
<phh>
ok, so indeed debian kernel + ramdisk + dtb I get beep as well
<phh>
it seems like chromium's coreboot doesn't handle fit >16MB
<wens>
:/
<wens>
the ramdisk itself is close to 16MB
<phh>
i'll try to report that to chrome team
<phh>
yup, that's why I had to make my own zImage with drivers/FS/root builtin
paulk-collins has quit [Quit: Leaving]
<wens>
trying to trim down debian's initrd, getting a white screen now, so that's something
<mmind00>
wens: if you don't see anything in the future, you can also try the usb-uart function, to at least get some sort of output
nighty has joined #linux-rockchip
<phh>
mmind00 oh, what's that? Is there some documentation about it?
<wens>
phh: it's using an USB-UART converter as a console
<mmind00>
phh: more than that ... one of the usb ports can output serial data instead of usb (you get raw serial data and thus still need a uart to usb converter though)
<gen>
ayaka: any chance to have libmali for fbdev instead of x11?
<bertje__>
an1 here who knows why there is no lvds driver yet for rk3288 in mainline?
<ayaka>
gen, I don't have much application
<ayaka>
but the libmali and header files are also offered
<ayaka>
you could write you own
<ayaka>
bertje__, just no one do it
<gen>
ayaka: libmali library requires x11. I want to try running without x11.
<ayaka>
gen, even me doesn't have the source code
<ayaka>
if I have, at lease I could re-build one to you
<bertje__>
@ayaka: what is required to add rockchip_lvds driver to mainline and make it work? just copy the driver code and add it to Kconfig/Makefiles etc? or more complicated than that ?
<ayaka>
bertje__, try, build and fix
<ayaka>
I don't have a lvds panel so I can't comment on it
<bertje__>
@ayaka: ok, so start with adding rockchip_lvds first, correct?
<ayaka>
yes
<bertje__>
@gen: what about using EGL?
<ayaka>
recently I am porting EGL
<ayaka>
porting mali GPU driver I mean
<bertje__>
@ayaka: I thought about just using release-4.4 branch of rockchip repo where lvds already works.. but problem is that usb is still broken
<bertje__>
@ayaka: meanwhile you have usb fixed on your branch but no lvds there ...
<ayaka>
bertje__, the usb fixup for 4.4 would be merged soon
<ayaka>
you could backport it
<ayaka>
as I have, still under reviewing
<gen>
bertje__: yes, I am using EGL
<bertje__>
@ayaka: ok, basically take your branch from where you branched off release-4.4 and put it on top of release-4.4?
<bertje__>
@gen: and it won't work without x11?
<bertje__>
@gen: i thought the point of EGL was to not need x11
<ayaka>
bertje__, no, you need to revert a patch
<gen>
bertje__: it won't work. libmali is configured for x11 so it needs x11 libraries.
<bertje__>
@gen: ok, and it requires x11 to be running as well?
<ayaka>
I don't know the internal of ARM mali, the mali 400 can't be rename or it would crashed
<ayaka>
there is too much strange settings in arm mali
<bertje__>
@ayaka: which patch needs to be reverted?
<gen>
bertje__: maybe. but I don't want to rely on x11 if I don't use it.
<ayaka>
I forget
<ayaka>
but that patch would disable the suspend of usb
<gen>
bertje__: it should be simple for someone to build libmali for fbdev if they have the code.
<bertje__>
@gen: right, but that is user space and it's closed source?
<gen>
bertje__: yes
<wadim_>
you can download a libmali for fbdev on the arm website
<wadim_>
for the T760
<bertje__>
@gen: that's unfortunate.. i was interested in EGL too but without running x11... i don't care if it links with x11 libs, but i dont' like x11 running
<gen>
wadim_: I was thinking for utgard
<bertje__>
@ayaka: do you mean there was a patch applied to release-4.4 branch that disables the suspend of usb, and I have to reverse the patch to make usb work on this branch?
<wadim_>
you can ask rockchip, maybe they will compile a libmali for you
<ayaka>
yes, and it is easy to fin it
<bertje__>
@ayaka: so all problems with usb were caused because of this patch that was applied?
<ayaka>
no
<bertje__>
@ayaka: i'm searching commit log for release-4.4