<mmind00>
naobsd: it was working before, so I'd assume it still does
<naobsd>
I still have no idea why it doesn't work on my firefly... I should try somewhat-stable
<naobsd>
(I don't have so much time for now...)
<pulser>
mmind00, very nice - I'll test out mmc speeds tomorrow. One very quick (and basic) question - what's the best way to apply the patches from the mailing list? I was finding git-am rejecting a bit more than I expected, but don't recall a fuzzy option on it - just wondered if there is a "better" way I'm forgetting
<mmind00>
naobsd: there isn't any difference concerning hdmi between mainline and my somewhat-stable
cristian_c has quit [Quit: Bye]
<mmind00>
pulser: I normally just pull in the maintainer-tree's next/whatever branch to get up to date
<mmind00>
pulser: sometimes I also simply edit the patch ;-)
<pulser>
Ah OK, that's a better way actually
<pulser>
I was using pwclient
<pulser>
Heh, I managed to pull Linus' 4.3 over somewhat-stable as a test and it worked nicely
<pulser>
That was just me doing a quick test to ensure I could merge things cleanly and get a working output - will have a look at your branches in the morning
<naobsd>
mmind00: I see, thanks...
<kapouer>
is "ARMSOCPrepareAccess: Failed to map buffer" something expected when running X ?
<kapouer>
(i'm trying to run gnome-shell, but it does the same with lightdm)
kapouer has quit [Quit: kapouer]
cnxsoft has joined #linux-rockchip
sunilmohan_w has joined #linux-rockchip
kapouer has joined #linux-rockchip
diego71 has quit [Ping timeout: 252 seconds]
diego71 has joined #linux-rockchip
lerc has quit [Read error: Connection reset by peer]
nighty^ has joined #linux-rockchip
cristian_c has joined #linux-rockchip
<mmind00>
kapouer: I generally don't know how X works, but that doesn't sound healthy
<kapouer>
i wonder if it's something that can be fixed in armsoc or a more general problem
<cristian_c>
hello
<mmind00>
kapouer: interesting ... seems broken here too [with all the edp tests and stuff, I hadn't X running for some time now]
<mmind00>
kapouer: probably some change in the DRM/KMS? I'll take a look
<kapouer>
(fbdev is working)
<cristian_c>
how could I add a new resolution not listed in 'modes' file?
<cristian_c>
Any ideas?
<naobsd>
does anyone have working HDMI on firefly/rock2 with linux-next?
<rperier>
mhhh... I did not test recently... last time I tried I had a freeze but it was on my chromebook...
<rperier>
also, it will probably don't help :p
<rperier>
(it was something like 1 month ago...)
<sjoerd>
naobsd: wfm
<sjoerd>
though i know at least one fix is needed to get weston to not hang, but the console comes up just fine here
<naobsd>
sjoerd: can I see kernel config and dmesg?
<naobsd>
I tried multi_v7_defconfig with
<naobsd>
CONFIG_DRM_ROCKCHIP=y
<naobsd>
CONFIG_ROCKCHIP_DW_HDMI=y
<naobsd>
CONFIG_ROCKCHIP_PM_DOMAINS=y
<sjoerd>
naobsd: kernel config, just multi_v7 with my patches
<sjoerd>
did you enable the iommu as well?
<naobsd>
CONFIG_ROCKCHIP_IOMMU=y etc are enabled w/o patch
<naobsd>
I cannot see anything related to rockchipdrm/hdmi in dmesg...
<sjoerd>
i know hdmi works in that one at least ;)
<sjoerd>
but i didn't htink there is anything in it wrt. hdmi that's not in next yet
cristian_c has joined #linux-rockchip
<mmind00>
yep, that is what is puzzling me ... hdmi on the firefly is working since january (commit-date)
<pulser>
kapouer: same issue here on booting the veyron-minnine in lightdm
<pulser>
sorry, slightly different message: "Driver failed PrepareAccess on a pinned pixmap"
<pulser>
and I get the failed to map buffer in X's log too
<kapouer>
pulser: i'm seeing that message as well
<kapouer>
so we can safely say it's the same error
<pulser>
yes - am going back through the changes
<pulser>
unfortunately I don't see any good errors in dmesg to chase down
<pulser>
kapouer: one option is to bisect, and work back until it breaks, then narrow down the commit causing the issue
<kapouer>
i can help with that, but i have yet to find a place where it works
<pulser>
oh OK, you have not had display working yet?
<pulser>
(even before mmind updated the branch last night?)
<kapouer>
not with armsoc
<pulser>
and you had tried a compiled kernel before last night?
<pulser>
that is strange - it was working here on veyron-minnie fine
<kapouer>
yes, but i had another issue with armsoc
<kapouer>
i had to install xserver-xorg-legacy i think
<kapouer>
then i didn't roll back to check with previous version
<pulser>
OK right
<kapouer>
xorg in debian is becoming less straightforward to launch ;)
<pulser>
if you want to try the build I had working, build from commit 6509232 on branch somewhat-stable
<pulser>
that should work fine (yay for git reflog)
<mmind00>
yeah, it looks like some recent change to the drm/kms code introduced this ... there are no real rockchip-specific changes, so it seems to come from some more core part
<pulser>
yeah - that would make sense - I had a look at rk related stuff and drew a blank
<pulser>
if I was better at git-fu, I would try to filter it to retain only your rk changes on top of 4.3.0, but I know that's too naive on a project the size of the kernel!
<mmind00>
as far as I got right now, the mmap of the drm-gem object in the xserver fails with ENXIO after the dumb-mapping itself
<pulser>
OK, you got further than me in diagnosing this then :) I couldn't find any meaningful errors, but I didn't have time to try to trace deeper yet
<mmind00>
I've just traced what armsoc does first ... with a big load of debug output :-)
<pulser>
ah OK :) so you got further than me then, as I was still reading X logs
<mmind00>
the issue might also come from the iommu, as this is involved in graphics-mem allocation ... all fields I haven't had much contact with yet [still looks like voodoo]
<pulser>
gles2 is broken, but I need to now undo the other reverts I was trying, so I will update in a couple of minutes
<pulser>
OK, es2gears remains "broken" - no display output
<pulser>
A few new errors now in dmesg; one is "mali ffa30000.gpu: Reset interrupt didn't reach CPU. Check interrupt assignments." and the other is "mali ffa30000.gpu: AS_ACTIVE bit stuck"
<pulser>
there also seems to be a board-specific (?) regression, namely that battery status is no longer being reported correctly
<mmind00>
pulser: nice find, now it's only to find what we need to fix ... the mali stuff _could_ be related to the new power-domains, but I'd think that the code I got from ChromeOS _should've_ set this up
<pulser>
yep - I suspect you will know a lot more than me about this stuff - I only have passing familiarity with this stuff
<pulser>
it COULD be powerdomains - if I get time I may try to revert... the battery status suggests there has been more changed than we realise :)
<pulser>
mmind00: am I right in saying that the powerdomains changes may allow the device to sleep "deeper" (now you brought that from chromeos?)
<mmind00>
pulser: nope ... the power-domains allow turning off stuff at runtime (like the gpu, video-encoder and some more) when it's not used
<mmind00>
pulser: that is work of Caesar from Rockchip ... what I brought over from Chromeos is the mali kernel part ... but as Chromeos has power-domain support for a lot longer, I suppose it should handle them correctly already
<pulser>
interesting - I felt (based purely on instinct/gut feel) that the non-chrome kernel drained more power in sleep, but perhaps that was "imagined"?
<pulser>
yeah - that would be a reasonable assumption - I didn't see anything obvious in dmesg, but for power domains I guess it might just be sitting there "off"
<mmind00>
again nope ... mainline is missing the actual deeper sleep ... so it will drain more
<pulser>
that explains it, thanks :)
<pulser>
(I am not familiar with sleep on Linux really)
<pulser>
I had assumed you'd use power domains to shut things off, then sleep (I am more familiar with MCUs where you set registers to flag what can sleep and what can't)
<sjoerd>
power domains can be used to shut of sections of the SoC
cosm has joined #linux-rockchip
<pulser>
sounds similar to the sleep registers on an MCU then :)
<mmind00>
which gets called before the actual mapping
<pulser>
ah right
nighty^ has quit [Ping timeout: 250 seconds]
AstralixNB has left #linux-rockchip [#linux-rockchip]
nighty^ has joined #linux-rockchip
markm has quit [Ping timeout: 252 seconds]
jas-hacks has joined #linux-rockchip
nighty^ has quit [Ping timeout: 240 seconds]
gb_master has joined #linux-rockchip
nighty^ has joined #linux-rockchip
<rperier>
I have just discovered openhub... seriously.... it rocks :D
<rperier>
It finds all your contributions... since the beginning ... everything! I have even forgot some of my contributions on some projects o_O
gb_master has quit [Remote host closed the connection]
markm has joined #linux-rockchip
nighty^ has quit [Ping timeout: 260 seconds]
Xeta has joined #linux-rockchip
<Xeta>
Hi! Anyone here have experience installing a linux distribution on MK 902 II?
nighty^ has joined #linux-rockchip
maz has quit [Quit: Leaving]
cosm has left #linux-rockchip ["Leaving"]
<mmind00>
btw. I've updated the branch and posted the drm patches
<pulser>
mmind00: tested your 2 commits and they are working fine - giving X, without egl (same error as I was getting by reverting) - going to have a look at those errors now
<mmind00>
pulser: I already forgot that there was also a mali problem :-) ... going to look at that too now
<pulser>
heh no worries - your fix is much nicer than my random reverting!
<pulser>
my initial findings were:
<pulser>
<pulser> A few new errors now in dmesg; one is "mali ffa30000.gpu: Reset interrupt didn't reach CPU. Check interrupt assignments." and the other is "mali ffa30000.gpu: AS_ACTIVE bit stuck"
<pulser>
mmind00: another one I am chasing down, is that there is no battery status showing (no BAT0/BAT1 in /sys/class/power_supply/) - I reverted the config line change making battery a module, but to no avail
edolnx has joined #linux-rockchip
<mmind00>
pulser: hmm, on regular chromebooks I think the sbs battery is the correct one ... except for minnie
<pulser>
OK interesting - let me investigate then
<pulser>
I insmod'd it, and it hasn't appeared
nighty^ has quit [Ping timeout: 240 seconds]
jas-hacks has left #linux-rockchip [#linux-rockchip]
<mmind00>
pulser: ok, it looks like we lost the sbs battery ... let's see where it ended up
<pulser>
don't see anything in arch/arm related to {sS}{bB}{sS} that's changed
<mmind00>
that's more a matter of mfd/cros_ec/... I think ... I don't think it has gone far ... it may very well just be us missing a merge [we are in the middle of the merge-window after all]
<pulser>
ah yes
<pulser>
cros_ec_i2c.c and cros_ec_spi.c appear to be recently changed - having a look trhough
<pulser>
nothing major though
<edolnx>
Greetings Everyone, I got a RK3386 based Uppel CX-R8 and I'm starting hacking on it. Good news: looks like it's got a userdebug boot loader on it, and UART pins exposed on the board. Bodes well for getting Debian amd64 installed at some point :D Any hints at SD bootloader would be appreciated!
Sadneophyte has joined #linux-rockchip
<edolnx>
sorry, it's an RK3368 not at RK3386
Sadneophyte has quit [Quit: Leaving]
<mmind00>
edolnx: on the rk3368 uart2 and the sd-controller share pins ... so you will either need to use a different uart, or some other boot-medium
lerc has quit [Remote host closed the connection]
lerc has joined #linux-rockchip
<naobsd>
if CX-R8 is Hotack HTC-T052-V* which should be same board as MK68, there should be 4 holes. I guess it's UART2... i.e. only UART2 is available(easily accessible)
<naobsd>
(I don't have it, not sure)
markm has quit [Ping timeout: 240 seconds]
<edolnx>
mmind00, Yep, saw that in my research. I've got USB ports I can boot off of. Should be interesting. Just hoping I can get into uboot on the UART ports as it looks like there are at least two from the kernel messages in Android :D
<edolnx>
I'm going to post some photos of the boards in a moment...
<edolnx>
I'll try and get a better quailty picture later. It's not the greatest. I'm putting some headers on the UART pins so I can attach my FTDI cable and see the sights
gb_master has joined #linux-rockchip
<naobsd>
hm, it's different to Hotack T052
<edolnx>
and sadly all the traces for the SD card and the GPIO pins are on middle layers of the board so I can't follow them :(
<naobsd>
but physical port locations are almost same, probably same external case can be used... so I cannot identify these 2 by looking port locations from outside ;)
<edolnx>
The USB port next to the SD card _may_ be switchable between OTG and Host, since it's the only one directly wired to the SOC. The rest go through that USB HUB
<edolnx>
naobsd, I have a couple of Rikomagic RKM MK68 boxes on the way as well, it will be interesting to see how they differ also.
<naobsd>
RK u-boot for rk3368 should support boot(load kernel etc) from USB storage too, but I never tried yet
<naobsd>
at least you should be able to use eMMC with UART2 console
<naobsd>
SD will not work when UART2 wires are connected but it may work just pulling wires w/o reboot/reflash/etc
<naobsd>
so you can try boot from SD then connect wires to UART2 after boot
<naobsd>
well, boot from SD, pull SD, then connect UART2
<edolnx>
I haven't had a chance to put together a SD card to boot from yet. It looks...complicated from the wiki :D
<naobsd>
I'll put script with files to make bootable SD for RK3368
<edolnx>
naobsd, Thanks! I've got access to Windows and Linux boxen to run that from, whichever is easier for you. I'm also planning on documenting a lot of what I'm doing and putting it on the wiki and my blog as I go
nighty^ has quit [Quit: Disappears in a puff of smoke]
<edolnx>
This isn't my first rodeo hacking on strange hardware, but this is my first adventure into Rockchip ARM stuff :)
<naobsd>
mkimage will be handy tool to make bootable SD for RK
<naobsd>
but rk3036 support need to be merged to generate right header ;)
<naobsd>
(mkimage in mainline u-boot)
naobsd has quit [Remote host closed the connection]
gb_master has quit [Quit: Leaving]
<edolnx>
I assume that the default baud rate on these UART ports is 9600?