ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
lkcl has joined #linux-rockchip
kevery has joined #linux-rockchip
vagrantc has joined #linux-rockchip
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-rockchip
shailangsa has quit [Ping timeout: 260 seconds]
stikonas has quit [Remote host closed the connection]
camus has joined #linux-rockchip
shailangsa has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery has joined #linux-rockchip
chewitt_ has quit [Read error: Connection reset by peer]
chewitt has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
crabbedhaloablut has joined #linux-rockchip
archetyp has quit [Quit: Leaving]
System_Error has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 256 seconds]
macc24 has joined #linux-rockchip
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-rockchip
_hramrach has quit [*.net *.split]
mx08 has quit [*.net *.split]
CounterPillow has quit [*.net *.split]
sigmaris has quit [*.net *.split]
clarity has quit [*.net *.split]
clarity has joined #linux-rockchip
CounterPillow has joined #linux-rockchip
_hramrach has joined #linux-rockchip
sigmaris has joined #linux-rockchip
rembo10 has quit [*.net *.split]
rembo10 has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery1 is now known as kevery
camus has quit [Ping timeout: 256 seconds]
camus has joined #linux-rockchip
System_Error has quit [Ping timeout: 276 seconds]
vagrantc has quit [Quit: leaving]
indy has quit [Ping timeout: 250 seconds]
chewitt_ has quit [Read error: Connection reset by peer]
chewitt has joined #linux-rockchip
chewitt_ has joined #linux-rockchip
chewitt has quit [Ping timeout: 264 seconds]
matthias_bgg has joined #linux-rockchip
camus has quit [Ping timeout: 252 seconds]
camus has joined #linux-rockchip
stikonas has joined #linux-rockchip
camus has quit [Ping timeout: 256 seconds]
camus has joined #linux-rockchip
<rembo10>
Is the psci support for the rk3288 different in mainline than in rockchip-linux? Sorry I'm still trying to wrap my head around this
<rembo10>
Or is it platform independent?
<rembo10>
For example I see some drivers used in the rockchip kernel, for example "rk3288_usb20_otg", that don't exist in mainline
<rembo10>
Or "rk3288-ddr-sram". My assumption was that they were merged with some other driver but maybe that's not the case?
<rembo10>
I'm also wondering if cpuidle is implemented in firmware? For example I enabled psci checker and see: "psci_checker: cpuidle not available on CPU [0-3], ignoring"
<rembo10>
I also see "psci_checker: Error occurred (-1) while trying to power down CPU 0" (only cpu 0 though. But I think maybe cpu 0 shouldn't be powered down?)
<rembo10>
I was having trouble bringing up the secondary cpus without using psci
<mmind00>
rembo10: regarding driver variances, there are of course a lot between the vendor-kernel and mainline - so things often are differently structured
<mmind00>
rembo10: but with psci they come up? ... cool
<rembo10>
But it's causing all these problems aha!
<mmind00>
rembo10: a psci implementation is part of earlier parts of firmware - so far I've seen at least 3 parts where it can be implemented: u-boot itself, trusted-firmware or optee
<mmind00>
rembo10: and I don't think there was an "official" vendor implementation in the wild, so I guess the psci you already seem to have on your device was implemented by the device vendor themself
<rembo10>
So my device originally came with android with the rockchip formatted images
<rembo10>
So I think it was implemented in the trust.img
<rembo10>
Which means... rockchip implemented ATF I guess?
<mmind00>
rembo10: not necessarily ... could also be done by the device vendor
archetyp has joined #linux-rockchip
<mmind00>
rembo10: or as part of optee
<mmind00>
rembo10: i.e. on arm64 it's always atf ... but for example for the 32bit rk3229 series, Rockchip implemented psci as part of optee
<rembo10>
It's all so confusing!
<rembo10>
It's so hard to know where it's implemented
<rembo10>
When I suspend on the android side, I think I saw something about OP-TEE
<mmind00>
rembo10: understandably ... if you have a serial console, you should hopefully see early output in (or before) the u-boot time on what it uses
<mmind00>
rembo10: ah ok, so it's probably optee
<rembo10>
When I try to enable idle-states in my dts, it seems like it goes into suspend on startup?
<rembo10>
Which I can't seem to figure out
<mmind00>
rembo10: which in turn could really be a feature of the manufacturer of your ebook device ... i.e. a ebook device wants to spend as much time suspended and normally only should wake up on some event and go back to suspend directly after that
<rembo10>
I mean before it even gets to stage 1
<rembo10>
From the android boot logs:
<rembo10>
[ 0.609770] TEE Core Framework initialization (ver 1:0.1)
<rembo10>
[ 0.609844] TEE armv7 Driver initialization
<rembo10>
[ 0.610511] TEE core: Alloc the misc device "opteearmtz00" (id=0)
<rembo10>
[ 0.610891] TEE Core: Register the misc device "opteearmtz00" (id=0,minor=62)
<mmind00>
rembo10: so yeah, probably optee ... and that's a part where you probably won't get sources for. I guess best way forward is to just ignore idle-states for now, they're not really need to get basic functionality I guess
<rembo10>
Can I suspend without using psci?
<rembo10>
I also thought my usb issues were caused by psci
<rembo10>
Sorry for all the questions
<rembo10>
I just have run into so many dead ends...
<rembo10>
So the linux op-tee won't be compatible with whatever the uboot/trust.img was created with?
<rembo10>
Basically everything I was searching for, ended up at patches that you wrote, haha.. so I feel like you're the only one who can help me :-D
<mmind00>
rembo10: both atf and optee have plaform-specific parts that need to be implemented ... so that optee on your device has rk3288-specific code in it that we don't have sources for
<rembo10>
So frustrating
<mmind00>
rembo10: from a "hacking" point of view, firmware stuff, including suspend is like the endgame for support - especially suspend is quite difficult on arm32
<mmind00>
rembo10: because there are so many things that can go wrong
<rembo10>
Right
<rembo10>
I thought rockchip was quite open about this stuff?
<mmind00>
rembo10: I did a rk3288 platform for atf, but I don't think that ever included suspend there
<rembo10>
So it's not as simple as just calling the psci suspend function....
<mmind00>
rembo10: Rockchip participates ... but as you can see on the mailinglist for example a lot of rk3568 support is done by others .... and of course _any_ soc vendor will think twice on investing time into a 7 year old soc ... sadly
<rembo10>
Yeah I guess that's fair enough
<mmind00>
rembo10: the other way around ... in a psci case, it should be just the kernel calling the psci suspend function
<rembo10>
Boox even has stopped supporting it pretty much
<rembo10>
Which is why I wanted to get linux running on it
<rembo10>
But it's like a perfectly capable chip for an ereader!
<mmind00>
rembo10: rk3288 originally implemented stuff themself ... i.e. cpu-core-handling and suspend ... with psci, all of that should move over to being done inside the psci implementation
<rembo10>
They rolled out a beta for Android 9 and then just.... left it hanging
<rembo10>
Right
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-rockchip
<rembo10>
But there would be no way to use the normal smp methods if I'm bringing up the secondary cpus with psci?
<rembo10>
I'm just trying to figure out what my options are
<rembo10>
I feel like I've come so far... to have it dual booting with wifi and everything... just to give up now
<rembo10>
I guess I could develop it to the point where it was functional, and then put the upstream uboot on it
<rembo10>
Then I wouldn't need to keep the original android stuff
<rembo10>
Hm so the rk3288-{android,linux}.dtsi in the rockchip-kernel uses psci
<mmind00>
rembo10: oh you're right
chewitt_ is now known as chewitt
<rembo10>
They're also using rockchip-suspend... I just saw in the decompiled dtb that it also uses rockchip-suspend
<rembo10>
Hmm
<rembo10>
pm-rk3288
lurchi_ has quit [Ping timeout: 265 seconds]
<rembo10>
Maybe it's just a problem with my wakeup sources then... I "echo +30 > /sys/class/rtc/rtc0/wakealarm" and then "echo mem > /sys/power/state"
<rembo10>
But the gpio power key doesn't work either, it's configured as a wakeup source
<rembo10>
It just stays frozen
<mmind00>
rembo10: arch/arm/mach-rockchip/* probably has the original suspend code as well, not sure if that is interfering
<rembo10>
I'll have a look
<rembo10>
Do you know why it wouldn't be in mainline?
<rembo10>
Oh wait I think it is
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
<mmind00>
rembo10: that is what I meant :-D ... mainline has very rudimentary suspend support for rk3288, which might interfere
<rembo10>
So it's just a matter of the patches not getting into mainline? I just figured like, the mainline would be more updated
<rembo10>
For some reason
<mmind00>
rembo10: sadly not at all ... in general vendors often semi ignore mainline ... i.e. the basics get in, but to support more esoteric functionality of a chip, making a mainlineable solution [quality-wise] would require more work, so often these "leaf"-things only end up in a vendor-tree, where there is no discussion ;-)
<mmind00>
rembo10: rk3288 is reasonably good supported, as there was the line of Chomebooks based on it, but even there some things didn't make it into mainline
<rembo10>
Yeah i think that's why I figured all this support would be there
<rembo10>
There are like so many devices using the 3288
<mmind00>
rembo10: though the "real" vendor-tree and the chromeos/mainline trees also diverged really early on ... so you have the rk3288 chromeos devices using a kernel quite close to mainline, but all the other rk3288 devices use a vendor-tree that looks largely different
<rembo10>
I see. I think my main concern was... It seemed like the usb (dwc2) was having difficulty getting the cpu out of L1 idle state
<rembo10>
So I figured it was all sort of related
<rembo10>
Basically if I'm developing, I want to have a rock solid way to access the device
<rembo10>
So I thought g_ether/dwc2 would be a good solution
<rembo10>
Then I was having trouble with suspend
<rembo10>
So I thought it was all related
stikonas has quit [Remote host closed the connection]
<rembo10>
Then I ended up down this rabbit hole
stikonas has joined #linux-rockchip
<rembo10>
Like the google searches I was doing would result in like 4 results :-D and 3 out of those 4 would just be the source code with the error message
kevery has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
kevery1 is now known as kevery
indy has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<rembo10>
mmind00: thanks so much for your help... I'm going to keep chipping away at this
<mmind00>
rembo10: glad if I can be of help ... good luck at the next steps :-)
<rembo10>
I guess the usb issues are unrelated to the tee stuff....
<rembo10>
Thanks
vagrantc has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
matthias_bgg has quit [Quit: Leaving]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
warpme__ has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 has joined #linux-rockchip
kevery1 is now known as kevery
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
kevery1 has joined #linux-rockchip
lopsided98 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #linux-rockchip
mx08 has joined #linux-rockchip
CounterPillow has quit [Remote host closed the connection]
mx08 has quit [Ping timeout: 265 seconds]
CounterPillow has joined #linux-rockchip
mx08 has joined #linux-rockchip
RayyanAnsari[m] has quit [Ping timeout: 265 seconds]
maxim[m] has quit [Ping timeout: 265 seconds]
RayyanAnsari[m] has joined #linux-rockchip
maxim[m] has joined #linux-rockchip
archetyp has quit [Quit: Leaving]
<macc24>
mmind00: do you know anything about mmc being broken on rk3399?
macc24 has quit [Quit: Ping timeout (120 seconds)]
macc24 has joined #linux-rockchip
lopsided98 has quit [*.net *.split]
vagrantc has quit [*.net *.split]
CounterPillow has quit [*.net *.split]
chewitt has quit [*.net *.split]
rembo10 has quit [*.net *.split]
norris has quit [*.net *.split]
robmur01 has quit [*.net *.split]
diederik has quit [*.net *.split]
dvergatal has quit [*.net *.split]
dliviu has quit [*.net *.split]
UndrWater has quit [*.net *.split]
anarsoul has quit [*.net *.split]
kilobyte_ch has quit [*.net *.split]
s1b1 has quit [*.net *.split]
maz has quit [*.net *.split]
urja has quit [*.net *.split]
warpme__ has quit [*.net *.split]
bitstuff has quit [*.net *.split]
Esmil has quit [*.net *.split]
jakllsch has quit [*.net *.split]
leming has quit [*.net *.split]
cyrozap has quit [*.net *.split]
phh has quit [*.net *.split]
mort has quit [*.net *.split]
smaeul has quit [*.net *.split]
hl has quit [*.net *.split]
kevery has quit [Ping timeout: 252 seconds]
kevery1 has joined #linux-rockchip
<mmind00>
macc24: not really ... I don't remember anything changing recently ... though I'm netbooting boards in my boardfarm ... what behaviour do you see?