<javier__>
bgamari-: sorry, I missed the notification
<javier__>
but I see that Wizzup already replied
<bgamari->
javier__, no worries
<javier__>
and no, I've no idea what could be the cause of the issue
<bgamari->
I'll see if I can reproduce your result of being able to boot with a userspace governor
<javier__>
bgamari-: cool
<bgamari->
javier__, I'm afraid I don't have any JTAG hardware capable of talking with this thing so if this isn't something simple I'll just have to drop it
<javier__>
bgamari-: you can solder a USB to serial TTL cable to the Chromebook UART pins if you have soldering skills
<bgamari->
Well, I have a serial console
<bgamari->
that's how I know where it failed in boot
<bgamari->
javier__, this is an odroid xu4
<javier__>
bgamari-: oh, sorry I thought you had a peach pi
<bgamari->
I fear that I may be running into the secure CCI issue
<bgamari->
but it's not clear
<javier__>
mmm, right
<bgamari->
unfortunately it seems like the HardKernel folks are about as responsive as a brick wall
<javier__>
bgamari-: do you have a branch somehwere? I can give a try too on my peach pi that has a much saner firmware
<bgamari->
Wizzup, Is there an easy way to determine the core voltage?
<bgamari->
That would be a good explanation
<Wizzup>
I am afraid I don't know
Gottox has quit [Ping timeout: 246 seconds]
<bgamari->
ahh, very likely not in fact
Gottox has joined #linux-exynos
<bgamari->
Wizzup, thanks!
<bgamari->
I never added the supply to the xu4 devicetree
<Wizzup>
I thought of it because javier__'s ML also mentioned voltage of '-1'
<bgamari->
hmm, indeed vdd_arm doesn't seem to budge
<bgamari->
according to /sys/class/regulator/regulator.40/microvolts
<bgamari->
ls
<bgamari->
ahh, alreight
<bgamari->
[ 2.135304] cpu cpu0: Looking up cpu-cluster.1-supply from device tree
<bgamari->
[ 2.135321] cpu cpu0: Looking up cpu-cluster.1-supply property in node /cpus/cpu@0 failed
<bgamari->
well that's not good
* Wizzup
needs to sleep <-- back later at some point
<bgamari->
as do I
<bgamari->
sadly
<Wizzup>
3:30 isn't a time to be up anymore :)
<bgamari->
heh, it's the same time here
<bgamari->
small world ;)
<bgamari->
g'night
<Wizzup>
nn
EmilMedve has quit [Quit: Leaving.]
EmilMedve has joined #linux-exynos
ssvb has quit [Ping timeout: 250 seconds]
amitk has joined #linux-exynos
zombah has joined #linux-exynos
ssvb has joined #linux-exynos
gordan has joined #linux-exynos
gordan_ has joined #linux-exynos
gordan has quit [Ping timeout: 245 seconds]
gordan__ has joined #linux-exynos
gordan__ is now known as gordan
gordan_ has quit [Ping timeout: 260 seconds]
EmilMedve has quit [Quit: Leaving.]
afaerber has joined #linux-exynos
<bgamari->
Hmm
<bgamari->
It seems that CPUs 0..3 are in cluster 1 whereas 4-7 are in 0
<bgamari->
javier__, is that as surprising to you as it is to me?
<gordan>
If you disabled the bL scheduler, then yes, that sounds correct.
<gordan>
CPUs 0-3 are the fast ones, 4-7 are the slow ones.
<gordan>
The slow ones are about 35% of performance of the fast ones.
<gordan>
Lopsided 8-core configuration is handy for big compile jobs that take hours and build in parallel most of that time.
<gordan>
Otherwise stick with bL switcher.
<Wizzup>
gordan: I think he meant that 0..3 should be cluster 0
<gordan>
Does numbering really matter in any way?
<bgamari->
ugh
<bgamari->
Wizzup, right
<bgamari->
gordan, currently 4-7 are the fast ones
<bgamari->
doh
<bgamari->
rather 0-3 are the fast ones
<gordan>
That's weird. What kernel are you running?
<bgamari->
but are in cluster 1
<bgamari->
4.4-rc3
<bgamari->
What frequency units are supposed to be in use in drivers/cpufreq/arm_big_little.c
<gordan>
Wasn't there a Global Task Scheduler thingy in the Linaro kernel branch that has some support for clever scheduling with awareness in the core assymetry?
<bgamari->
This is mainline
<gordan>
Sure, but what is your actual objective?
<bgamari->
gordan, to bring up cpufreq on Exynos 5420
<gordan>
I hadn't realized that frequency scaling doesn't work already.
<bgamari->
gordan, There is no support for cpufreq in 5420
<bgamari->
It does not for the dual-cluster chips
<bgamari->
as far as I know
<bgamari->
there was a patch set
<bgamari->
which was dropped
<bgamari->
never merged
<gordan>
See, I never noticed that. The battery just seems to last forever anyway.
<bgamari->
This is what I am working on
<bgamari->
well, if you run a mainline kernel then this is because you are stuck at 800MHz
<bgamari->
unless your bootloader configures things otherwise
<gordan>
Possibly haven't noticed because instead of just scaling down it moves to the slow A7 cores and switches off the A15 cores completely. Which is sort of like frequency scaling.
<gordan>
I'm pretty sure my Peach Pi runs at more than 800MHz under load.
<gordan>
On the fast cores.
<bgamari->
gordan, I'm just saying what I have observed on my XU4
<bgamari->
javier__, there seems to be some inconsistency in the frequency units in arm_big_little.c
<gordan>
Hang on, so on the XU4 even under load and with the bL scheduler you are topping out at 800MHz??
<bgamari->
unless we are trying to run the core at 1.8MHz ;)
<bgamari->
gordan, if cpufreq is to be believed, yes
<gordan>
I can't believe it's running at 800MHz because compiling stuff is damn quick.
<gordan>
Far quicker than it has any right to be if it was running at 800MHz.
<gordan>
How are you checking?
<bgamari->
this is the state that cpufreq finds the core in when it initializes
<bgamari->
cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 800000 KHz
<amitk>
bgamari-: Is this a 5420 and 5422 ?
<bgamari->
amitk, whatever is in the xu4
<bgamari->
I'm afraid I can't check at the moment
<amitk>
I suspect it is a 5422 since 5420 won't ever show all 8 cores with mainline (w/o some samsung secret sauce)
<amitk>
xu4 has the same chip as xu3, IIRC - a 5422 with a locked down firmware
<gordan>
That's a good point, didn't 5420 have a bug in it that made showing all 8 cores unsafe due to cache races?
<amitk>
gordan: correct
<amitk>
even the 5422 has some issues (depending on what you want to do with it). It ships with a locked down stage 1 bootloader that prevents writing to the CCI. So the kernel can't use cpuidle to turn off a cluster
<amitk>
the 5800 in the chromebook is a rebadged 5422 with google firmware that doesn't have this limitation
<gordan>
Interesting, good to know.
<amitk>
it should be OK to use it for cpufreq, though.
<bgamari->
amitk, I see
<amitk>
bgamari-: but you won't be able to get the cluster to shutoff
<bgamari->
ahh
<amitk>
bgamari-: this is my experience with xu3. I had no reason spend money on the xu4 since I was told it was identical. So you might want to confirm that.
<daniels>
bgamari-: you're right that it is a 5422 and that the clusters are reversed
<daniels>
bgamari-: eventually i gave up on the concept of the odroids and moved to rockchip
<amitk>
daniels: me too, xu3 and xu4 aren't useful for serious kernel work in many respects (and hi!)
<daniels>
amitk: o/
<daniels>
amitk: long time!
<amitk>
daniels: not hacking on X/wayland anymore? Or is HW enablement just a pastime?
<bgamari->
daniels, I see
<bgamari->
daniels, I am also close to giving up on the odroids
<bgamari->
daniels, but thanks for the reference
<daniels>
amitk: heh, not x11 for years now! still wayland a bit, but have spent a lot of time in kms & misc hw enablement this year
<amitk>
daniels: cool..
<daniels>
bgamari-: no problem, sorry it's not more rosy news - the separate cpuidle/regulator/cluster/fan series were all picked from linux-samsung-soc; not sure if they did eventually get upstream or not
<daniels>
bgamari-: you can ignore the mali bits if you want
<bgamari->
daniels, I'm pretty sure they didn't
<bgamari->
daniels, what hardware are you using now?
<daniels>
bgamari-: radxa rock2
EmilMedve has joined #linux-exynos
<javier__>
bgamari-: sorry, I'm busy this morning and not paying too much attention to irc
<javier__>
the ARM b.L CPUidle generic driver can be used for Exynos5420/5422/5800 but as amitk said, the firmware should leave in a mode that the kernel MCPM support can write to the CCI
<javier__>
which is not the case on Odroids...
<bgamari->
javier__, no worries
<bgamari->
javier__, right, I'm still trying to get in touch with the odroid folks
<javier__>
and yes, for some reason the Odroids have the cores reversed
<bgamari->
but my luck with them hasn't been terribly great in the past
<bgamari->
javier__, odd
<javier__>
AFAIU is not something specific to Exynos5422 but rather the firmware in the only available dev boards with 5422
<bgamari->
As far as I can tell cpufreq measures frequency in kHz
<bgamari->
javier__, do you know whether this is true?
<bgamari->
there seems to be some inconsistency somewhere
<sjoerd>
javier__: I suspect it must be rom, given it's the boot cpu that's different as well (e.g. a7 on odroid xu3, a15 on chromebook)
<amitk>
javier__: correct, the chromebooks show that this can obviously be done in the correct way, but we've had no luck getting anything out of samsung on this front
<sjoerd>
javier__: well rom, "hardware"
ssvb has quit [Ping timeout: 250 seconds]
<javier__>
sjoerd: right
<amitk>
javier__: did you anything come out of the effort to try to fix the situation (someone at Samsung Poland, IIRC was looking into it)
<javier__>
sjoerd: I meant that in theory there could be Exynos5422 with a different cluster number for the A7 and the A15
<javier__>
amitk: unfortunately it seems that there was not a lot of progress due lack of documentation...
<bgamari->
javier__, at this point things are failing with
<bgamari->
[ 10.021068] :[ 10.028098] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 1, Found OPP: 1800 kHz, 1250000 uV
<javier__>
yeah, I know that is strange but that how it is...
<amitk>
javier__: no, it isn't strange at all ;)
<bgamari->
1800kHz looks quite odd
<javier__>
amitk: hehe, fair
<daniels>
bgamari-: heh, opp changed units?
<amitk>
javier__: you're just not working in Ring 0 of the organisation ;)
<bgamari->
it would seem that way
<daniels>
because 1800MHz is the top freq
<daniels>
*top achievable
<javier__>
amitk: indeed :)
<sjoerd>
javier__: it's the odroid using secure mode where you have to talk to the secure firmware for a load of stuff isn't it ? as opposed to chromebooks where linux can just twiddle the world
<amitk>
sjoerd: basically, but the silly part is that odroid isn't meant to be a secure product
<javier__>
sjoerd: yes, which is silly for a dev platform
<sjoerd>
I tried telling the bl{1,2} blobs that but they wouldn't listen
<sjoerd>
stubborn little things
* sjoerd
would be very happy if a magic bl1 would appear to turn of the security bits
<bgamari->
javier__, do you know why they insist on secure mode?
<amitk>
"someone implemented it for a product, they reused it for a devboard" is my guess
<javier__>
bgamari-: I agree with amitk
<javier__>
have to leave again, I'll be online again after lunch
<bgamari->
javier__, no worries
ssvb has joined #linux-exynos
zombah has quit [Quit: Leaving]
Tenkawa has joined #linux-exynos
<Tenkawa>
hi all
<Tenkawa>
the new kernel is working well :)
<Wizzup>
:)
<Tenkawa>
went with the 4.3.0 one
<Wizzup>
good choice
Tenkawa has quit [Remote host closed the connection]
EmilMedve has quit [Quit: Leaving.]
<javier__>
bgamari-: hi, I'm looking at your patches now
<javier__>
bgamari-: your "Move to operating-points-v2" patch doesn't look correct to me
<javier__>
bgamari-: AFAICT OPPv1 operating-points property freq is specificed in kHz while OPPv2 table specifies it in Hz
<javier__>
but you just copied the values from one to the other without doing the conversion
<javier__>
bgamari-: ah, sorry. I see that you changed it in a later patch "Clarify units"
<javier__>
bgamari-: I don't have access to my peach pi now but I'll test the patches later
<bgamari->
javier__, ahh
<bgamari->
alright
<bgamari->
javier__, thanks again!
<bgamari->
javier__, indeed I did
<bgamari->
I'll need to squash some of the history away
<bgamari->
sorry for the sad state of the history
<javier__>
bgamari-: no worries, I just tried your patches without success
<bgamari->
javier__, what sort of no success?
<javier__>
bgamari-: peach pi hangs on boot with exynos_defconfig + b.L switcher disabled + CPUFreq options (for now only user space governor since that worked for me before)
<javier__>
unfortunately I don't have a serial console soldered on this machine yet to get more info
<bgamari->
javier__, alright
<bgamari->
I'll be continuing to dig in tonight
<javier__>
bgamari-: you said that userspace governor at least made the Odroid to boot right? but then hang when scaling frequencies?
<javier__>
bgamari-: I've an Odroid XU4 here as well, I've test there
<javier__>
*I'll
<bgamari->
Not anymore
<bgamari->
it now actually fails at boot
<javier__>
bgamari-: cool, at least is consistent which is good
<javier__>
and with the XU4 I've a serial console to get more info
<bgamari->
This is what I now see
<bgamari->
[ 10.021068] :[ 10.028098] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 1, Found OPP: 1800 kHz, 1250000 uV
<bgamari->
Which would appear to be another unit issue
<bgamari->
yet I'm pretty sure my devicetree is up to date
<javier__>
yeah, I don't know how good was the idea to mix units for the different OPP DT binding versions...
<bgamari->
heh
<javier__>
bgamari-: anyway, I'll test on my XU4 later and let you know if I find anything
<bgamari->
javier__, thanks!
<javier__>
bgamari-: shouldn't you have a operating-points-v2 in the CPUs dev nodes in arch/arm/boot/dts/exynos5422-cpus.dtsi ?
<javier__>
bgamari-: otherwise the A15 will have the OPP table of the A7 and vice versa
<bgamari->
hmm
<bgamari->
that's a lovely question
<bgamari->
oh dear
<javier__>
bgamari-: arch/arm/boot/dts/exynos5420.dtsi defines the CPU's and the OPP tables and later the CPUs are overriden on the exynos5422-cpus.dtsi but the OPP table will be the old one
Tenkawa has joined #linux-exynos
<Tenkawa>
more and more tweaking done :)
<bgamari->
I see that
<bgamari->
now
<bgamari->
sounds plausible
<bgamari->
I'm still not sure how it would result in the issue I'm seeing
<bgamari->
but I'll certainly try changing it
<javier__>
bgamari-: I didn't mean that, I just wanted to point out that it is currently wrong :)
<bgamari->
sure
<bgamari->
thanks for pointing that out
<javier__>
yw
<javier__>
bgamari-: I expect to only be a problem if you try to scale to the max an min values
<javier__>
*and
Tenkawa has quit [Remote host closed the connection]
prahal____ has joined #linux-exynos
Vasco_O is now known as Vasco
gordan has quit [Quit: Konversation terminated!]
ssvb has quit [Ping timeout: 260 seconds]
afaerber has quit [Quit: Ex-Chat]
<javier__>
bgamari-: I think the WARN on bL_cpufreq_set_rate_cluster (which is caused by a fail in clk_set_rate) is a red herring
<javier__>
bgamari-: it seems that what is causing the kernel to panic is the BUG on cpufreq_online()
<javier__>
bgamari-: which is caused by cpufreq_frequency_table_get_index() returning an unknown frequency
<javier__>
now... the freq is 800000 KHz which is in the OPP tables (for both A7 and A15) so that's strange
ssvb has joined #linux-exynos
zombah has joined #linux-exynos
afaerber has joined #linux-exynos
<javier__>
bgamari-: so the problem is at the end a unit mismatch indeed
<javier__>
the problem is that cpufreq_frequency_table_get_index() was iterating over the operating points frequencies (in kHz) and comparing with the freq in Hz
<javier__>
I also included the changes to exynos5422 OPP tables as discussed before
<javier__>
bgamari-: now, that patch is wrong since the reported frequencies in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies reports the freqs in kHz
<javier__>
bgamari-: so the problem seems to be that frequencies in the cpufreq table is in kHz instead of Hz
<javier__>
I have to leave for today but tomorrow I can take a better look to the CPUFreq framework to understand what's going on