dlan has quit [Ping timeout: 260 seconds]
<bgamari-> javier__, ugh, well I managed to rebase the cpufreq patches
<bgamari-> hangs on boot shortly after attempting to initialize cpufreq
dlan has joined #linux-exynos
<Wizzup> is that not what javier__ posted?
<Wizzup> the problem he experienced*
<javier__> bgamari-: I was about to ask the same
<bgamari-> Wizzup, javier__, in the original thread?
<javier__> I got boot hangs for certain CPUFreq governors
<javier__> yes
<bgamari-> sounds like it then
<bgamari-> I dnd't see your message
<bgamari-> hmm
<bgamari-> javier__, approximately when was this thread?
<bgamari-> javier__, I've looked back to v9 of Thomas's original patch but can't find your reply
<bgamari-> Are there any theories on why this might be happening?
<Wizzup> 15:56 < javier__> bgamari-: btw, I also had issues with Bart's v1 CPUfreq patches https://lkml.org/lkml/2015/5/15/544
<bgamari-> ahh, v1
<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-> javier__, yep
<javier__> bgamari-: awesome, I'm about to leave for today but I'll give a try tomorrow
<bgamari-> Great, thanks!
<bgamari-> It's really appreciated
<bgamari-> in the meantime I'll see if I can at least get the thing to boot with usermode regulator
<bgamari-> that would at least make debugging a bit less painful
<javier__> bgamari-: Ok
<javier__> I've my morning tomorrow quite busy but I'll test it for sure after lunch
<javier__> leaving for today, bye!
<bgamari-> javier__, have a nice night!
<javier__> bgamari-: thanks, you too!
meridion has quit [Ping timeout: 244 seconds]
<bgamari-> javier__, indeed it looks like that worked
<bgamari-> javier__, userspace regulator allows the machine to boot
<bgamari-> hmm, oh dear
<bgamari-> [ 2.226235] cpu cpu0: failed to get cpu0 clock: -2
<bgamari-> [ 2.230800] cpufreq-dt: probe of cpufreq-dt failed with error -2
meridion has joined #linux-exynos
meridion has quit [Ping timeout: 260 seconds]
meridion has joined #linux-exynos
EmilMedve has joined #linux-exynos
<bgamari-> javier__, I've pushed an update branch FYI
<bgamari-> Well, fixing a rebase mistake eliminated that error
<bgamari-> Unfortunately now it hangs on boot again
<bgamari-> slightly later than it did previously
<bgamari-> strangely enough only slightly before getty is started
<bgamari-> Sadly it seems to be quite hung with no output on the serial console
<bgamari-> ahh, actually...
<bgamari-> [ OK ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
<bgamari-> Starting LSB: set CPUFreq kernel parameters...
<bgamari-> shortly after that
<bgamari-> which I suppose makes sense
<bgamari-> well, at least it's trying to set up scaling
<bgamari-> even if it goes down in flames
<bgamari-> indeed knocking out that init job allows the machine to boot
<bgamari-> Seems it's currently running at only 800MHz, so my suspicion that it isn't running at full-speed appears to be well-founded
<bgamari-> cpufreq-set -c0 -f900M doesn't appear to result in an immediate crash
<bgamari-> 1000M, 1200M, and 1400M also appear to be okay
<bgamari-> ahh, but a few switches back and forth then result in
<bgamari-> [ 246.879459] Unhandled fault: dcache parity error (0x408) at 0x00000000
<bgamari-> [ 246.884501] pgd = c0004000
<bgamari-> looks like 1600M is pretty unstable
<Wizzup> (stupid question) does the voltage scale with the freq
<bgamari-> [ 196.818712] Unhandled prefetch abort: unknown 25 (0x409) at 0xc008c6a8
<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> It doesn't auto-scale?
<bgamari-> gordan, I'm sorry?
<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-: if you're really motivated, you might want to pick up the piles of cpufreq/cpuidle/regulator bits in https://git.collabora.com/cgit/user/daniels/linux.git/log/?h=tmp/lfrb - that worked for me on an xu3
<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
<bgamari-> [ 10.037310] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 1, 800 MHz, 1025 mV --> 1 MHz, 1250 mV
<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-> [ 10.037310] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 1, 800 MHz, 1025 mV --> 1 MHz, 1250 mV
<bgamari-> [ 10.047371] ------------[ cut here ]------------
<bgamari-> [ 10.051930] WARNING: CPU: 6 PID: 1 at drivers/cpufreq/arm_big_little.c:189 bL_cpufreq_set_rate_cluster+0x2f4/0x3a8()
<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__> bgamari-: the following naive patch makes both XU4 and Peach Pi to boot http://hastebin.com/akucajecur.xml
<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
Vasco is now known as Vasco_O
<bgamari-> javier__, brilliant
<bgamari-> javier__, back from dinner
prahal____ has left #linux-exynos [#linux-exynos]
prahal____ has joined #linux-exynos
prahal____ has quit [Ping timeout: 260 seconds]
prahal____ has joined #linux-exynos
zombah has quit [Ping timeout: 260 seconds]
Turl has joined #linux-exynos
zombah has joined #linux-exynos
zombah has quit [Client Quit]