Date: Thu, 4 Oct 2018 15:26:19 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Mark Millard <marklmi@yahoo.com> Cc: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Banana Pi M3 (armv7/CortexA7) with head -339076 and u-boot 2018.09_3 from ports: what CPU clock speed is it using? More. . . Message-ID: <20181004152619.b9daf1e395f543aa1621acd9@bidouilliste.com> In-Reply-To: <5B9D79C7-306E-45E0-9311-DDA0CC70C4A5@yahoo.com> References: <5B9D79C7-306E-45E0-9311-DDA0CC70C4A5@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, 3 Oct 2018 12:59:13 -0700 Mark Millard via freebsd-arm <freebsd-arm@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@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181004152619.b9daf1e395f543aa1621acd9>