<rperier>
do we have a dts property like "card-external-vcc" for sdio (or equivalent) ? this one is used by the sdio host in the chromeos kernel to supply wifi and bt, I think that we will probably need something like that (except if it already exists somewhere else)
<sjoerd>
rperier: on exynos peach pi we use the mmc-pwrseq bits
<rperier>
indeed... it seems that this is what I was looking for (you seem to use it for "WIFI_EN" too)
<rperier>
I will look into it
<rperier>
thanks
mrueg has quit [Ping timeout: 264 seconds]
mrueg has joined #linux-rockchip
bbelos_ is now known as bbelos
<mmind00>
rperier: yep ... the veyron mmc hosts already use it in mainline for emmc and sd-cards
ganbold has joined #linux-rockchip
<rperier>
oh, cool. So, I have everything I need in this case
cnxsoft1 has quit [Quit: cnxsoft1]
ganbold has quit [Ping timeout: 255 seconds]
ganbold has joined #linux-rockchip
popolon has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
premoboss has joined #linux-rockchip
markm has quit [Ping timeout: 264 seconds]
<amstan>
rperier: can i see the code of your kernel?
<amstan>
rperier: i think you're not rebooting properly
<amstan>
this happened to mmind00 too
<amstan>
you have to use the warm_reset gpio to reset, not the arm reset
<rperier>
for now, I have an official chromeos kernel on my sdcard with an arch linux
<rperier>
I download a mainline kernel via wifi, and I reboot to mainline on the fly with kexec
<amstan>
that should be ok... in theory
<amstan>
as long as you don't reboot via the arm way back into the firmware it shouldn't matter
<amstan>
and shutting down is a whole different mechanism, it powers off everything via an i2c command to the pmic, no firmware should run at poweroff
<rperier>
mhhh...anyway... the "boot" cpu is not restarted during kexec, only other cores... yes... as you said... it has probably nothing to do with my issue...
<rperier>
I have some crashes or freezes sometimes... not sure that it can directly impact the firmware... what do you think ? when a case like this one happens, I do an hard poweroff
<rperier>
(press the "power" button during...5-10s)
<rperier>
If this issue happens again, I will try to note what I did (in details), if it can help...
premoboss has quit [Remote host closed the connection]
cristian_c has joined #linux-rockchip
wildea01 has quit [Quit: leaving]
drcode has joined #linux-rockchip
<drcode>
hi all
<amstan>
rperier: if it is the firmware problem, the good news is that we have a fix for it, but you need to update your RO firmware(which requires opening your speedy and removing the wp screw)
<drcode>
I am thinking to buy rockchip board based on 3288
<drcode>
I wil be glad for some help
<mmind00>
drcode: you'll need to be more specific in what type of help ;-)
<drcode>
what board are recommanded radxa or firfly?
<cristian_c>
hello
<drcode>
I want to compile liunx kernel with rockchip
<drcode>
3288
<cristian_c>
how can I mount some nand partitions in user-space?
<rperier>
both are great
<rperier>
however
cristian_c has quit [Remote host closed the connection]
<drcode>
I know both using same chip - radxa , ugoos ut3 and firefly
<rperier>
drcode: if you plan to play a bit with the mainline kernel, I think that a firefly might be a good choice as it is greatly supported in the mainline kernel (
<rperier>
it will be easier at the beginning I mean
<drcode>
I want to had kali linux
cristian_c has joined #linux-rockchip
<rperier>
oh kali linux
<drcode>
if the chip are the same
<drcode>
I can do it on radxa or uggos?
<rperier>
in this case, i think that you might use the official kernel directly (shipped with the firefly)
<rperier>
it's a 3.10
<rperier>
except if you want a recent kernel
<cristian_c>
I don't see mtdblocks files in /dev, but only loop0 to loop7, and 7:1 to 7:7 in /dev/block
<drcode>
rperier: I don;t know about there board
<cristian_c>
Any ideas?
<drcode>
how are the firefily boards? tha give only 4 mounth warrnty
<drcode>
is there kali linux for radxa rock2 or firefly?
<rperier>
there are many different projects on rockchip-based devices, I am not aware of kali linux...so i would say no..
<drcode>
radxa rock2 also has sata
<drcode>
I am realy conufuze
<rperier>
I have both
<rperier>
both are excellent, very well designed
<drcode>
radxa rock2 or fireflay
<rperier>
BUT
<rperier>
the radxa rock 2 is an open hardware
<rperier>
all documentation are very good and opened
<rperier>
documentation for firefly is good too, but it is more confusing
<rperier>
and misses some stuffs
<drcode>
I am thinking to buy rock2 4 Gb ram - 32Gb emmc
<drcode>
by the way, is there possible to change emmc?
<drcode>
I had odroid-u2 before with emmc 64Gb
<rperier>
take these points in consideration + what you plan to do with the boards (how many I/O do you need ? do you really need sata ? etc) + the price perhaps
<rperier>
I don't think that's possible to change emmc, if you have any specific detailed questions about the board, you can ask on radxa.com directly, there is a great forum
<mmind00>
amstan: bindings is slightly different in mainline, but just look at rk3288-firefly.dtsi in the &saradc node
<mmind00>
amstan: although so far I'm still wondering how to use these values (aka the saradc seems mostly used for buttons and I think I saw an hp-detect somewhere too)
<amstan>
i can't figure out why you would use it for a button
<amstan>
for hp-detect it makes sense
<mmind00>
don't ask me ... to few pins?
<amstan>
the buttons on the headphones can be measured by an adc
<amstan>
i guess
<mmind00>
or more likely one old soc had to few pins and the principle stuck / nobody wanted to change the loader-recovery code
<amstan>
lol
<mmind00>
amstan: ok, wasn't hp-detect, but mic_detect instead ... and a battery detect seems also common
<amstan>
shouldn't there be a c file with the same compatible string somewhere?
<mmind00>
amstan: your kernel seems incomplete ... mainline contains a nice drivers/iio/adc/rockchip_saradc.c ;-)
<amstan>
we might not have the upstream driver, yeah
<amstan>
yep
drcode has quit [Quit: Page closed]
steev_ has quit [Ping timeout: 240 seconds]
steev_ has joined #linux-rockchip
nighty^ has quit [Quit: Disappears in a puff of smoke]
cristian_c has quit [Quit: Bye]
mrjay has joined #linux-rockchip
<mrjay>
hi all
<mrjay>
mmind00: so to enable usb-phy on rk3066 only dts modification was needed?
<mmind00>
mrjay: yep
<mrjay>
mmind00: thanks by the way.
<mmind00>
mrjay: no problem ... I've tested this on a Marsboard by the way
<mrjay>
mmind00: i thought it needed spme c code to enable it.
<mrjay>
mmind00: you're fast
<mmind00>
mrjay: nope, the phys are actually similar between rk3066, rk3188 and rk3288
<mrjay>
mmind00: aha, ok.
<mrjay>
mmind00: one thing i can't figure out
<mrjay>
mmind00: on mk808 there is reset button which state can be read through adc. Is there a way in dts to map adc channel changes as key presses?
<mmind00>
mrjay: I think you mean the recovery-button (not reset)? ... in the backlog you can see amstan and me talking about the saradc just an hour ago
<mrjay>
mmind00: don't need patch this time, only info what to look for
<mmind00>
mrjay: but no there is currently nothing for a saradc -> key handling
<amstan>
this totally baffles me
<amstan>
why would anyone want to read 1 button through 1 adc channel?
<amstan>
i guess if you're out of pins...
<mrjay>
yeap i meant recovery button ... sorry
<mrjay>
reading the logs now
<mmind00>
mrjay: the saradc seems only be used for 0/1 state readings (button, mic-detect, battery-detect), so the current idea I have in the back of my head is some sort of adc->gpio driver
<mmind00>
mrjay: but only an idea and far away in time-matters
<amstan>
mmind00: if you write that, don't forget about schmidt triggering
<mrjay>
great idea i say
<amstan>
let's say the values go from 0-1023
<amstan>
if you read something under 300 let's say it's 0, same with >700==1
<amstan>
but if it's in between you have to have a history, if it was >700 recently it would be a 1, if it was
<mrjay>
it would be cool if adc pins could have multipurpose character gpios/adc lines
<mrjay>
in rk3 socs
<amstan>
mrjay: what do you mean by "character"?
<amstan>
on most MCUs ADCs are multipurpose, they're just a different pinmux for a GPIO
<mrjay>
sorry ... bad polish to english translation also my knowledge in this matter is poor
<mrjay>
:)
<mmind00>
although the rockchip saradc seems to use dedicated pins
<mmind00>
and amstan now you make pull out my firefly, because I remember the reported values being actually quite stable :-)
<amstan>
most adc readings will probably have some kind of noise +-10 units
<amstan>
combine that with the rising edge when you press a button
<amstan>
and for a few cycles you'll toggle above and below your threshold(let's say 512)
<amstan>
this is not about debouncing, this is a much smaller effect(and higher frequency) than bouncing of a button
<amstan>
that's why schmidt triggers were invented
<mmind00>
amstan: wikipedia seems to have a nice image illustrating what you just said ... I think I understand now :-)
<amstan>
for button bouncing... you'll also have that noisy wave go fully up and down a few times, but on a much longer time period
<amstan>
so schmidt triggers can't help in all situations
<mrjay>
also observable on mk808
<mrjay>
when holding button values oscilate plus minus 1~2
<mrjay>
:)
<amstan>
yeah, i might have exaggerated when i said 10
<mmind00>
:-D
<mmind00>
still it might be a while until I might tackle this ... my favorite toy-mice (Jerry, Minnie and Pinky) do not seem to use the saradc ;-)
<mrjay>
also diffrent adc values on some boards might mean diffrent action like in samsung smartphones when you connect to microusb port for example mhl adapter resistor value is diffrent from when you connect it to for example dock station
<mmind00>
mrjay: yep ... on the saradc you can get something similar ... sometimes more than one source is connected to a channel
<mmind00>
mrjay: and then it's different voltages for different buttons ... combinations might be interesting to observe too ;-)
<mrjay>
mmind00: agree :)
<amstan>
mmind00: do you have upstream on your firefly?
<amstan>
mmind00: you said you were going to get it out, what were you going to do?
<amstan>
i ask because i'm in a noob and have no idea how to get it going
<mmind00>
amstan: of course ... I have only upsteam on my rockchip devices ... getting the rockchip kernels to compile was always to much hassle for me ;-)
<amstan>
i cherry-picked the upstream driver, enabled the config, hacked the status=enabled in the rk3288.dtsi, but all i see is a pretty boring ./bus/platform/drivers/rockchip-saradc folder
<mmind00>
amstan: yeah, the iio-specific stuff is hiding very well
<mmind00>
amstan: I always use /sys/devices/platforms/ff100000.saradc/iio_something
<amstan>
that's the only saradc i see for sys # find|grep saradc
<amstan>
i might be missing the subnode
<mmind00>
also, look into the firefly.dtsi ... we want a vref-supply
<mmind00>
amstan: which is the regulator connected to ADC_AVDD_1V8
<amstan>
i see no errors in dmesg about a missing vref supply
<amstan>
in fact there's nothing in dmesg|grep sar
<mmind00>
hmm ... when you do a "ls /sys/devices/platform" you should see all the dt devices as "ffxxxxxx.something" ... if the saradc is not in there it means the kernel did not get the device from dt
<mmind00>
i.e. all platform devices are in there, even the ones without drivers
<mmind00>
is something connected to channel 0 then?
<mmind00>
(aka ADC_IN0)
<amstan>
nope
<amstan>
so it's floating
<amstan>
i'm testing this on minnie
<amstan>
so i don't expect it to be showing me interesting things
mrjay has quit [Quit: Page closed]
naobsd has joined #linux-rockchip
naobsd has quit [Quit: naobsd]
<amstan>
mmind00: ya! it works nicely
<amstan>
i tried it in a real device
<amstan>
i was holding a wire, then i had print "#"*(int(open("/sys/devices/ff100000.saradc/iio:device0/in_voltage0_raw:368").read())/16) in a loop in python