2024-10-01 14:28:41 <mps> I've got opensbi+u-boot built from source on alpine to work \o/
2024-10-01 14:29:01 <mps> for spacemit SoC
2024-10-01 15:20:24 <ncopa> congrats! Awesome!
2024-10-01 16:00:31 <mps> ncopa: thanks. But we will have again to 'play' with their sources
2024-10-01 17:01:14 <mps> and this is what I use as APKBUILD for opensbi-spacemit
2024-10-01 17:01:27 <mps> have no better idea for now
2024-10-01 19:12:12 <mps> >>> ERROR: u-boot-spacemit: 2022.10_2.0 is not a valid version
2024-10-01 19:12:16 <mps> why?
2024-10-01 19:12:53 <ikke> The _ is not valid there
2024-10-01 19:13:51 <ikke> The _ can only be used to separate a pre or post suffix
2024-10-01 19:13:55 <mps> same is with 2022.10-2.0
2024-10-01 19:13:58 <ikke> https://gitlab.alpinelinux.org/alpine/go/-/blob/master/version/doc.go?
2024-10-01 19:14:38 <ikke> only 2022.10.2.0 would be valid
2024-10-01 19:14:40 <mps> ah like I did with mesa-asahi
2024-10-01 19:14:58 <mps> mesa-asahi-24.3.0_pre20240930-r0
2024-10-01 19:15:09 <ikke> that is valid indeed
2024-10-01 19:15:34 <mps> hm, have to contemplate about this
2024-10-01 19:16:15 <ikke> What does that specific version mean?
2024-10-01 19:16:22 <ikke> 2nd release of october 2024?
2024-10-01 19:16:45 <mps> tag in gitlab
2024-10-01 19:16:59 <ikke> sure, just trying to understand the version scheme
2024-10-01 19:17:03 <mps> https://gitlab.freedesktop.org/asahi/mesa/-/tags
2024-10-01 19:17:45 <mps> ah, you mean for u-boot-spacemit?
2024-10-01 19:17:55 <ikke> yes
2024-10-01 19:18:00 <mps> it is branch 'bl-v2.0.y'
2024-10-01 19:18:18 <ikke> bl is baseline?
2024-10-01 19:18:30 <mps> could be
2024-10-01 19:18:50 <mps> upstream is not open source friendly
2024-10-01 19:19:33 <mps> to see commits on their repo you must register account or use google account
2024-10-01 19:19:38 <ikke> anoying
2024-10-01 19:20:38 <mps> but I 'promised' to clandmeter that I will try to make all this for bpi f3 and I want to finish
2024-10-01 19:20:40 <ikke> I'd mirror it somewhere public
2024-10-01 19:21:15 <mps> like ncopa did with linux-spacemit kernel?
2024-10-01 19:23:11 <ikke> He rebased the commits iirc
2024-10-01 19:23:44 <mps> yes
2024-10-01 19:39:21 <mps> for now I will go with 2022.10.2.0
2024-10-01 19:48:12 <mps> by blind trying I see tar.gz could be downloaded from their repo
2024-10-01 19:48:43 <mps> it is very nuce that my crystal ball still works fine ;)
2024-10-01 19:48:52 <ikke> heh
2024-10-02 10:59:21 <mps> anyone have bpi f3 running with linux-spacemit kernel? source "$(OPENSBI_SRC_DIR)/lib/sbi/Kconfig"
2024-10-02 10:59:24 <mps> source "$(OPENSBI_SRC_DIR)/lib/sbi/Kconfig"
2024-10-02 10:59:26 <mps> 21:17 ......... mps| https://gitlab.freedesktop.org/asahi/mesa/-/tags
2024-10-02 10:59:26 <mps> 21:17 ......... mps| https://gitlab.freedesktop.org/asahi/mesa/-/tags
2024-10-02 10:59:28 <mps> source "$(OPENSBI_SRC_DIR)/lib/sbi/Kconfig"
2024-10-02 10:59:31 <mps> source "$(OPENSBI_SRC_DIR)/lib/sbi/Kconfig"
2024-10-02 10:59:32 <mps> huh
2024-10-02 10:59:52 <mps> I hate touchpads
2024-10-02 11:05:12 <mps> wanted to ask what is load on bpi f3 with latest linux-spacemit kernel
2024-10-02 11:05:22 <mps> anyone can check
2024-10-02 11:15:52 <ikke> I still need to install mine. Maybe this evening. But need to liberate an sdcard 
2024-10-02 11:19:03 <mps> ok, noticed it uptime never goes below 1.00 in my case, while with old kernel locally build it is mostly 0.00
2024-10-02 11:22:52 <ikke> You mean load?
2024-10-02 11:24:09 <mps> load, yes
2024-10-02 11:54:46 <ncopa> alpine-bpi-f3:~# uptime
2024-10-02 11:54:46 <ncopa>  11:54:34 up 6 days, 17:54,  0 users,  load average: 8.04, 8.11, 7.91
2024-10-02 11:54:54 <ncopa> Linux alpine-bpi-f3 6.6.52-2-spacemit #3-Alpine SMP 2024-09-25 16:59:27 riscv64 Linux
2024-10-02 11:55:15 <ncopa> but it is also building qemu currently
2024-10-02 11:55:21 <mps> I've guess because linux-spacemit have CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y instead of CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
2024-10-02 11:56:17 <mps> I know you like SCHEDUTIL but I told few times it is not good choice
2024-10-02 11:56:41 <ncopa> you can change it?
2024-10-02 11:56:50 <mps> yes
2024-10-02 11:56:55 <ncopa> to test if that is the case
2024-10-02 11:57:21 <mps> now I'm testing apks of opensbi and u-boot
2024-10-02 11:58:03 <mps> will test later, probably at evening. for now just wanted to ask if someone can confirm this load
2024-10-02 11:59:19 <mps> ncopa: btw do you have time to review opensbi and u-boot APKBUILDs, can paste them. they are not big
2024-10-02 12:07:34 <mps> here is the opensbi-spacemit https://tpaste.us/XvEv
2024-10-02 12:08:23 <mps> and u-boot-spacemit is here https://tpaste.us/Lyv4
2024-10-02 12:36:35 <ncopa> mps: looks like they are good enough to push to testing
2024-10-02 12:37:39 <mps> thanks for review
2024-10-02 12:49:56 <ncopa> re gov schedutil, I use that to utilize modenr CPU's capability to scale down the freqency
2024-10-02 12:50:01 <ncopa> to save energy
2024-10-02 12:50:36 <ncopa> i dont like waste resources
2024-10-02 12:51:44 <mps> schedutil will be fixed in 6.12 to work fine, for now it is 'not so'. because this I use conservative to save energy
2024-10-02 12:52:11 <ncopa> i havent seen any doc explaing the problem with schedutil?
2024-10-02 12:52:44 <ncopa> schedutil is supposed to be balanced. get the freq up under load, and take it down again when cpu is idle
2024-10-02 12:52:51 <mps> also I didn't, but talk on different channels persuades me
2024-10-02 12:53:10 <mps> and experience
2024-10-02 12:54:02 <ncopa> what does not work fine with schedutil in your experience?
2024-10-02 12:55:08 <mps> less battery and somewhat higher load
2024-10-02 12:55:54 <mps> try to change to conservative on bpi f3 and check
2024-10-02 12:58:11 <mps> it should be 0.00 if not some intensive program runs
2024-10-02 12:58:46 <mps> with hostapd it is mostly 0.00 in my case
2024-10-02 13:55:36 <ncopa> not sure if load is a good measure nowaday
2024-10-02 13:56:17 <ncopa> not really sure how it works, but as I understand it is amount of work relative available CPU
2024-10-02 13:57:51 <mps> yes, you are right
2024-10-02 13:58:15 <mps> maybe call it 'cpu utilization'
2024-10-02 13:58:34 <ncopa> if you for example have close to no work to do. lets say it is 0.001 when cpu freq is at 100%
2024-10-02 13:58:56 <ncopa> which would be rounded to 0.00
2024-10-02 13:59:15 <ncopa> then you reduce the CPU freq, the CPU speed
2024-10-02 13:59:32 <ncopa> to 10%
2024-10-02 14:00:13 <ncopa> then load will tell you that you would need 10 times more CPU power to do the same amount of work
2024-10-02 14:00:33 <ncopa> and load will show you 0.010 (rounded to 0.01)
2024-10-02 14:00:46 <ncopa> even if it is the exact same amount of work
2024-10-02 14:00:49 <ncopa> no?
2024-10-02 14:00:58 <mps> there is 'sugov' kernel thread which is very active with schedutil, could be bug in some of patches for spacemit
2024-10-02 14:01:17 <ncopa> but i am not convinced it is a problem
2024-10-02 14:01:55 <mps> so, if this thread runs constantly you have 1.00 load
2024-10-02 14:02:13 <ncopa> 1.00 load means you use all CPU power
2024-10-02 14:02:31 <mps> 1.00 is one cpu
2024-10-02 14:02:37 <ncopa> it means you use CPU 100%
2024-10-02 14:02:39 <mps> not all 8
2024-10-02 14:03:42 <mps> you can easily create program which runs on one cpu to check this
2024-10-02 14:04:09 <mps> not use sleep in loop
2024-10-02 14:04:16 <ncopa> what i know for sure is that CPU gov "performance" will set up the speed to max, regardless if there is work to do or not
2024-10-02 14:04:33 <mps> yes
2024-10-02 14:05:00 <ncopa> like pressing the gas pedal down to bottom in a car, regardless if you move fast, slow or stand still
2024-10-02 14:05:58 <mps> cpu freq will be max but that doesn't mean that cpu work intensive task, they have 'halt' mode (from my memory from I486 times)
2024-10-02 14:06:11 <ncopa> exactly
2024-10-02 14:06:30 <ncopa> you press the gas pedal down to the bottom, even if the car stand still
2024-10-02 14:07:00 <ncopa> engine runs super fast, even if car is not moving
2024-10-02 14:07:01 <mps> comparison is not good in this case
2024-10-02 14:07:39 <mps> cpu clock is max, but most of the cpu is idle
2024-10-02 14:08:31 <mps> and when it is in some kind of 'sleep'
2024-10-02 14:08:45 <mps> or better say 'snooze'
2024-10-02 14:09:20 <ncopa> it does wake up regularily to do maintence tasks, like updating the clock, respond to IRQ
2024-10-02 14:09:28 <ncopa> to do very light work
2024-10-02 14:09:57 <mps> yes, and one cpu is enough for this
2024-10-02 14:10:23 <ncopa> one cpu is enough, and it does not need full speed to do it
2024-10-02 14:10:27 <ncopa> lower freq works fine
2024-10-02 14:10:31 <ncopa> and saves energy
2024-10-02 14:10:31 <mps> right
2024-10-02 14:10:34 <ncopa> thats the idea at least
2024-10-02 14:11:05 <ncopa> but if it is broken that is ofc not good
2024-10-02 14:11:20 <mps> yes, even if cpu is 'snoozing' higher clock use more energy than low freq
2024-10-02 14:11:23 <ncopa> but i dont think looking at 'load' is a good indication that something is broken
2024-10-02 14:12:02 <mps> higher load than expected is sign that something is wrong
2024-10-02 14:12:44 <ncopa> but what i try to say is that it will give higher 'load' number for the exact same amount of work
2024-10-02 14:12:49 <ncopa> when freq is low
2024-10-02 14:12:52 <ncopa> vs high
2024-10-02 14:13:05 <ncopa> higher 'load' does not mean it has more work to do
2024-10-02 14:13:21 <mps> try `echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor` on bpif3 and you will see
2024-10-02 14:13:22 <ncopa> as it is relative the capacity of the CPU
2024-10-02 14:13:49 <mps> higher load means that it works on something
2024-10-02 14:13:58 <ncopa> yes
2024-10-02 14:15:05 <mps> in /sys/devices/system/cpu/cpufreq/policy0/ are some files with which you can 'play' to see
2024-10-02 14:15:11 <ncopa> but if the load shows 0.001 on 100% cpu freq, and you reduce cpu freq with 90%, the exact same amount of work will sho load '0.01'. It looks like load is 10 times more
2024-10-02 14:15:23 <ncopa> while you in fact only have 1/10 CPU capacity
2024-10-02 14:15:26 <mps> right
2024-10-02 14:15:26 <ncopa> its a relative number
2024-10-02 14:15:50 <ncopa> so I'm not convinced it is a problem
2024-10-02 14:16:03 <mps> no, freq and load not much related (on same cpu)
2024-10-02 14:16:22 <ncopa> then I misunderstand
2024-10-02 14:16:37 <mps> freq is only 'capability' while load is real usage
2024-10-02 14:17:59 <mps> if you have one process or thread spinning constantly you will have load of 1.00 independent of freq (not exactly this but I think you understand)
2024-10-02 14:19:18 <ncopa> yup
2024-10-02 14:19:28 <mps> TBH I didn't examined much of this on modern cpus, but this is principle
2024-10-02 14:20:26 <mps> more than 30 years passed when I had work deeply with such problems and solutions
2024-10-02 14:21:02 <mps> but I'm sure that high freq doesn't mean high load
2024-10-02 14:21:15 <ncopa> yes agree on that
2024-10-02 14:21:22 <ncopa> high freq does not mean high load
2024-10-02 14:21:26 <ncopa> ofc
2024-10-02 14:22:38 <mps> if I use machine for real time I use performance and if on batteries I use conservative, IME best options
2024-10-02 14:22:42 <ncopa> but as I understand it: if you have a specific amount of work, that requires 1Gig cpu clock cycles to complete (lets say xz compress some data)
2024-10-02 14:22:52 <ncopa> and you have 1 cpu core
2024-10-02 14:22:57 <mps> ofc, tried schedutil but always had issue with it
2024-10-02 14:22:58 <ncopa> running at 1Ghz
2024-10-02 14:23:14 <ncopa> the job will take 1 second
2024-10-02 14:23:40 <ncopa> and load will show 1.0
2024-10-02 14:23:46 <mps> no, depends on cpu class, RISC or CISC
2024-10-02 14:24:07 <ncopa> er...
2024-10-02 14:24:30 <ncopa> i give up
2024-10-02 14:24:36 <mps> CISC needs few clocks for one instructions while RISC mostly need one clock for one instruction
2024-10-02 14:24:48 <ncopa> yeah i perfectly know that
2024-10-02 14:24:59 <ncopa> that is why i did not say 1Gig instructions
2024-10-02 14:25:07 <ncopa> i said 1 Gig cycles
2024-10-02 14:25:13 <ncopa> but really i need to do other stuff now
2024-10-02 14:25:17 <ncopa> i give up
2024-10-02 14:25:27 <mps> only one CPU existed which could execute 1.5 instructions per one clock cycle - NC4016
2024-10-02 14:25:38 <mps> ok
2024-10-02 14:25:44 <ncopa> i never talked about instructions in the exacmple but ok
2024-10-02 14:26:06 <mps> all in all I think schedutil is buggy on spacemit
2024-10-02 14:26:08 <ncopa> feel free to set gov to performance of conservative if that is what you need
2024-10-02 14:26:15 <ncopa> file a bug to upstream kernel
2024-10-02 14:26:39 <ncopa> send me the link when kernel devs acknoledge it is a bug
2024-10-02 14:26:44 <mps> bianbu want registration even to see commits :)
2024-10-02 14:27:14 <mps> no, I didn't told that mainline schedutil is buggy
2024-10-02 14:28:19 <mps> some improvements are announced to 6.12 schedutil and I wait release to test it
2024-10-02 14:28:40 <mps> in theory it should be good scheduler
2024-10-02 14:44:07 <ncopa> my friend chatgpt agrees with me: higher load avg when you reduce CPU freq is to be expected due to the way the load is calculated: https://chatgpt.com/share/66fd5b87-0f70-8010-a2c1-78d5f32b4e83
2024-10-02 14:48:43 <mps> ahaha
2024-10-02 14:50:49 <mps> you trust to AI
2024-10-02 14:56:29 <mps> I will stay with my definition - 'cpu utilization'
2024-10-02 14:58:11 <ncopa> relative cpu utilization
2024-10-02 14:58:39 <ncopa> agree
2024-10-02 14:59:35 <mps> no, I can't forge right english term but something like 'cpu utilization of its capacity'
2024-10-02 15:00:51 <mps> 'cpu utilization of its current working capacity'
2024-10-02 15:05:07 <ncopa> so with same amount of work, "load" increases when "current working capacity" goes down due to lower freq.
2024-10-02 15:05:20 <ncopa> but i do have one cpu core running at 100% here
2024-10-02 15:05:56 <ncopa>   PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
2024-10-02 15:05:56 <ncopa>   117     2 root     RW       0   0%   6  12% [sugov:0]
2024-10-02 15:06:06 <ncopa> what is sugov?
2024-10-02 15:06:30 <ncopa> HAHA!
2024-10-02 15:06:37 <ncopa> Sugov is a kernel thread used in ARM architecture as part of the scheduling governor
2024-10-02 15:07:40 <ncopa> which means there actually is a bug related CPU governor 
2024-10-02 15:08:47 <ncopa> how do we report this to bianbu linux?
2024-10-02 15:10:47 <mps> I guess you have to login at https://gitee.com/bianbu-linux/linux-6.1 and create issue report
2024-10-02 15:14:13 <ncopa> gives me 500
2024-10-02 15:14:38 <ncopa> btw, i built the leds heartbeat as module
2024-10-02 15:14:40 <mps> it asks me to login
2024-10-02 15:14:52 <ncopa> when i login or register i get 500
2024-10-02 15:15:05 <ncopa> Linux alpine-bpi-f3 6.6.53-0-spacemit #1-Alpine SMP 2024-10-02 09:48:21 riscv64 Linux
2024-10-02 15:15:12 <ncopa> the leds heartbeat is gone
2024-10-02 15:17:35 <mps> I didn't tried to register, agreement is in chinese so I don't understand it
2024-10-02 15:18:00 <ncopa> im not able to report it
2024-10-02 15:18:02 <ncopa> oh well
2024-10-02 15:18:13 <mps> nice :/
2024-10-02 15:18:27 <mps> ncopa: do you have nvme on bpif3
2024-10-02 15:18:37 <ncopa> i do
2024-10-02 15:19:02 <mps> and you can lower loadavg with changing scheduler?
2024-10-02 15:23:17 <ncopa> when changing it to "performance" it dropped yes
2024-10-02 15:23:36 <ncopa> [sugov:0] is related the cpu scheduler
2024-10-02 15:24:37 <mps> right
2024-10-02 15:24:49 <mps> and even with nvme?
2024-10-02 15:49:44 <mps> ncopa: I pushed opensbi and u-boot for spacemit to builder. now have to change image create script to use our build for them
2024-10-02 15:49:56 <mps> but first will go to walk
2024-10-02 16:55:39 <mps> well, ofc load will go up if freq is low. by 'load' I mean execution will be slower, and not sure for calculated load in /proc/loadavg
2024-10-02 16:56:00 <mps> forget this ^
2024-10-02 16:56:12 <mps> intended for someone else
2024-10-02 17:53:48 <mps> ncopa: here is my updated script to create sd image https://tpaste.us/lbMn
2024-10-02 17:54:18 <mps> it uses now all from our repo
2024-10-02 17:54:43 <ncopa> you dont happen to have a diff?
2024-10-02 17:54:49 <ncopa> nice, very nice
2024-10-02 17:55:23 <mps> note use u-boot.itb instead of u-boot.itb and fw_dynamic.itb instead of fw_dynamic.bin
2024-10-02 17:56:28 <mps> https://tpaste.us/dojW diff but not sure is it correct
2024-10-03 12:08:41 <ikke> I have booted by banapi f3 now as well with ncopas image and tiny-init
2024-10-03 12:08:51 <ikke> For some reason I cannot get the serial console to work
2024-10-03 12:11:17 <ikke> Hmm, does not come back after upgrade
2024-10-03 12:16:08 <ikke> oh, I have serial console n ow
2024-10-03 12:16:56 <ikke> And it received a different IP
2024-10-03 12:25:29 <ncopa> the ip depends on your dhcp server and which port you plug in
2024-10-03 12:41:16 <ikke> Usually it's stable
2024-10-03 12:41:31 <ikke> But I thought it didn't come back because the ip changed
2024-10-03 12:46:02 <ikke> I must say that the fan that came with it is very quiet
2024-10-03 12:46:14 <ikke> initially I didn't even realize it was working
2024-10-03 12:49:15 <ncopa> this is even more quiet: https://fosstodon.org/@ncopa/113231568682842848
2024-10-03 12:49:45 <ikke> What temperatures do you measure?
2024-10-03 12:50:35 <ncopa> 48C currently
2024-10-03 12:50:57 <ikke> Mine is ~39C
2024-10-03 12:51:01 <ncopa> temp was lower with the heatsink than with fan when runnin stress
2024-10-03 12:51:13 <ikke> But I'm not running any load
2024-10-03 12:51:27 <ncopa> mine runs docker and gitlab CI
2024-10-03 12:51:30 <ikke> aha
2024-10-03 13:48:44 <ikke> ncopa: did you manage to disable the leds?
2024-10-03 13:53:35 <mps> ikke: red led can't be disabled
2024-10-03 13:53:43 <ikke> The green one then?
2024-10-03 13:54:25 <mps> add '/etc/local.d/led.start' file
2024-10-03 13:54:45 <mps> and put in it:
2024-10-03 13:54:49 <mps> echo none > /sys/class/leds/sys-led/trigger
2024-10-03 13:55:01 <mps> echo 0 > /sys/class/leds/sys-led/brightness
2024-10-03 13:57:19 <ikke> thanks
2024-10-03 14:51:04 <ncopa> i at least was able to build the hearbeat trigger as module, so it does not blink at least.
2024-10-03 15:57:41 <mps> linux-spacemit need more modularization but some things must be in-kernel. which ones will 'try and see'