<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>
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>
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: 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
<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
<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
<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...