<naobsd>
[PATCH] Revert "drm/rockchip: Convert the probe function to the generic drm_of_component_probe()"
<naobsd>
this is what I have to try...
<edolnx>
naobsd, is there a good resource on u-boot? I've used it on some other platforms and it can do wonderful things (like making the kernel easily upgradable for Linux distros) but I'm not familiar with it's ins and outs enough to know how to make it do those things...
<naobsd>
edolnx: please forget about "on some other platforms" until someone make it wonderful on this platform
<edolnx>
naobsd, that was kind of my goal :D
<edolnx>
try to make the u-boot better for linux distros, as an option at least
<naobsd>
edolnx: then, please add rk3368 support to mainline u-boot :)
<naobsd>
reverting drm probe patch _and_ CONFIG_ROCKCHIP_PM_DOMAINS=y are required...
<naobsd>
well
<naobsd>
edolnx: I'm trying linux-next on rk3288
<edolnx>
cool
rory096 is now known as rory-zzz
<naobsd>
I'm just talking about a bug recently introduced in linux-next
<edolnx>
OK, I've created a boot.img using the mkbootimg command, but flashing it to boot and recovery partitions is failing because of a "boot/recovery image sha mismatch". Also, during flashing it's saying "premature end-of-file reached" which makes me think I've done something wrong
<edolnx>
any ideas?
<naobsd>
exact command line you typed please
<naobsd>
please make sure you are using mkbootimg _for rockchip_, not generic one for other platforms.
<naobsd>
what's vmlinuz-4.2.0-0.bpo.1-arm64/initrd.img-4.2.0-0.bpo.1-arm64? is size of boot.img equal or smaller than boot partition defined in parameter?
<edolnx>
That's the stock kernel from Debian 8 (it's a 4.2.0 backport)
<edolnx>
The boot.img I created is smaller than the one which was already on the system (I backed it up)
<edolnx>
mine: 23642112 original: 33554432
<naobsd>
edolnx: well, exact command line please, how did you flash boot.img?
<edolnx>
sudo ../../rkflashtool/rkflashtool w boot < boot.img
<edolnx>
then sudo ../../rkflashtool/rkflashtool w recovery < boot.img
<naobsd>
hm, rk3036/rk312x use different controller...
<naobsd>
I guess it might be better to prepare mainline based repos on github/linux-rockchip/
<naobsd>
current {linux,u-boot}-rockchip (SDK based) might give confusion...
<naobsd>
[ 12.513568] rockchip-drm display-subsystem: No connectors reported connected with modes
<naobsd>
oops
<naobsd>
I have to find standard HDMI display...
<sjoerd>
naobsd: yeah hopefully the linux-rockchip repo and wiki can start driving folks twoards mainline things ;)
<pulser>
naobsd: just a quick question - which regression were you trying to resolve on the latest build? (<naobsd> I'm just talking about a bug recently introduced in linux-next)
<mmind00>
pulser: I think naobsd means either the power-domains being required by the drm-driver or the drm probing issue, that got now reverted
<pulser>
ah OK - I should try that as it will likely fix it on rk3288 as well
<pulser>
thanks :)
<mmind00>
that is rk3288-only actually :-) ... naobsd had issues bringing his drm/kms up, which we were puzzled about ... but I guess that was triggered by the probe-issue, in linux-next
<pulser>
ah right - I don't think we had a probing issue, so good point
<mmind00>
yep ... I got that with my pull from master yesterday and promptly added the revert from Mark
<pulser>
ah right OK
<mmind00>
and a really cool thing, they fixed a display-shift, that I hadn't seen at all until now :-)
<pulser>
ahh yes, I saw that commit
<pulser>
the off-by-1-pixel?
<mmind00>
yep ... on the left you saw the right side shining through
<pulser>
heh, that's a fun little quirk
<pulser>
I didn't actually spot it myself, I saw the commit for the fix and thought "hmmmm... I didn't look very hard"
<pulser>
I really need to set up a direct ssh link from the chromebook to my main PC, so I can "deploy" the kernel to it seamlessly (and use cgpt to give a one-shot boot to my second kernel partition)
<naobsd>
I have to attach standard HDMI monitor to check everything works... but at least drivers are probed and running now with reverting & PM_DOMAINS
<mmind00>
naobsd: that is really great to hear :-D
<naobsd>
should I prepare patch for PM_DOMAINS for 4.4? I don't have so much time... :(
<naobsd>
I don't know when 4.4 window is closed
<mmind00>
I'm still not sure about the pm-domains ... if either we require it, or stuff should be able to run even if the driver is switched off ... will need to look at others for precedence I guess
<naobsd>
sure
<mmind00>
naobsd: merge-window closes this sunday, but of course stuff fixing issues, like with the domains will go in during the fixes-period as well of course
<mmind00>
pulser: re mali not working: looks like the mali dts node actually never got its power-domain reference
<mmind00>
pulser: so it's probably simply just off
<mmind00>
pulser: try adding a "power-domains = <&power RK3288_PD_GPU>;" to the gpu node in rk3288.dtsi
<pulser>
OK - let's give that a shot. I am on your latest somewhat-stable head
<pulser>
interestingly, status = "disabled" in the dtsi - I assume that's not something as simple as it sounds?
<mmind00>
pulser: that's normal ... in the soc-dtsi you set the core nodes and properties and mark everything that might be unused by boards as disabled
<pulser>
ah right - then it can be overridden in the actual board
<pulser>
makes sense then
<mmind00>
pulser: the board file then updates the status for stuff it actually uses
<pulser>
mmind00: interesting, I am getting some eglInitialize() failed error on the es2 stuff. I did a full reinstall though to the SSD finally rather than the SD, and I had this issue last night, but I got rid of it (I thought)
<pulser>
not convinced the change to the devicetree has changed anything - I suspect I need to figure out some missing package for egl
<mmind00>
pulser: I remember seeing that in the past ... but I guess the power-domain addition made the mali core generally work again
<pulser>
yes, that is my guess too - I think this is a userland issue of some kind
<mmind00>
pulser: if you get egl errors, you're probably farther along ... when I tried I got that stuck mali+es2 app also bein stuck
<pulser>
ah right
<pulser>
hmm, this might be an issue
<pulser>
"Looking up vdd-gpu-supply property in node /gpu@ffa30000 failed"
<kapouer>
same thing here - but i'm still trying to figure why i get "drm permission denied"
<pulser>
ah right - I won't panic yet then
<pulser>
what is strange though is that last night I was getting es2_info working, returning stuff about midgard
<pulser>
yet today it was giving me the whole can't initialize egl
<naobsd>
are libs for mali installed properly?
<pulser>
they *should* be, but I am going to double check that ;)
<pulser>
as I did have some weird issues with that last night, and I ended up manually doing it all
<pulser>
OK so it is indeed using /usr/lib/mali for the glx "alternative", and the libs appear to be there fine
<kapouer>
it's weird, either i get aiglx enabled + drm permission denied, or aiglx reverting to swrast...
em|biketron has quit [Ping timeout: 276 seconds]
em|biketron has joined #linux-rockchip
<pulser>
hmm where is your "drm permission denied" coming from (logs wise), kapouer?
<pulser>
oh how I am an idiot... your user account must be a member of "video" group to get mali midgard driver working and loaded (permissions etc) - it worked fine as root
<pulser>
mmind00: btw, in case I missed anything, did you see any changes recently that could affect emmc on boot-up? I get an intermittent (and now constant) issue where I get transfer errors from emmc, that halt the boot. (cmd response 0x900)
<pulser>
I now have working GLES output from the screen thanks to the latest changes on the somewhat-stable branch on the veyron-minnie (rk3288)
<mmind00>
pulser: mmc-tuning ... and you are on minnie [I remember there were problems at some point] ... does removing "mmc-hs200-1_8v" from the emmc node in rk3288-veyron.dtsi help?
<pulser>
yes, I am on minnie - the issue is a bit intermittent, but I shall give it a shot
<pulser>
(BTW, count the above as a "+1, looks good to me" on your suggestion to add the power-domain to the GPU)
<pulser>
the above change shouldn't remove the speed changes, just the power source, from the tuning?
<mmind00>
pulser: great that you have acceleration now :-) ... the gpu node of course must stay in a separate branch, but I'll add the powerdomain there
<pulser>
yes
<pulser>
so thanks for your help there :)
<mmind00>
pulser: removing that option will probably drop the speed changes ... so we'll probably go with a "/delete-property/mmc-hs200-1_8v;" in the minnie dts
<pulser>
right - interesting it appears to have issues with it
<pulser>
I was hoping to get it to work for MOAR SPEED!!! ;)
<pulser>
may need to look into it - it was something about mmc2, but I should really look at the logs properly
<mmind00>
pulser: it will work eventually :-)
<pulser>
heh ;)
<pulser>
but yes, just going to boot the patched kernel and let you know how it works
<pulser>
I will do maybe 20 boots or so and check it's stable
<kapouer>
pulser: in Xorg log, and yes user is a member of video group, but i'm testing it as root.
<naobsd>
oops, sudden reboot on rk3288 can happen while git push/fetch locally :(
<pulser>
mmind00: change seems stable over about 10 or so boots :) thanks
<mmind00>
naobsd: probably overheated ... with current kernels clock<->tsadc init is flaky, so the tsadc cannot influence cpufreq as cooling-device
<mmind00>
pulser: great, I'll package that up into the minnie-dts then
<mmind00>
for now ... and send it upstream therafter
<naobsd>
it's not make -j4 so I thought it will be ok...
<mmind00>
naobsd: probably git is also taxing on the cpu ... maybe even more so when handling kernel gits :-)
<pulser>
great, mmind00 :)
<pulser>
I really need to test it on HDMI output - still not managed to get around to testing that!
<pulser>
and I want to do it before I give this one back, so I know if I should buy one myself or not
<naobsd>
maybe
<naobsd>
oops
<naobsd>
this linux-next kernel do not understand cpu freq > 1200000...?
<naobsd>
strange...
<naobsd>
lets reboot
<naobsd>
it shouldn't get reboot if max_freq is really 1200000 :(
<naobsd>
I shouldn't use linux-next ;)
<mmind00>
pulser: I pushed the actual change to the minnie dts to github ... could you give this one a final go ... my minnie is currently 650km away ;-)
<naobsd>
working properly this time... I hope my file system is not corrupted yet...
<pulser>
sure - I will do a build from HEAD again
<pulser>
does this require me to re-apply the change for the mali GPU?
<pulser>
nevermind, I see it is there anyway
<naobsd>
I'm using one of rk3288 board as a development work machine
<naobsd>
USB storage is not so fast but not so bad...
<pulser>
a fun quirk of the minnie that I need to look into is its handling of ACPI events - it seems (according to a blog post I read) that closing the lid sends a "wake" event
<pulser>
I had a quick skim of the EC source code, but I didn't spot anything obviously awry there to indicate this would happen, although I need to look more closely at it
<pulser>
as it's possible the EC is sending the right signals, but the kernel is handling the event as a wake trigger
<pulser>
mmind00: confirmed working on all counts
<mmind00>
pulser: great, thanks :-)
<mmind00>
pulser: ACPI? I don't think so ... the lid is just a (gpio-)key-event
<pulser>
yes I had noticed it was just a GPIO
<pulser>
as that's why I was confused - I guess it's the userland config
<pulser>
where it's mapping *that* GPIO into "wake"
<pulser>
(button is button is button, GPIO for buttons)
<pulser>
though it is fun they use dual accelerometers for the lid and orientation though - found someone wrote a nice little C driver, so I might try to daemonize it some time (theirs is a little binary that only supports a to-and-fro then exits)
<masked>
can anyone point me to a guide to creating a firmware image that include a boot partition and what not?
<masked>
i'm cool with creating arm OS images but want to put them in with the other "android" related stuff
masked has quit [Ping timeout: 250 seconds]
masked has joined #linux-rockchip
masked has quit [Ping timeout: 264 seconds]
masked has joined #linux-rockchip
VargaD has quit [Ping timeout: 260 seconds]
VargaD has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
johnnyr has quit [Ping timeout: 250 seconds]
johnnyr has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
<edolnx>
masked, I'm trying to figure that out myself. This may help, but I'm having issues on my RK3368 getting these to work: http://wiki.radxa.com/Rock/Booting_Linux
rory096 has joined #linux-rockchip
rory096 has joined #linux-rockchip
cosm has joined #linux-rockchip
kapouer has quit [Quit: kapouer]
kapouer has joined #linux-rockchip
ojn_ has joined #linux-rockchip
carlp_ has joined #linux-rockchip
masked_ has joined #linux-rockchip
sunxi_fan has quit [Ping timeout: 240 seconds]
edolnx has quit [Ping timeout: 240 seconds]
ojn has quit [Ping timeout: 240 seconds]
masked has quit [Ping timeout: 240 seconds]
carlp_ is now known as edolnx
sunxi_fan has joined #linux-rockchip
ojn_ is now known as ojn
AstralixNB has quit [Remote host closed the connection]
edolnx has quit [Quit: Leaving]
jas-hacks has joined #linux-rockchip
cosm has quit [Ping timeout: 240 seconds]
gb_master has joined #linux-rockchip
<pulser>
mmind00: Interestingly, the micro-HDMI output works nicely on the minnie :) Although I only see a cursor on one screen, but that's obviously some userland thing to fix
<mmind00>
pulser: I'm not surprised ;-) ... hdmi is in mainline since january
<pulser>
ahh OK I didn't realise :)
<pulser>
I have tested it on a native HDMI screen, as well as through a "HDMI -> VGA", and both are fine, so that is good
<pulser>
although there are occasional horizontal dark flickers, but I think that is probably related to the cursor bug or interference
<pulser>
nothing much :)
<pulser>
so count me as impressed :)
gb_master has quit [Quit: Leaving]
gb_master has joined #linux-rockchip
gb_master has quit [Remote host closed the connection]
<kapouer>
ohhh
<kapouer>
i think i found the reason why i get these "cannot set the DRM interface" errors
<kapouer>
setting oneself as drm master, and dropping oneself from being drm master
jas-hacks has quit [Remote host closed the connection]
<kapouer>
in armsoc driver,
<kapouer>
assumes it's the x driver that must do it. On systems with systemd, it's systemd-logind doing it for us
<pulser>
I can run X, I can't run gnome-shell well (crashes), but I can run XFCE and LXDE fine
<pulser>
acceleration is only EGL, not regular "OpenGL", so AFAIK you won't get a regular desktop DM to work "fancy"
<pulser>
2 secs, I turned mine off
<kapouer>
i wasn't so sure of that, given gnome-shell is using cogl
<kapouer>
an abtraction for gl/gles
<pulser>
well, I am very unfamiliar with all of that ;)
<pulser>
so I have not looked - I just know gnome isn't working right now
<pulser>
but that it should work
<kapouer>
me too, had to read :(
<pulser>
so I shall investigate it at some point
<pulser>
but let me get a look at the X log
<pulser>
OK kapouer, I need to reboot it, as my current X log has all my plugging and unplugging HDMI things
<kapouer>
btw if that's of any use, i had regular mmc issues (and filesystem errors) last week, and now it's two days without any problem. Basically is see "mmc tuned" messages instead of filesystem errors.
<mmind00>
kapouer: your's is the inverse of pulser's then :-S
<pulser>
hmm OK, a lot has changed since I last did all this :/ now it seems that systemd gets much more "in the way" - where is the best place for me to set these params? (I am trying to launch gnome from lightdm for now)
<pulser>
or must I try to do so manually?
<sjoerd>
for debian we bulid the arm clutter/cogl with egl by default which should just work iirc
<sjoerd>
it's been a while since i cared about X on arm
<pulser>
hmm right - so it "should" work then
<pulser>
I am on testing - I wonder if I should roll back to stable for this
<pulser>
to at least rule that out
<pulser>
kapouer: afraid I don't think I can easily test out gnome - I am trying to find out how to do things, but I am too used to the "old ways", and can't find anything that will bring me up to speed - if it isn't something I can click in lightdm, the last time I played with X, the only way to use it was to run "startx" :)
<pulser>
so I fear I will not be the best person to try testing this out :/
<pulser>
I already find it frustrating logs are strewn all over the place, and gnome is masking "useful" errors with silly "fullscreen" sad face signs etc... it's all changed a lot lately!
<pulser>
and I get a hard "freeze" if I switch VT to the graphical one, after trying to manually run gnome-session
<kapouer>
you can still ssh-login from there, though
<pulser>
fair enough - I am not a big fan of the level of complexity in the stack though these days - why are my VTs being frozen by a userland app? :)
<kapouer>
shouldn't when it's working
<pulser>
I need to try to find some good introduction docs I think, as too much is new for me
<pulser>
as I understand what you guys were suggesting I try, but I have no idea where to set the env vars, as I have no idea what environment the X stuff is being run in, since there's systemd or something starting lightdm automagically
<kapouer>
what i'm doing to test is disable gdm and try thing manually
<kapouer>
startx there, run gnome-shell there
<pulser>
OK so I stopped lightdm and disabled it
<pulser>
so I run startx
<pulser>
Fatal server error, no screens found
<kapouer>
yep, same here
<pulser>
don't I need an X server running first?
<sjoerd>
pulser: your VTs could always be "frozen" by a user app
<kapouer>
yes, depending on how it fails, you can override /usr/lib/gnome-session/gnome-session-check-accelerated
<pulser>
OK, I think I need to do some reading first :)
<pulser>
since lightdm works OK, I wonder if I can read its init scripts to get an idea what it's doing
cristian_c has quit [Quit: Bye]
<pulser>
Oh dear, I seem to have broken graphical desktop by installing kde packages
<pulser>
Or rather it seems I'm breaking things by assuming I can control the selected display manager just using systemctl enable and disable - that seems a wrong assumption
<mmind00>
dpkg-reconfigure kdm (or whatever) :-)
<pulser>
Yeah - I discovered that now - unfortunately I'm not so familiar with Debian on the desktop so I need to brush up
<pulser>
Might need to read the manual and just learn it, since arch is nowhere near as good as Debian on arm on the minnie
<pulser>
It's very strange though that gdm won't load, yet I can use lightdm fine and run kde5
<pulser>
(you use kde iirc mmind00?)
<mmind00>
yep
naobsd has quit [Quit: naobsd]
nighty^_ has quit [Read error: Connection reset by peer]
nighty^ has joined #linux-rockchip
masked_ has quit [Read error: Connection reset by peer]