<bashintosh>
naobsd: thanks for your reply yesterday, sorry I wasn't around the keyboard at the time :)
<tlwoerner>
naobsd: ping
<naobsd>
hi
<naobsd>
tlwoerner: hi
<naobsd>
tlwoerner: I'll post reply google groups messages
<tlwoerner>
naobsd: hello, i was hoping my emails to the mailing list would get your attention ;-) but i know you prefer to communicate over IRC so i thought i'd give you a ping here too
<tlwoerner>
naobsd: awesome! thanks :-)
<tlwoerner>
i thought i was following your latest instructions, but obviously not :-(
<naobsd>
tlwoerner: one important thing, please don't assume Rockchip implementation is standard, please don't assume mainline kernel follows Rockchip implementation
<naobsd>
these are very different thing
<tlwoerner>
right, but the "firefly" branch includes the commit to handle the mtdparts kernel cmdline, so I *thought* it should work
<bashintosh>
I see that it has many similarities with the Chromebook's DTS which, USB wise, uses DWC2 DRD driver rather than the DWC_OTG_310
<bashintosh>
Is there a newer kernel version for the Firefly which uses DWC2 somewhere? I'd like to use that driver rather than DWC_OTG_310 - using a staging DWC2 driver backported from kernel 3.13 seems to work fine but I can't figure out the vbus stuff in the DTS, so basically the ports have no power.
<bashintosh>
Not sure if you can help but worth trying :)
<rperier>
hi all
<bashintosh>
hi!
<sjoerd>
Anyway know where one can find teh CRU documetnation for RK3188 ?
apritzel has joined #linux-rockchip
wildea01 has joined #linux-rockchip
Avagetto has joined #linux-rockchip
Guest74771 has quit [Ping timeout: 244 seconds]
<mmind00>
sjoerd: I don't think it's publically available ... what do you need to know?
GTRsdk has quit [Ping timeout: 244 seconds]
<sjoerd>
mmind00: found the core issue already by comparing the vnedor kernel
<sjoerd>
mmind00: one question though for the spdif transceiver what does the hclk do ? Is that just to clock the control
<mmind00>
sjoerd: yep, the hclk supplies the transceiver ip block in the soc
<sjoerd>
right and the sclk is what's used to clock the actual audio going out
<mmind00>
yep
<sjoerd>
cool
<sjoerd>
time to start prepping some patches then
<sjoerd>
I've got my rock playing audio out from spdif nicely now
<mmind00>
sjoerd: mainline spdif ... nice ;-)
<sjoerd>
was the most trivial audio output to get going
<rperier>
nice :)
mrueg is now known as monsieurm
markm has joined #linux-rockchip
<naobsd>
oops
<naobsd>
very busy day (as usual)... :(
<naobsd>
bashintosh: kernel.org kernel is mainline Linux kernel developed by Linux community. Rockchip 3.10 kernel is developed by Rockchip. please don't assume they are compatible.
<naobsd>
later...
naobsd has quit [Quit: naobsd]
monsieurm is now known as mrueg
Avagetto has quit [Remote host closed the connection]
sunilmohan_w has quit [Ping timeout: 272 seconds]
markm has quit [Ping timeout: 240 seconds]
sunilmohan_w has joined #linux-rockchip
nighty^ has joined #linux-rockchip
markm has joined #linux-rockchip
<rperier>
tlwoerner: you have good ideas, but we need to agree about how to do things :)
<rperier>
arffff you closed the merge request, I have lost all the discussion :(
<rperier>
however interesting work was done on eMMC part
<tlwoerner>
rperier: i agree (that we have to agree) and am working to address all your comments/concerns :-)
<tlwoerner>
in the end i most strongly feel that there should only be one meta-rockchip, i don't want there to be multiple meta-rockchip's all over the place
<tlwoerner>
once i have my stuff in a state you are happy with and have accepted into your layer, i'll stop working on mine
<rperier>
that's also why... it would be nice to host this repo on git.yoctoproject.org directly
<rperier>
github is nice, but very confusing with all these forks
<rperier>
few days ago, I received another bug on the wrong repo for example
<rperier>
:/
<tlwoerner>
rperier: have you asked anyone? i'm guessing it might be possible to have it hosted on the yoctoproject's git server
<rperier>
no I don't ask anyone sorry, that's just an affirmation
<tlwoerner>
i agree, it's almost funny how so much stuff on github is just a copy of someone else's github repository. many times there isn't a single change, it's just a copy for the sake of copying ;-)
<rperier>
(french guys, we build weird sentences sometimes, sorry :D)
<tlwoerner>
when i worked at Linaro my team lead was from France, very nice guy
<tlwoerner>
and, of course, all the free-electrons guys are French too
<tlwoerner>
(they're nice too)
<rperier>
oh you know the free-electrons guys too :)
<tlwoerner>
just from meeting them at ELC
<tlwoerner>
any chance you'll be at the upcoming ELC-E in Dublin?
<rperier>
I met the team few months ago, very nice guys, yes
<rperier>
Mhhh I will try to have some days off, it would be cool (rockchip-taks are just an hobby for now)
<rperier>
I need to come to one of these events, yes. It seems very cool!
<tlwoerner>
if you are able to come, it runs from Monday to Wednesday, on the two days afterwards (thurs and fri) there are OE-specific things going on
<mrutland>
Interesting part is the "For Reviewer & Developer" section on the promotion page
<wildea01>
ojn: the "spec" refers to an "external fan connection", so I guess it's allowed somehow
<mrutland>
mmind00: neat
<mrutland>
"CPU: All CPU(s) started at EL1" :(
<mrutland>
maz: ^
<apritzel>
mmind00: that looks like this old dodgy u-boot tree
<mmind00>
apritzel: it probably is
<mmind00>
apritzel: even their upstream kernel is still 3.10-based
<mmind00>
apritzel: aka the same one they use in rk3288-androids
<maz>
mrueg: guess I'm in for some late hacking nights!
<rperier>
Trevor, I have just read your proposal about the "cortex-a17" tune. Looks interesting....
<ojn>
that's ok. slap another 3-4 shims of various sorts that people get to chase down from random github accounts and things will be great!
<apritzel>
mmind00: if the IP around the cores is very similar to rk3288, then a proper u-boot port shouldn't be so much work
<apritzel>
mmind00: Simon's port is pretty good regarding device abstraction, so ideally it should just work with the right device tree
<tlwoerner>
rperier: not so much a proposal anymore, it was accepted :-)
<tlwoerner>
rperier: technically it is what the rk3288 is, so if the compiler is going to have special modes for it, we should be using them
<tlwoerner>
since linaro back-ported the a17 support to their 4.9 release, i have been using this tuning for my firefly work
<rperier>
I was wondering, which parts will changed compared to a cortex a15 ? I mean, both have a VFPv4, both have a Thumb2 unit, both have a virtualization unit (it won't be used by the compiler...)..
<tlwoerner>
(since gcc-linaro-4.9 will build the Rockchip 3.10.x kernel without patches)
<tlwoerner>
rperier: no idea, i haven't had a chance to read the manual for either the a15 or the a17 yet ;-)
<rperier>
:)
<tlwoerner>
maybe -mtune=cortex-a17 is just a synonym for -mtune=cortex-a15?
<tlwoerner>
we'd have to ask someone at ARM perhaps
<maz>
tlwoerner: it shouldn't. very different microarch.
* tlwoerner
looks at maz
<tlwoerner>
maz: great, thanks for the input. i'll have to get reading ;-)
<maz>
tlwoerner: not sure there is much to read apart from the GCC source code...
<maz>
tlwoerner: the A17 TRM is probably very close to the A15, as all the changes are almost invisible to SW.
<mrutland>
mmind00: for the PSCI implementation, did I understand correctly that there are sources available somewhere? From a quick look around I couldn't find any rk3368 ATF trees.
<mmind00>
mrutland: not available currently ... it's based on something from arm, but Rockchip so far did not want to provide their modifications
<maz>
mmind00: is there at least a binary available somewhere?
<maz>
wouldn't be the first time I patch one...
<mrutland>
mmind00: That's unfortunate, especially as it seems to pointlessly drop to EL1, rendering virtualization impossible :(
<mmind00>
mrutland: yep ... again like on the rk3288
<mrutland>
Yeah :(
<maz>
the rk3288 at least drops you in secore mode, making the switch to HYP very easy.
<maz>
secure*
<mmind00>
maz: I guess on the rk3288 the situation might solve itself at some point with Simon's work
<maz>
mmind00: hopefully it will, I plan to bring a chromebook back from Seattle... ;-)
<tlwoerner>
maz: maybe i should do that too while i'm there ;-)
<tlwoerner>
maz: is it available from brick&mortar stores? i thought it was only available online (e.g. amazon)?
<mmind00>
tlwoerner: I think walmart too, which you could probably let deliver to a store at least?
<maz>
tlwoerner: I was thinking of getting it delivered to the hotel.
<tlwoerner>
maz: amazon will do that?!
<tlwoerner>
it's the hisense?
<maz>
tlwoerner: I don't see why not.
<maz>
tlwoerner: I was considering the asus (I definitely want 4gb).
<mmind00>
tlwoerner: the Hisense one (aka jerry) is walmart I think
<tlwoerner>
mmind00: ah, that's where i was looking
<rperier>
hisense has an excellent design
<rperier>
you can find all of these chromebooks easily in USA, I think
<rperier>
(I bought my veyron on amazon us)
<apritzel>
mmind00: I got the SD card working with Simon's tree on the RK3288
<mmind00>
apritzel: yay
<apritzel>
mmind00: it turns out that the Rockchip MMC driver was the first MMC driver using the U-boot device model, so some generic initialization was missing
<rperier>
tlwoerner: yep, mine was bought on amazon.com, amazon sent my chromebook by plane (it took... 2 weeks, something like that)
<rperier>
the price was converted from US $ to euro...
<rperier>
(but it was for an asus c201 not the hisense)
<rperier>
:)
cristian_c has joined #linux-rockchip
<apritzel>
mmind00: what are your load addresses for the kernel and the DT on a RK3288 board?
<cristian_c>
apritzel: hello, i've built and loaded the module
<cristian_c>
then I've run idcdetect and i2cdump
<mmind00>
apritzel: the old uboot does: kernel @ 0x02000000, ramdisk @ 0x04bf0000, Device Tree to 0480c000
<mmind00>
although I've so far always used an appended dtb on the firefly
<apritzel>
mmind00: thanks, I used that, too
<apritzel>
mmind00: so though u-boot can load the kernel and dtb from the SD now, I get the usual ARM result after bootz .... nothing :-(
<maz>
apritzel: earlyprintk is your friend, always.
<apritzel>
maz: earlycon= is on the command line, still nothing
<maz>
apritzel: earlyprintk, not earlycon.
<maz>
this is "good ol' 32bit".
<mmind00>
maz: although with a recent patch that sits in Russell's tracker, earlycon finally also works :-)
<maz>
mmind00: does it work early enough so that you actually see output from the decompressor?
<cristian_c>
apritzel: I've compared results against ring buffer messages
<mmind00>
maz: nope ... not this early
<maz>
mmind00: and the other question is: how long will it stay in Russell's patch system?
<mmind00>
maz: from what I've read that's the reason why both will stay around
<mmind00>
apritzel: although defaults should already set it accordingly, for comparison the earlyprintk section of my .config looks like https://bpaste.net/show/e86497bbf3b3
<apritzel>
mmind00: thanks, I'll give it a try
<cristian_c>
apritzel: but I can see only addresses related to devices mapped in /sys/bus/i2c
<cristian_c>
with i2cdump
<apritzel>
cristian_c: so what's the exact issue here?
<cristian_c>
apritzel: I've read dmesg and I see many no ack messages
<cristian_c>
apritzel: I'm trying to figure out why some i2c devices are not loaded
<cristian_c>
i2c i2c-3: No ack, Maybe slave(addr: 0x30) not exist or abnormal power-on, retry 2...
<cristian_c>
4rh adapter (i2c-3) is related to the two cameras
<cristian_c>
I've read documentation in lm-sensors website about i2c-tools
<cristian_c>
some drivers are registered in dmesg output (for example cameras and gsensor)
<cristian_c>
but i2cdump shows only pin mapping only for gsensor
GriefNorth has joined #linux-rockchip
<cristian_c>
for addresses related to audio (0x1a) on i2c-0 and pmic (0x2d) on i2c-1 i2cdump says they are busy and doesn't show pin mapping
<cristian_c>
but audio (rt5631) and pmic (tps65910) are working in my os
<cristian_c>
lis3dh (gsensor) is half-detected, but it seems not loaded, anyway i2cdump shows mapping about it
<cristian_c>
lis3dh is located at 0x19 in i2c-0
<cristian_c>
audio, gsensor and pmic are located in /sys/bus/i2c/devices
<cristian_c>
I don't know why cameras are not located in i2c-3 directory, but dmesg shows many errors about ov2659 in i2c-3
<cristian_c>
apritzel: I don't know too why internal display is not powered, I can use only hdmi connection
<cristian_c>
with my oa
<cristian_c>
os
<cristian_c>
in dmesg lcdc0 and lcdc1 messages are not clear so much
<apritzel>
cristian_c: probably some clocking or power issue?
<cristian_c>
maybe
<apritzel>
cristian_c: could check the relations between those devices in the DT
<cristian_c>
apritzel: I've choosen some options in .config before building kernel
<apritzel>
if the I2C slave is not powered up, then it wouldn't respond, I guess
GriefNorth has quit [Quit: Konversation terminated!]
<cristian_c>
apritzel: I understand, thanks
<apritzel>
cristian_c: that's not so much about the kernel config, more a board setup issue
<cristian_c>
apritzel: I've found an option in .confg about powersupply
<cristian_c>
apritzel: a last thing
<cristian_c>
'one more thing'
<apritzel>
cristian_c: check whether you need some power or clock drivers for the nodes listed in the device tree
<cristian_c>
apritzel: If I see at /sys/bus/i2c/drivers in android, I see lis3dh, ov2659, ov3660, rt5631, tps65910,and wm831x
<cristian_c>
ov are the cameras, lis3dh rt5631 and tps65910 are detected also iny os
<cristian_c>
apritzel: but I see wm831x
<cristian_c>
when I've built the kernel , I've not enabled wm831x
<cristian_c>
because I thought that it was not needed, tps65910 is the pmic for regulator, rtc.....
<cristian_c>
and I thought wm831x was pmic too
<cristian_c>
apritzel: so, I thought I had not to enable wm831x because I should enable only one pmic driver
<cristian_c>
but maybe I was wrong and maybe I had to enable two pmic drivers
<cristian_c>
to enable the remaining i2c devices
<apritzel>
you may have different PMICs on the board
<cristian_c>
ahhhhh, ok
<apritzel>
maybe you can dump the config from the Android kernel?
<cristian_c>
I'll try to enable wm831x too before rebuilding
<cristian_c>
apritzel: unfortunately, the stock android rom has not config.gz in /proc :(
<apritzel>
cristian_c: yeah, I was afraid of that
<cristian_c>
vendor has not enabled the 'create config.gz package' in .config
<apritzel>
can you see a list of drivers somewhere in /sys?
<cristian_c>
but I've enabled it when I've built the kernel for ubuntu :)
<cristian_c>
h
<cristian_c>
*yeah
<cristian_c>
apritzel: i can see builtin kernel drivers in both android and ubuntu
<cristian_c>
/sys/modules for example, contains directory about loaded drivers
<cristian_c>
*/sys/module
<cristian_c>
or /sys/class/platform
<cristian_c>
apritzel: I thank you for feedback, suggestions and help
<apritzel>
cristian_c: you're welcome
<cristian_c>
I'll make some attempts
<cristian_c>
(p.s. I see i .config an option related to battery config_38volts, this ismfor batteries with 3.8 V, but android apps see my battery as 7.4, vendor info are not clear, I think because vendor has put two batteries inside the case, in series or parallel, I'mcnot very exèert, so I've not enabled that option in kernel config before building because I was in doubt)
GriefNorth has joined #linux-rockchip
apritzel has quit [Ping timeout: 264 seconds]
cristian_c has quit [Read error: Connection reset by peer]