ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
nighty has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
cnxsoft has joined #linux-rockchip
ayaka has joined #linux-rockchip
ayaka has quit [Quit: Mutter:]
ayaka has joined #linux-rockchip
ayaka has quit [Client Quit]
lkcl has joined #linux-rockchip
lkcl has quit [Ping timeout: 255 seconds]
cnxsoft has quit [Remote host closed the connection]
lkcl has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft1 is now known as cnxsoft
<LongChair> cnxsoft: didn't find anything available in europe ...
<cnxsoft> LongChair: Denmark and Finland
<LongChair> doesn't seem there is any stock there :)
<LongChair> at least yet
<LongChair> asus made images ready to flash though :
wadim_ has joined #linux-rockchip
<wens> hmm, v4.10-rc5 doesn't work on my c201
LongWork has joined #linux-rockchip
<phh> wens you mean rc4=>rc5 broke it?
<wens> phh: from 4.9.0
<wens> it boots to some point, then stalls
<phh> wens: ah, and if you wait long enough, does it say mmc_switch in the stacktrace?
paulk-collins has joined #linux-rockchip
nighty has quit [Quit: Disappears in a puff of smoke]
Omegamoon has joined #linux-rockchip
Laibsch has joined #linux-rockchip
<Laibsch> Hi guys, one of the questions I have is how you would rate GPL-compliance of Rockchip vs Allwinner vs Amlogic? Or are they all equally bad?
<Laibsch> I suppose #linux-rockchip is mostly a reverse-engineering effort?
paulk-collins has quit [Read error: Connection reset by peer]
paulk-collins has joined #linux-rockchip
lkcl has quit [Ping timeout: 240 seconds]
<phh> Laibsch: nope, #linux-rockchip is mostly rockchip guys :P
<Laibsch> Obviously ;-)
<Laibsch> I thought so
<Laibsch> But I'm still wondering about the attitude of the involved companies towards the GPL.
<phh> Laibsch: well there is also the kernel maintainer for rockchip devices, whcih isn't a rockchip guy
<Laibsch> It will affect my purchase to a certain degree.
<phh> Laibsch: it was bad (GPL violations everywhere)
<phh> Laibsch: now they push some drivers into mainline, and drivers that can't go to mainline for some reasons are available as well (vpu/2d bliter/gpu)
<Laibsch> My current favourite (based on features vs price only) has indeed a rockchip although I read negative comments about rockchip's disclosure policy and thus I'm concerned about how well it will be supported.
<Laibsch> I also do not want to reward companies for bad behaviour (given the choice)
<phh> disclosure policy?
<phh> you can watch logs here where I ask for rk3399 TRMs and I just get it :P
<Laibsch> well, you said it, they were not disclosing in the past.
<Laibsch> I don't even know what a TRM is. I'll google that.
<phh> Technical Reference Manual
<Laibsch> OK
<phh> the hardware documentation let's say
<Laibsch> from Rockchip or leaked?
<phh> rockchip
<Laibsch> cool!
<Laibsch> thumbs up
<Laibsch> How is the support for the rockchip rk3229?
<Laibsch> can I build a mainline kernel?
<Laibsch> I'm thinking of reflashing what's referred to as a V88 OTT box (Android TV set-top box) with an RK3229 CPU to use as a homeserver.
<phh> mmm it feels like mainline support is quite poor
<Laibsch> so, what do people do? compile their own kernel with binary blobs?
<Laibsch> and have it break when kernel API changes?
<phh> official rockchip kernel doesn't have any binary blob
<Laibsch> I've had that problem way back when I was fiddling with the Sharp Zaurus more than ten years ago.
<Laibsch> I see. Thank you for the information. Is there an effort to integrate it with mainline kernel? What are the obstacles? Manpower, license, upstream doesn't like the code, ...?
<phh> as far as I can tell, only manpower.
<phh> stdint: would you know if you have some internal work ongoing to mainline rk3229? it looks like some drivers are there, ethernet/i2s/mmc, but no vop?
<phh> stdint: or even usb...
nighty has joined #linux-rockchip
<Laibsch> OK, I could actually help with that
<Laibsch> So, I should not expect any problems to reflash a rockchip device?
<Laibsch> I am not afraid of the command line, I'm a Debian maintainer and have some experience cross-compiling for embedded devices for about 10 years.
<Laibsch> I have used the serial console for reflashing, but if possible, I'd rather do it in a different manner without opening the device. Should that be possible?
<phh> yup sure, all rockchip devices have a ROM which can flash from USB
<phh> Laibsch: you'll need an USB-A <=> USB-A cable
<phh> (unless the OTT you're looking at has an usb slave connector)
<Laibsch> Is that the same as OTG?
<phh> cable you mean?
<phh> the cable is not an otg cable, it's something like that:
<Laibsch> I was wondering if usb slave connector is just another word for OTG
<Laibsch> some of these devices have an USB OTG port
<phh> it means either micro-usb or mini-usb or USB type D
<phh> type D is really unlikely
<phh> OTG means something really specific: it can do both usb host and usb slave, with dedicated hardware to detect whether is should go host or slave
<phh> most rockchip OTT are capable of both slave and host, but not OTG capable
<Laibsch> OK
<phh> (also, fwiw, the usb port which can be used to reflash the device, can also be remuxed into a serial port)
<Laibsch> Any reason to stay away from*/32749147294.html ? Looks like an incredible machine considering the low price.
<Laibsch> actually, the same machine also sells for just 18 USD, IIRC
<Laibsch> BTW, XDA still bashes rockship at for binary blobs in the released kernel sources. I suppose that's outdated, then?
<Laibsch> Granted, the article is from 2013, but people might not realize that
cnxsoft has quit [Quit: cnxsoft]
alex_ has joined #linux-rockchip
<Omegamoon> Speaking about binary blobs... I would like to have Mali user space binaries for Utgard (Mali400) that does NOT depend on X11. Anyone in here knows who could provide these?
<Omegamoon> Currently the rk-rootfs-build repo here...
<Omegamoon> ...has the r6p0-01rel1 version of the Mali user space binaries, but these depend on X11
<Omegamoon> I need these binaries in order to get LibreELEC working. Now it bails out during startup saying "ERROR: Unable to create GUI. Exiting"
<Omegamoon> I wonder if this is due to the X11 dependencies, or worse, due to some RK specific modifications in X11
Laibsch has quit [Ping timeout: 248 seconds]
<phh> Omegamoon: have you checked Mali's website?
<phh> right, mali only has 450
Laibsch has joined #linux-rockchip
<phh> Omegamoon: well then you could try {lib,mac}hybris or perhaps check on allwinner side
<Omegamoon> would be nice if someone from Rockchip could help me out here... a fbdev version of the user space binaries is all I need :)
<Omegamoon> @phh: thanks, I got a couple of version from here and there on the Net
<Omegamoon> but the binaries need to match the kernel driver (API)
afaerber has quit [Quit: Leaving]
<Omegamoon> there are lots of versions for Android, but only a few for Linux :(
<phh> Omegamoon: I recommend opening an issue on the github
<phh> Omegamoon: well you can find the kernel source quite easily
<phh> and erm, you can fake it
<phh> not really recommended, but well
<Laibsch> Omegamoon: Somehow I think I rmember the nick from somewhere. Do you remember mine?
<Laibsch> anyhow, why don't you compile yourself? that's usually the best way.
cnxsoft has joined #linux-rockchip
<phh> Laibsch: we don't have sources for mali userspace
<Laibsch> Oh, I see.
<Laibsch> That won't affect my plans, I suppose (running a headless homeserver).
<Laibsch> ?
<phh> no
<Laibsch> nice. Does the rk3229 attach the USB ports via an internal USB hub? This is one the things limiting speed for the raspberry Pi.
<phh> I wouldn't tell for sure, but on rk3288 at least, there are three dedicated usb controllers
afaerber has joined #linux-rockchip
Laibsch has quit [Ping timeout: 255 seconds]
<Omegamoon> @Laibsch: can't remember... help me here :)
<Omegamoon> Zaurus perhaps?
paulk-collins has quit [Remote host closed the connection]
Laibsch has joined #linux-rockchip
<Laibsch> thanks, phh. Do you have any idea where to find out for sure?
<phh> erm, doesn't support rk3228 either actually, the only supported kernel at rockchip for rk3228 is 3.10
<phh> Laibsch: I confirm there are three independent usb bus
<phh> (and ethernet isn't on USB bus)
<naobsd> last time (several months ago?) I tried mainline on rk3229, it boots, but very poor support
<phh> it seems to be the same thing at the moment
<naobsd> probably there is no mainline u-boot for rk322x yet
<naobsd> (stock u-boot can boot mainline kernel)
<naobsd> there are many outdated info about RK... our wiki is one of them :(
<naobsd> it might be better to refer rockchip official wiki
<Laibsch> so, an RK3229-based box would currently be a bad choice if I want to run Debian for example?
<phh> Laibsch: I think so yes. better take rk3288 or wait for rk3329
<naobsd> probably info about RK 4.4 kernel and mainline u-boot/linux is important for now. older info should be marked as OLD or vanished...
<Laibsch> OK. Thanks.
<phh> naobsd: well rk3228/9 is only in rk 3.10 -_-'
<naobsd> I think Android kernel is not so good for "Linux". (I know it works, but)
<phh> naobsd: I agree, but better redirect to a kernel with some support than one without
<naobsd> ah, yes
<naobsd> I agree
<naobsd> btw I think I saw a 4.4 branch for rk322[89] on github
<naobsd> (if my memory is correct)
<naobsd> but it seems there is no such branch on rockchip-linux
<naobsd> probably it was someone's personal repo
<phh> naobsd: yup I'd like to know too
<phh> I don't understand what's happening there
<phh> I'm waiting for rk2928 support now
<Omegamoon> @phh: strangely enough, most of the Mali kernel sources that are out there are crippled... they don't work
<naobsd> Make RK3188 Great Again!
<phh> I have very nice rk3188 devices
<phh> like a 9.7" tablet with 2048x1536 screen
<naobsd> phh: I'm waiting for RK3066 ;)
<phh> naobsd: rk3066 is the IoT chip?
<phh> ah no, it's rk3188's ancestor
<naobsd> phh: no older than RK3188, dual core
<Omegamoon> hey... nice find :)
<phh> it's rk3036 the IoT thingy
<Omegamoon> that one has user space binaries that I didn't try yet
<naobsd> REVISION=Linux-r6p1-01rel0 VARIANT=mali400-gles11-gles20-neon-linux-x11-fbdev-ump hmmmmm
<naobsd> better than nothing
<phh> ump :(
<Laibsch> I'm looking at trying to figure out where I can see what CPU is supported and which one is not?
lkcl has joined #linux-rockchip
<phh> Laibsch: arch/arm/boot/dts/ and arch/arm64/boot/dts check the -evb.dts and its various includes, and you'll see the peripherals supported
<phh> Laibsch: you'll see that in the various includes of rk3229-evb.dts, there is no usb ehci ochi or whatever
<phh> though you have gmac (ethernet)
<phh> check rk3288-evb.dts if you want an example that contains pretty much everything
<naobsd> oh 3.0 kernel, live long and prosper!
<phh> -_-
<naobsd> anyway
<naobsd> I think I can use them to make RK3066 based Linux system ;)
<naobsd> with lovely 3.0 kernel
<Omegamoon> ump... crap
<naobsd> I'm happy. probably...
<naobsd> it might be a crap, but anyway old information should be vanished now
<phh> also, what do you do with machybris?
cnxsoft has quit [Quit: cnxsoft]
paulk-blaze has joined #linux-rockchip
paulk-blaze has quit [Ping timeout: 258 seconds]
JohnDoe_71Rus has joined #linux-rockchip
Laibsch has quit [Read error: Connection reset by peer]
lkcl has quit [Ping timeout: 240 seconds]
<Omegamoon> @phh: machybris... reluctant to use that kind of overhead
<phh> Omegamoon: for rk3188/rk3066 that's the only way
<phh> well, most realistic way
<Omegamoon> for rk3066... yes, but for rk3188?
<Omegamoon> rk3188 is part of the 3.10 kernel for some time now
<Omegamoon> haven't tried it yet though
Laibsch has joined #linux-rockchip
lkcl has joined #linux-rockchip
jacob_ has joined #linux-rockchip
jacob_ is now known as Guest66446
Guest66446 has quit [Client Quit]
wzyy2 has joined #linux-rockchip
<Omegamoon> I'll try a version of the Allwinner Mali400 user space binaries now...
<wzyy2> We used to have plans to port rk3229 from 3.10. . . Just, no enough resources and it still lack some drivers.
lkcl has quit [Ping timeout: 240 seconds]
<Omegamoon> really don't know if these Mali binaries are SOC specific in any way
<phh> Omegamoon: no they are not, SoC specific part is in kernel
<Omegamoon> so there is a change it might work then...
<Omegamoon> lets hope so
<dlezcano> mmind00, hi
<dlezcano> mmind00, do you have access to a rk31xx platform ?
<wzyy2> Mali binaries are not SOC specific but GPU specific. Both of GPU software and hardware versions must match.
<dlezcano> ... or someone else :)
<Omegamoon> @dlezcano: what access do you mean?
<dlezcano> Omegamoon, just give the content of /sys/devices/system/clocksource0/*
<dlezcano> \/sys/devices/system/clocksource/clocksource0/*
<LongWork> Omegamoon: did you try the arm ones ?
<Omegamoon> available_clocksource
<Omegamoon> current_clocksource
<Omegamoon> power
<Omegamoon> subsystem -> ../../../../bus/clocksource
<Omegamoon> uevent
<Omegamoon> that is conents of /sys/devices/system/clocksource0
<Omegamoon> *contents
<Omegamoon> @LongWork: which ones do you mean?
<mmind00> dlezcano: Hi ... yep - need to fixup its bootloader first though :-)
<dlezcano> Omegamoon, available_clocksource and current_clocksource
<dlezcano> mmind00, if Omegamoon can give me the information, it should be ok.
<dlezcano> Omegamoon, oh, and the clockevent also if you can
<dlezcano> mmind00, I want to check the global timer is not used at all.
<mmind00> dlezcano: I think right now it is used ... which is the problem Alex is trying to fix
<dlezcano> mmind00, yeah but it shouldn't with the twd
<dlezcano> mmind00, so I am wondering if we can just remove the global
<mmind00> dlezcano: looking at arch/arm/kernel/smp_twd.c it looks like it only registers a clockevent device, not a clocksource?
<dlezcano> mmind00, yeah ...
wadim_ has quit [Remote host closed the connection]
<dlezcano> mmind00, so if we disable the global or we remove it, if there is no alternative, we end up with jiffies
<Omegamoon> interesting... the allwinner mali user space binaries get me at least through the EGL initialization
<wzyy2> Omegamoon, are you using rk3066?
<Omegamoon> no, rk3128 currently
<Omegamoon> I target the cheap ass devices for now :P
<dlezcano> mmind00, we should be able to replace the global with the armv7-timer no ?
<mmind00> dlezcano: nope, the rk3188 is a cortex-a9 ... there was no arch-timer on those yet
<mmind00> dlezcano: on the A9s there was this combination of global+
<mmind00> local timers
<dlezcano> mmind00, ok. The patch disables the global
<dlezcano> mmind00, why not remove it directly
<dlezcano> and use the rockchip-timer instead
<dlezcano> mmind00, don't we have an alternative to the global's clocksource ?
<mmind00> dlezcano: why not removing it, is a good question, I guess as reference or so ... devicetree is a hardware description after all
<dlezcano> mmind00, yes, that is a good point.
<mmind00> dlezcano: using rockchip-timer instead is what Alex patch series is doing I'd think
<dlezcano> ah, ok :)
<dlezcano> I think it is time, I send my changes for clocksource
<phh> mmind00: speaking of "is a hardware description", would it make sense to declare vpu and mali inside the dts, even though there is no actual driver? (possibly it would require to commit a documentation first though)
<mmind00> phh: hot topic right now :-) ... short answer (for mali) is yes, long answer is "wait for to land"
<mmind00> phh: the vpu not so much ... there is work done on it (albeit slowly), so bindings should enter with the real driver
Laibsch has quit [Read error: Connection reset by peer]
<phh> haha, I didn't see the mali binding indeed
<phh> mmind00: well vpu is quite a long shot. ATM it requires a driver that have no way to be merged upstream, and I would like to be able to provide DKMS drivers for those
<phh> (I guess the motivation for mali is the same though)
<mmind00> phh: the "ATM" is the issue here :-) ... with bindings there always needs to be backwards compatibility, so any binding introduced now any driver will always need to honor
<mmind00> phh: and for the vpu there is at least a sourceful driver that at least has the chance to enter mainline at some point
<phh> yup I know, but I think that rockchip did multiple drivers (both the v4l and the vpu), I think they can be pretty confident as to what is needed
<phh> mmind00: this driver does only h264 and vp8... we are pretty far from the actual capabilities of the chip
<Omegamoon> LongWork: unfortunately... no Mali-400 user space binaries there
<mmind00> phh: yes and exactly that is the reason not to have preliminary bindings :-) ... the whole VPU involves multiple IP blocks, a somehow shared service block and probably more
<mmind00> phh: things like the core display driver did look vastly different (also in terms of bindings) when it was propsed the first time, so there is quite a chance that something needs to change midway
<mmind00> phh: another example is the memory controller binding currently in use in uboot (inherited from chromeos), which misrepresents the hardware a lot (see which I still need to submit :-) )
<phh> right
<phh> though at some point someone has to jump, to at least start the discussion
<mmind00> phh: yep, but in the case of the (complex) vpu it should definitly involve code
paulk-collins has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
Laibsch has joined #linux-rockchip
Laibsch has quit [Quit: Leaving.]
Laibsch has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 255 seconds]
lkcl has joined #linux-rockchip
mrjay has joined #linux-rockchip
hramrach has joined #linux-rockchip
hramrach__ has quit [Ping timeout: 255 seconds]
hramrach has quit [Ping timeout: 255 seconds]
Laibsch has quit [Read error: Connection reset by peer]
hramrach has joined #linux-rockchip
vagrantc has joined #linux-rockchip
lkcl has quit [Ping timeout: 255 seconds]
scelestic has quit [Read error: Connection reset by peer]
LongChair has quit [Ping timeout: 240 seconds]
LongWork is now known as LongChair
scelestic has joined #linux-rockchip
LongChair1 has joined #linux-rockchip
<Omegamoon> @phh: raised a ticket on github, asking for Utgard mali user space binaries...
<Omegamoon> which has been closed by wxyy2 within an hour
<Omegamoon> saying fbdev mali drivers are for the old 3.10 kernel which they don't plan to give support
<Omegamoon> wow!
<Ancient> So, a patch got merged in for 4.10 that breaks eMMC on my C201. Is it conventional to bump the original mailing list patch submission?
<Ancient> Mailing lists always confused me in that regard, it seems hard to re-open issues for discussion and keep track of open/close states.
<vagrantc> oh, i wonder if it fixes emmc on my C201 :)
<vagrantc> Ancient: what patch?
<Ancient> Right now I've been un-patching that one for each rc in 4.10 so far so I can keep testing a few things.
<Ancient> I also emailed the original author, but no reply (yet).
<vagrantc> well, you can always propose a revert :)
<vagrantc> that might stir people up a bit more than just asking
<vagrantc> there's hardly anything on the internet more able to find the right answer than proposing a wrong one :)
<alex_> vagrantc I just tried reverting that commit and compiling, now the mmc is working properly for me
<Ancient> That's a neat way to look at it actually. I generally try to propose a right answer or if I don't know it, just ask.
<alex_> i'm also using a C201
<vagrantc> you can ask, and people may read it and know, but not bother to care... but if they see something *wrong on the internet* they take swift action
<vagrantc> it's a tool in the toolbox :)
<vagrantc> ok, i'd really love to get the C201 to the point where I can actually boot off of something other than USB
<vagrantc> so if this works, i'll be quite thrilled
<LongChair1> @Omegamoon : we have Mali 450 userspace driver but not Mali 400 iirc
<Omegamoon> @LongChair1: if rockchip takes community support seriously then they should provide it
<LongChair1> agreed
<LongChair1> stdint is away for a few days i think ... you might wanna ask him when he's back
<Omegamoon> it is pretty stupid that I need to try Allwinner or Odroid binaries
<LongChair1> yeah C1 might be Mali 400
<LongChair1> that or wait for stdint and switch to another RK soc in the meantime :)
<Omegamoon> haha... one at a time :)
<LongChair1> i suppose that once you have one going, others should flow :)
<Omegamoon> the Allwinner EGL binaries at least get through the initialization
<alex_> vagrantc: emmc is still broken, but sd card works
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria]
<Ancient> alex_, Can you tell me anything about the problem you're seeing booting from your eMMC? I'm doing that right now on a C201, maybe I can help.
<Ancient> Also, what's your root= value? I know a few people with C201s had some trouble with the fact that the plain device name changed when migrating from chromiumos kernel to the mainline.
<alex_> Ancient I dind't try to boot from eMMC, i booted from USB, but sometimes the boot would succeed and sometimes fail, then I would get lockups in mmcqd/2, trying to mount the sd card would lock up the system
<Ancient> Ah, my mistake. :)
<alex_> Ancient root=PARTUUID=%U/PARTNROFF=1
<Ancient> I'm not sure I've got any helpful ideas then, sorry.
<Ancient> All three are working on my device: SD, USB and eMMC. So I'm not sure what the problem might be.
<Ancient> The only two things I don't have working still (that I care about anyway) are Mali & headphone plug/unplug detection.
<vagrantc> i've been testing since ~v4.8 and had eMMC and sometimes SD be very unreliably detected ... usb usually works fine
<vagrantc> i had a patch that made MMC work reliably by disablign tuning or something, but then it apparently broke for other people
<vagrantc> er, eMMC
<vagrantc> that sounds promising
<mmind00> at least for the general mmc <-> runtime-pm thingy
<phh> Ancient you' ve seen my repo for mali on mainline?
<Ancient> phh, I have. I recently compiled it actually (and sent you a PR for the Kbuild) but haven't had a chance to test it yet.
<Ancient> General case of too many projects on the go at once.
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
vagrantc has quit [Ping timeout: 245 seconds]
<Ancient> mmind00, Hmm, that does look promising. I'll test that out in a few minutes and report back my findings.
Omegamoon has left #linux-rockchip [#linux-rockchip]
<Ancient> mmind00, Confirmed, that does the trick. So it looks like the mmc problems will likely be resolved for rc6.
<Ancient> Sharp eye there.
<mmind00> Ancient: I was in the Cc-list of the patch ;-)
irsol has quit [Ping timeout: 264 seconds]
irsol has joined #linux-rockchip
nighty has quit [Quit: Disappears in a puff of smoke]
<naobsd> I remembered about RK3229 patches
<naobsd> mmind00: what's the remaining for u-boot for RK3188?
<mmind00> naobsd: spl/tpl loads and can now also configure sdram ... uboot itself also works ... but the transistion between the two (via the bootrom) does not work in most cases ... if you put the FlashBoot thing in front in works, so something in the spl is not right yet
<mmind00> naobsd: one Rockchip guy was able to build a working image (spl -> uboot) via some very old tool, but anything recent does not produce working images
<mmind00> naobsd: so essentially we're looking for the proverbial needle in the haystack to find out what makes the bootrom choke :-)
<naobsd> hm
<naobsd> mmind00: btw I wonder how did you find spl/tpl need to be splitted... concatnated spl/tpl binary for sd boot can be used for usb boot too? or I need to do something to support tpl in rkflashtool?
<naobsd> I hope concatnated single binary is enough...