Banana Pi M3 (armv7/CortexA7) with head -339076 and u-boot 2018.09_3 from ports: what CPU clock speed is it using? More. . .
Emmanuel Vadot
manu at bidouilliste.com
Thu Oct 4 13:26:28 UTC 2018
Hi,
On Wed, 3 Oct 2018 12:59:13 -0700
Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
> The following leaves me wondering if the switch to linux
> based .dts files and related changes have also invalidated
> some "Supported devices" table entries in
> https://wiki.freebsd.org/FreeBSD/arm/Allwinner . For
> example: cpufreq / DVFS and/or Thermal for some columns.
Not really, see below.
>
> With -r308125 the BPi-M3 would -j4 or -j5 buildworld buildkernel for the
> src.conf settings that I use in about 9.5 hours. (From my 2016-Nov-05
> list E-mail.)
>
> [The BPi-M3 has heat sinks, a case, and a fan.]
>
> I've not done such builds in a long time and I've not recorded times
> when I have. But having updated to -r339076 based and the modern
> 2018.09 u-boot context has the BPi-M3 just finished building
> lib/clang/libclang/AST/ materials after about 19 hours. top
> indicates swap has 1740M Total and Free. (My top modifications
> indicate the Max Observed Active Mem as 922M so far.)
>
> There is a big difference in clang between the two and that
> contributes to taking more time. But, by contrast, the (aarch64
> A64 based) Pine64+ 2GB -j4 buildworld buildkernel for -r338860
> built completely in about 13.75 hours, although it had faster
> media in the microsd card slot (e.MMC on an adapter and used
> in DDR52 mode via experimental changes to allow e.MMC use).
>
> This leaves me wondering if the BPi-M3 clock rate(s) for the
> CPU and/or RAM are set avoiding the upper end of the range
> compared to -r308125's time frame. (This may well be reasonable
> currently.)
>
> Taking a guess at relevant figures from the modern
> BPi-M3 configuration via sysctl -a output:
>
> hw.clock.c1cpux.frequency: 1008000000
> hw.clock.c0cpux.frequency: 1008000000
> . . .
> hw.clock.pll_c1cpux.frequency: 1008000000
> hw.clock.pll_c0cpux.frequency: 1008000000
>
> (I've not figured out anything for DRAM: I ignored
> anything reported as 0 and bus-*.frequency figures.)
There must be something wrong with the DRAM clock since we switch to
the new clock model, someone (tm) should fix this.
> If the current context is without throttling or some
> such, it may be that 1 GHz or so is used to just keep
> things in a safe range: I see no evidence of cpu or such
> temperatures in the sysctl -a output so a feedback loop
> controlling the frequency (and voltages) may not be an
> option currently for the BPi-M3.
>
> However, it is possible the frequency or other behavior
> is unexpected. I can not tell.
There is two problem for cpufreq on BanapiM3
1) The current DTS (from linux 4.18) doesn't have the regulator define
for switching voltage, this is fixed in later version.
2) A83T is a multi cluster ARM cpu, and this cause problem when
switching frequency, I don't know exactly what's happening but removing
the other cluster from the dts and I don't have any problem switching
frequency.
set->dev okay
cpu_get_pcpu
thread_lock
sched_prio
sched_bind
panic: acquiring blockable sleep lock with spinlock or critical section
held (sleep mutex) pmap
@ /usr/home/manu/Work/freebsd/freebsd.git/sys /arm/arm/pmap-v6.c:6496
cpuid = 0 time = 1538658865 KDB: stack backtrace: db_trace_self() at
db_trace_self pc = 0xc05c8b38 lr = 0xc0075d14
(db_trace_self_wrapper+0x30) sp = 0xddbaa890 fp =
0xddbaa9a8 db_trace_self_wrapper() at db_trace_self_wrapper+0x30
pc = 0xc0075d14 lr = 0xc029d418 (vpanic+0x16c)
sp = 0xddbaa9b0 fp = 0xddbaa9d0
r4 = 0x00000100 r5 = 0x00000001
r6 = 0xc06d9038 r7 = 0xc0a90fd8
vpanic() at vpanic+0x16c
pc = 0xc029d418 lr = 0xc029d1f8 (doadump)
sp = 0xddbaa9d8 fp = 0xddbaa9dc
r4 = 0xc06b36e7 r5 = 0xc06d32a9
r6 = 0xc06c560d r7 = 0x00000000
r8 = 0x00001960 r9 = 0xc7086834
r10 = 0x00000000
doadump() at doadump
pc = 0xc029d1f8 lr = 0xc0307c44 (witness_checkorder+0xcd0)
sp = 0xddbaa9e4 fp = 0xddbaaa38
r4 = 0xc029d1f8 r5 = 0xddbaa9e4
witness_checkorder() at witness_checkorder+0xcd0
pc = 0xc0307c44 lr = 0xc02822d0 (__mtx_lock_flags+0xb4)
sp = 0xddbaaa40 fp = 0xddbaaa68
r4 = 0x00000000 r5 = 0x00000000
r6 = 0xc7086844 r7 = 0x00000000
r8 = 0xc7086834 r9 = 0xc06c560d
r10 = 0x00001960
__mtx_lock_flags() at __mtx_lock_flags+0xb4
pc = 0xc02822d0 lr = 0xc05e6148 (pmap_fault+0x74)
sp = 0xddbaaa70 fp = 0xddbaaa90
r4 = 0x00000005 r5 = 0x00516564
r6 = 0x00000005 r7 = 0xc7086834
r8 = 0xc7086844 r9 = 0xc0b275e4
r10 = 0x00000000
pmap_fault() at pmap_fault+0x74
pc = 0xc05e6148 lr = 0xc05eaca8 (abort_handler+0x110)
sp = 0xddbaaa98 fp = 0xddbaab28
r4 = 0x00000005 r5 = 0x00000000
r6 = 0x00000000 r7 = 0x00000005
r8 = 0x00000013 r9 = 0xddbaab30
r10 = 0x00516564
abort_handler() at abort_handler+0x110
pc = 0xc05eaca8 lr = 0xc05cb488 (exception_exit)
sp = 0xddbaab30 fp = 0xddbaac00
r4 = 0x00516540 r5 = 0xc06ecb29
r6 = 0x0000007a r7 = 0x00000000
r8 = 0xdb200024 r9 = 0xdb200000
r10 = 0xdb44a000
exception_exit() at exception_exit
pc = 0xc05cb488 lr = 0xc02449e4 (cf_set_method+0x5bc)
sp = 0xddbaabc0 fp = 0xddbaac00
r0 = 0xdf0ae780 r1 = 0x00000001
r2 = 0xddbaaafc r3 = 0x00000000
r4 = 0x00516540 r5 = 0xc06ecb29
r6 = 0x0000007a r7 = 0x00000000
r8 = 0xdb200024 r9 = 0xdb200000
r10 = 0xdb44a000 r12 = 0x20000000
cf_set_method() at cf_set_method+0x5c0
pc = 0xc02449e8 lr = 0xc0245fa8 (cpufreq_curr_sysctl+0x21c)
sp = 0xddbaac08 fp = 0xddbaac38
r4 = 0xc0891b64 r5 = 0x00000001
r6 = 0xdb200000 r7 = 0xc5362a80
r8 = 0x00002454 r9 = 0xdb200000
r10 = 0xc0891b7c
cpufreq_curr_sysctl() at cpufreq_curr_sysctl+0x21c
pc = 0xc0245fa8 lr = 0xc02ac594
(sysctl_root_handler_locked+0xd0) sp = 0xddbaac40 fp = 0xddbaac68
r4 = 0xc534f9c0 r5 = 0xc5345000
r6 = 0xddbaaccc r7 = 0xc0245d8c
r8 = 0xddbaac7c r9 = 0x00000000
r10 = 0x00000000
sysctl_root_handler_locked() at sysctl_root_handler_locked+0xd0
pc = 0xc02ac594 lr = 0xc02abc64 (sysctl_root+0x21c)
sp = 0xddbaac70 fp = 0xddbaacb8
r4 = 0x00000000 r5 = 0xc534f9c0
r6 = 0x00000000 r7 = 0xc5345000
r8 = 0xddbaac7c r9 = 0x00000000
r10 = 0xddbaaccc
sysctl_root() at sysctl_root+0x21c
pc = 0xc02abc64 lr = 0xc02ac260 (userland_sysctl+0x15c)
sp = 0xddbaacc0 fp = 0xddbaad18
r4 = 0x00000004 r5 = 0xddbaad40
r6 = 0x00000000 r7 = 0x00000000
r8 = 0xddbaaccc r9 = 0xdf0ae780
r10 = 0x00000000
userland_sysctl() at userland_sysctl+0x15c
pc = 0xc02ac260 lr = 0xc02ac0c0 (sys___sysctl+0x7c)
sp = 0xddbaad20 fp = 0xddbaadb0
r4 = 0xdf0aea20 r5 = 0xdf0ae780
r6 = 0xddbaad3c r7 = 0x00000000
r8 = 0x00000000 r9 = 0xdf0ae780
r10 = 0xdf0aea18
sys___sysctl() at sys___sysctl+0x7c
pc = 0xc02ac0c0 lr = 0xc05ea608 (swi_handler+0x294)
sp = 0xddbaadb8 fp = 0xddbaae40
r4 = 0x20057008 r5 = 0xc08e9250
r6 = 0xde875390 r10 = 0xdf0aea18
swi_handler() at swi_handler+0x294
pc = 0xc05ea608 lr = 0xc05cb418 (swi_exit)
sp = 0xddbaae48 fp = 0xbfbfd778
r4 = 0x20057008 r5 = 0x00000000
r6 = 0xbfbfe3a0 r7 = 0x000000ca
r8 = 0x00000000 r9 = 0x00000000
r10 = 0x00000000
swi_exit() at swi_exit
pc = 0xc05cb418 lr = 0xc05cb418 (swi_exit)
sp = 0xddbaae48 fp = 0xbfbfd778
KDB: enter: panic
[ thread pid 868 tid 100103 ]
Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]!
In the meantime you can use
https://people.freebsd.org/~manu/sun8i-a83t-bananapi-m3.dtb
This is the DTB from Linux 4.20 (or what 4.20 will be) with one of the
cluster removed. Setting the freq with sysctl dev.cpu.0.freq=XXXX or
using powerd works. Simply put it in the /dtb directory of the FAT
partition.
--
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
More information about the freebsd-arm
mailing list