<sjoerd>
just looking at the schematics myself as my board should arrive today
<sjoerd>
At a first look it seems the power tree looks a lot like that of the rk3288-evb-act8846
nashpa has quit [Ping timeout: 250 seconds]
nashpa has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 256 seconds]
onesixnine has quit [Quit: Page closed]
<mmind00>
sjoerd: probably also very similar to the firefly ... I think that is sort of the reference design :-)
levd1 has joined #linux-rockchip
<rperier>
yes but there are few changes like pmic_vsel or pwr_hold If am remember correctly
<sjoerd>
mmind00: indeed
<rperier>
I only looked at the schematic a bit and compared some stuffs with the firefly dts, but I had no time enough
<rperier>
:(
<sjoerd>
guess what i'm doing now
levd has quit [Ping timeout: 260 seconds]
<rperier>
usb host and otg pins did not change so much too...
<sjoerd>
rperier: ooi did you hae some ideas on how to split up the dtsi's between the baseboard and the som ?
<mmind00>
sjoerd: do a som.dtsi .... and a baseboard.dts ... that way potential new basedboards can include the common som defs
<rperier>
I would create a file for the som... then include the som dtsi from rock2-squareboard.dts and from rock2-fullboard.dts... something like that
<rperier>
yes
<sjoerd>
There are a few som variants, but iirc the only changes are memory and emmc sizes
<mmind00>
while not split into som+baseboard the veyron stuff is quite similar in doing this
<mmind00>
sjoerd: memory is supposed to be set by the bootloader (aka overwriting the dts node)
<mmind00>
so simply take the smaller size as default
<sjoerd>
I see
<sjoerd>
that works
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 252 seconds]
levd1 has joined #linux-rockchip
<rperier>
btw, the suffix "_d" and "_u" on GPIO output in the schematic... is for... ? pull up/down?
levd has quit [Ping timeout: 244 seconds]
<sjoerd>
That's my assumption
levd1 has quit [Ping timeout: 244 seconds]
<mmind00>
rperier: but it could also mean what is the "active" value ... haven't looked at the schematics ... the veyron devices for example seem to use "_l" and "_h"
<rperier>
indeed... :/
<rperier>
you're talking about the schematic of your pinky right ? (the developer model)
premoboss has quit [Remote host closed the connection]
<rperier>
(I mean, the only model with public schematics)
<mmind00>
there are pinky schematics? ... I was actually talking about the pin definitions in the dts referencing the schematics ;-)
<rperier>
oh ! my bad, ok
<rperier>
:)
mrueg has quit [Quit: No Ping reply in 180 seconds.]
mrueg has joined #linux-rockchip
<mmind00>
woohoo ... Minnie touchscreen is also working now
<rperier>
whoo ! nice
JohnDoe_71Rus has joined #linux-rockchip
<rperier>
btw, I shared my point of view on your patch for "usb-uart" (a kind of "ping" with my point of view). You will probably disagree, but hey, that's the game :D
<rperier>
the code itself works very fine on all my devices
<mmind00>
rperier: I actually do not disagree :-) ... just implementing this is not easy at the point it should happen (neither the devicetree nor the grf syscon is available then)
<mmind00>
to late for 4.3 anyway ... I guess I'll revisit this in time
<sjoerd>
hmm, can one not force the rockchip rom to ccheck SD card before eMMC ?
<rperier>
Oh sure, not for 4.3. I don't think that the devicetree is so problematic, you could switch your mux from an early stage and then do your devicetree stuffs later (when it is available)... the boring part will be grf syscon... :/
<rperier>
anyway...
ganbold has quit [Ping timeout: 255 seconds]
<rperier>
mhhh... for my personnal education, I think that I will inform myself of this early stage thing in the linux kernel... seems interesting
ganbold has joined #linux-rockchip
markm_ has quit [Ping timeout: 272 seconds]
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft has joined #linux-rockchip
<mmind00>
rperier: yep, all the different initcall times are interesting :-)
<rperier>
hehe. I am pretty sure that I already saw patches for early syscon initialization... don't remember if it was accepted or not...
<mmind00>
rperier: early syscon support is already "old-news" ;-) ... aka currently the early_initcall seems to be the earliest thing that can use syscons ...
dlezcano_ has joined #linux-rockchip
<c0d3z3r0>
hi guys did anyone test kexec on rk3188? I'm stuck at "Uncompressing Linux…"
<rperier>
I use it everyday on all my rockchip-based devices... it works fine
<rperier>
which device ?
<c0d3z3r0>
radxa rock pro
<rperier>
did you concatenate the dtb to your kernel image ? or did you ask kexec to load the dtb when loading your kernel image ?
<c0d3z3r0>
it is appended to the kernel
<rperier>
with a mainline kernel? :/
<c0d3z3r0>
yep
<c0d3z3r0>
4.2-rc6
<rperier>
have you a trace or a log ?
<rperier>
what's your kernel cmdline? (the one that you try to boot)
<c0d3z3r0>
rperier: I forgot my geoip blocking… but at least now I know it works :D
<rperier>
ahah :D
<c0d3z3r0>
a second try ended with the same result :/
<rperier>
mhhh interesting
<rperier>
I had the same kind of issues... few months ago
<c0d3z3r0>
hm how did you fix it?
<rperier>
wait a sec, I have a patch somewhere in my github repo
<rperier>
it is not yet mainlinable, but you could rebase it (few lines) and try it at least
<rperier>
(not so complicated)
<rperier>
what happens is: you probably don't have heiko's patch to enable usb-phy on rk3066/rk3188 , if you use the dwc2 driver in dual role, when the driver does not find a valid usb phy it fails... but in some obscur cases... it can call interrupt handlers or function when the hw is uninitialized
<rperier>
I think that this is your problem
<c0d3z3r0>
mhh dual role is not enabled
<rperier>
only host?
<c0d3z3r0>
right
<rperier>
mhhh
<rperier>
the weird thing is that
<rperier>
I only had this issue with my radxa rock pro
<rperier>
not with my radxa rock (first edition)
<rperier>
:D
<rperier>
apparently you're in device mode
<c0d3z3r0>
I checked my config again. only CONFIG_USB_DWC2_HOST is enabled
<c0d3z3r0>
rperier: same exception after adding heiko's patch
cosm has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
mrueg has quit [Quit: No Ping reply in 180 seconds.]
mrueg has joined #linux-rockchip
markm has quit [Ping timeout: 250 seconds]
cristian_c has joined #linux-rockchip
VargaD has quit [Ping timeout: 246 seconds]
VargaD has joined #linux-rockchip
gb_master has joined #linux-rockchip
premoboss has joined #linux-rockchip
gb_master has quit [Remote host closed the connection]
<rperier>
amstan: I am wondering something... do you use brcm_patchram_plus on chromeos.... I mean... it was created for chromeos right ? I don't find it via "cross/shell"
<rperier>
anyway, I think I will need to package it for meta-rockchip in yocto... (to kick bt and have a working wifi)
<rperier>
I think that *
<mmind00>
wohoo, wifi on Minnie now too
pizthewiz has joined #linux-rockchip
gb_master has joined #linux-rockchip
<maz>
mmind00: out of curiosity, which one is minnie?
<mmind00>
maz: Minni is the Flip
<maz>
mmind00: right.
<maz>
mmind00: which one is the c201?
pietrushnic has joined #linux-rockchip
<mmind00>
maz: that is called speedy
<maz>
mmind00: thanks!
<mmind00>
maz: and it seems even the edp might be mainline-ready in the near future
<mmind00>
maz: first two revisions were posted last week
<maz>
mmind00: really cool stuff.
<maz>
mmind00: I'm looking forward to retiring my 2.5 year old chromebook
<maz>
being stuck on 3.8 is not my definition of fun.
<mmind00>
maz: hehe ... hopefully the still slight functionality deficit (compared to the actual chromeos kernel) will go away in time too
<maz>
mmind00: I don't mind missing a few things, as long as the basic "laptop" functionality is present. It is more important for me to be able to *fix* things when they go wrong.
<maz>
mmind00: with my current samsung crap, I can't do a thing.
<maz>
mmind00: specially given that this is the only laptop I carry around.
<greggypoo>
maz, you're refering to the xe303?
ganbold has quit [Ping timeout: 255 seconds]
<amstan>
maz: i've been running the chromeos kernel with arch for a while, runs nicely\
<maz>
greggypoo: yes, the first ARM-based chromebook.
<maz>
amstan: I'm not interested in running a 2 year old kernel.
<amstan>
maz: what features are you interested in that you can't use on 3.14?
<amstan>
in terms of drivers, they're either mirroring upstream or we have more stuff implemented than upstream
<maz>
amstan: my *job* is to maintain Linux on ARM.
<amstan>
ah, in that case.. heh
<sjoerd>
maz: more interestingly what are you missing upstream for that laptop?
<maz>
amstan: KVM is the most important bit.
<maz>
sjoerd: ^^
<sjoerd>
ah thought that was possible on the chromebooks
<sjoerd>
but never tested it
<maz>
and with that anything that is related to SMMU support.
<maz>
sjoerd: it should be possible if you run mainline.
<maz>
sjoerd: I wouldn't want to use what we merged in 3.14, really.
<sjoerd>
mine are part of our lava setup, so i don't really use them personally directly
<sjoerd>
the smmu stuff has been landing recently iirc
<rperier>
mmind00: you're working on wifi on veyron ?
<rperier>
s/on/for/
<mmind00>
rperier: for the broadcom-based devices there isn't much to work on ;-)
<greggypoo>
maz, fwiw i am using a c201 right now, and i love it. but i loved the xe303 too :)
<mmind00>
rperier: aka Minnie just talks to my AP
<mmind00>
rperier: the marvell variants don't like me yet
<rperier>
I was trying to get my broadcom wifi work on my speedy... that's why I ask
<greggypoo>
but i'm just as stuck on 3.14 with this as i was at 3.4 with the older one
<mmind00>
rperier: hmm, I just built the bcrmfmac driver (see updated veyron_defconfig) and copied the lib/firmware/brcm/* stuff from the chromeos rootfs to mine
<mmind00>
greggypoo: difference seems to be that we're a lot further along in getting all this into the mainline kernel ;-)
<greggypoo>
optimist :P
<mmind00>
greggypoo: realist :-P
<mmind00>
greggypoo: apart from audio (i2s support is present, just nobody looked at hooking this up), only the edp driver for the display is "missing" (*)
<mmind00>
(*) I use the chromeos one right now and the real mainline support is currently under review
sunilmohan has joined #linux-rockchip
<greggypoo>
crazy, i haven't even considered moving away from the chromeos kernel
<greggypoo>
someday i want to look into what has been done to work with mali
premoboss has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]