<babbabbage>
and I was wondering if anyone is working on a libreboot port for the radxa rock/rock 2?
ssvb has joined #linux-rockchip
aep has joined #linux-rockchip
hipboi has joined #linux-rockchip
markm has joined #linux-rockchip
robogoat has joined #linux-rockchip
<sjoerd>
mmind00_: random wonderings, any ideas of what might break linux booting after loading u-boot over usb via maskrom mode ?
<mmind00_>
sjoerd: how far does it get? Anything at all?
<sjoerd>
mmind00_: no output at all,from the kernel though i didn't try with a debug serial thing (so i wouldn't have output before the fdt etc was setup)
<sjoerd>
babbabbage: if you're looking for an upstream/open-source bootloader u-boot works. Don't know anything about coreboot tbh
<mmind00_>
sjoerd: but uboot did actually load the kernel image from a card ... the only spontanous guess would be the maskrom setting some clock differently in the usb vs. mmc case
<sjoerd>
mmind00_: yes, uboot spl can e.g. load u-boot second stage from an sd card, pull the kernle of the network or local storage etc etc
<sjoerd>
just the actual booting of the kernel is not happy
<sjoerd>
but yeah could be mask rom turned a pd/clock of that the kernel is not turning back on in early boot i guess
* sjoerd
should dump the settings
<sjoerd>
the other ponderings i had was that e.g. an interrupt or exception happens during early kernel boot the kernel is not ready to handle yet
<sjoerd>
but it's all guesses at this point unfortunately
<mmind00_>
sjoerd: you could look via some jtag debugger if you like the pain I guess [and have the experience to do that ... the only thing I ever did with jtag was stopping and starting a s3c2416 :-) ]
<sjoerd>
not enoughfree time unfortunately
<sjoerd>
this is realy hobby stuff atm
vickycq has quit [Quit: WeeChat 1.0.1]
vickycq has joined #linux-rockchip
AstralixNB has quit [Quit: Leaving.]
ckeepax has joined #linux-rockchip
lerc has quit [Ping timeout: 244 seconds]
GriefNorth has joined #linux-rockchip
ckeepax has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
ckeepax has joined #linux-rockchip
lerc has joined #linux-rockchip
babbabbage has quit [Quit: Leaving]
lerc has quit [Read error: Connection reset by peer]
lerc has joined #linux-rockchip
lerc has quit [Remote host closed the connection]
lerc has joined #linux-rockchip
jas-hacks has joined #linux-rockchip
lerc has quit [Ping timeout: 250 seconds]
VargaD has quit [Ping timeout: 260 seconds]
VargaD has joined #linux-rockchip
premoboss has joined #linux-rockchip
lerc has joined #linux-rockchip
naobsd has quit [Remote host closed the connection]
naobsd has joined #linux-rockchip
cristian_c has joined #linux-rockchip
aep has quit [Ping timeout: 245 seconds]
aep has joined #linux-rockchip
<pulser>
mmind00_: I shall indeed give it a test - was away on business, but I now have some time to play :)
<pulser>
for now, in case it is of interest to you, I am using MATE desktop environment, on archlinux arm, but with Compiz for accelerated (composited) window manager - works rather nicely, and less crashy than kde plasma5
<mmind00_>
pulser: hehe
<pulser>
hmm, I am sure I was going to ask you something about that/this though
<pulser>
ah OK yes - I had found kde didn't work with accel without me reverting to the ChromeOS kernel - will be interesting to see if analogix helps in any way there
<pulser>
(I didnt' try MATE, but I shall try it on your new kernel)
<pulser>
and RE sound, I need to look into that, as audio does not work on somewhat-stable, but I had it working on the ChromeOS kernel (well, arch's package)
<mmind00_>
pulser: yep, as I said, fried my speakers a bit when I tried once ... sjoerd had the thought that a ucm profile might be missing
<pulser>
yes - I added the profile
<pulser>
the issue appears to be somewhat kernel related (I will make a PKGBUILD some time for the ucm profile, if amstan didn't already do so)
<pulser>
we both had planned to do it
<pulser>
I am comfortable enough that if you use the UCM, it appears relatively safe
<mmind00_>
does anything make any sound at all?
<pulser>
on the ChromeOS kernel, I had sound working fine
<pulser>
I need to look back at yours having worked it out there :)
<mmind00_>
I meant on mainline ;-)
<pulser>
yeah - I shall investigate, but I never had it work so far
<pulser>
I did notice differences in what was being "reported" as available by pulseaudio - at a guess, I thought the headphone detection polarity was wrong
<mmind00_>
me neither ... only sometimes a little plop and then a cloud of bad smell ;-)
<pulser>
as I noticed *removing* the headphones would open VLC (or whatever was registered as media app)
<pulser>
:(
<pulser>
so it got me wondering if something was set to the wrong polarity in the dts, as that would possibly explain it routing the audio the wrong way (to headphone or similar)
<amstan>
the dts is pretty similar to the chromeos one though
<amstan>
mmind00_: i could probably try getting it all going on a danger board with mainline
<amstan>
no minnies will have to get sacrificed that way
<amstan>
and i can also scope things
<mmind00_>
amstan: that would be great :-D
<cristian_c>
hello
<cristian_c>
I'd like to add a new resolution size
<pulser>
would be nice, amstan :) I did compare DTS and saw no issues - it was just something that "seemed to fit" in my mind as an explanation, on acocunt of the removing headphone triggering VLC, rather than inserting
<cristian_c>
how could I add a new resolution not listed in 'modes' file?
<cristian_c>
Any ideas?
ssvb has quit [Ping timeout: 260 seconds]
gb_master has joined #linux-rockchip
ssvb has joined #linux-rockchip
ssvb has quit [Ping timeout: 260 seconds]
gb_master has quit [Quit: Leaving]
jas-hacks has left #linux-rockchip [#linux-rockchip]
ssvb has joined #linux-rockchip
<pulser>
mmind00_: OK interesting - using compiz, I get errors in dmesg as follows using your kernel (compiz crashes or doesn't load)
<pulser>
rockchip-dp ff970000.dp: Link Training Clock Recovery Success
<pulser>
rockchip-dp ff970000.dp: Link Training success!
<pulser>
rockchip-dp ff970000.dp: Timeout of video streamclk ok
<pulser>
rockchip-dp ff970000.dp: unable to config video
<mmind00_>
pulser: I see these messages too, but edp output generally still does work
<mmind00_>
do you have output at all?
<pulser>
OK - this is on the internal screen
<pulser>
I get "output" yes, I get the graphical login screen
<pulser>
I briefly see a top bar appear - going to disable compiz to rule that out
<mmind00_>
then I don't think this should be related to the new edp ... i.e. we're only changing the output encoder, not anything to creating graphical images
<pulser>
OK, in which case it will be accel "not working right" for compositing on mainline
<pulser>
so I will switch to marco as a WM and it should "work"
<pulser>
confirmed - I get output when I use a non-compositing WM
<pulser>
interestingly, I get an "accurate" battery life prediction from mainline, and *not* from the chromeOS kernel (yours says 13h45, chromeOS says maybe 2 hours or so...) - yours is the one that's right
ssvb has quit [Ping timeout: 250 seconds]
lerc has quit [Ping timeout: 245 seconds]
<pulser>
I am seeing messages about EDID bad checksum (which might be related to the edp handling stuff), but the output works fine
<pulser>
RE sound, I only see "Dummy output"; not the actual working output (in dmesg, I see some messages from alsa-ucm complaining of no sink and source at high: Headphone (and Mic), and tat it can't match media roles for modifier Speaker Swap Mode
lerc has joined #linux-rockchip
ckeepax has quit [Ping timeout: 245 seconds]
ssvb has joined #linux-rockchip
gb_master has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 260 seconds]
gb_master has quit [Quit: Leaving]
<pulser>
mmind00_: got sound working on chromeOS kernel - ignore that message there, what appears to be an issue is this one: "max98090 2-0010: ASoC: Can't set HiFi hw params: -22"
<pulser>
even though the sound device "shows up", and looks normal otherwise, it doesn't seem to make any actual sound :)
lerc has quit [Ping timeout: 260 seconds]
markm has quit [Ping timeout: 260 seconds]
markm has joined #linux-rockchip
ckeepax has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
ckeepax has quit [Ping timeout: 245 seconds]
<norris>
mmind00_: your somewhat-stable brings up graphics/UI fine on jaq
<norris>
w/ eDP
<mmind00_>
norris: thanks for testing ... so we'll be staying on the mainline-targetted code and hope that the last quirks will get resolved and it can really land
<norris>
mmind00_: what quirks, exactly? just the forced-hpd stuff?
<mmind00_>
norris: mainly the failing hotplug and one lockdep warning, I've already told Yakir about this, but if time permits will look at this myself too
<mmind00_>
norris: especially the hotplug only seems to fail on initial bringup ... later readings of the plug-status seem to work just fine
<norris>
mmind00_: ok. wasn't sure if anyone was looking at the hotplug issues, or if yakir was really going with that hack...
masked has quit [Changing host]
masked has joined #linux-rockchip
<mmind00_>
norris: forcing hotplug detection is actually a feature of the IP ... and at least pinky seems to need it, but the others would hopefully be able work normally
<norris>
mmind00_: right, the DT property isn't entirely a hack, but its use on all boards seems to be
<mmind00_>
norris: you could try disabling it and see what happens
<norris>
mmind00_: already tried; panel doesn't get registered
<mmind00_>
norris: and if I remember correctly dianders said that most all except pinky should support regular hotplug detection, so the driver seems to be doing something strange