Date: Tue, 14 Nov 2017 17:54:30 -0800 From: Mark Millard <markmi@dsl-only.net> To: Andreas Schwarz <freebsd.asc@strcmp.org> Cc: freebsd-arm@FreeBSD.org, ian@freebsd.org Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time Message-ID: <C0897088-D1C3-4577-8BFE-25298C392604@dsl-only.net> In-Reply-To: <4aff62bc14e.1f031cb6@mail.schwarzes.net> References: <d85f883f-84c2-5051-1996-2a0e73a2c1e7@restart.be> <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <c2bff518-89ce-4956-2548-e56afab5d83d@restart.be> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <FCA144E8-121A-48A5-8CDB-101FBDE6E84C@dsl-only.net> <dceb4702-8ede-aadd-17d8-ed41436955ad@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <4AB259A5-F00A-408F-968A-26AD8D776708@dsl-only.net> <4aff62bc14e.1f031cb6@mail.schwarzes.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Nov-14, at 5:09 PM, Andreas Schwarz <freebsd.asc@strcmp.org> =
wrote:
> On 14.11.17, Mark Millard wrote:
>=20
> Hi Mark,
>=20
>> I'm not the one with the clock problem
>> but I'll note that the -r325700 Pine64+
>> 2GB with a production-style kernel (not
>> debug) that I'm using has rather different
>> dev.cpu.0 output from sysctl as far as
>> "freq" goes (no such):
>=20
> My pine is the same, a PINE A64+ 2GB version.
>=20
> Using also a "non-debug" kernel config
>=20
> root@pinelot:~ $ cat /sys/arm64/conf/PINE64-ASC
>=20
> include "GENERIC"
>=20
> ident PINE64-ASC
>=20
> # remove predefined options from "GENERIC"
> nomakeoptions DEBUG
> nomakeoptions WITH_CTF
> nooptions KDB, KDB_TRACE, DDB
> nooptions INVARIANTS, INVARIANT_SUPPORT
> nooptions WITNESS, WITNESS_SKIPSPIN
> nooptions USB_DEBUG
> nooptions BUF_TRACKING
> nooptions DEADLKRES
> nooptions FULL_BUF_TRACKING
>=20
> # add options we want
> options TMPFS # Efficient memory filesystem
Showing my control of options:
# more /usr/src/sys/arm64/conf/GENERIC-NODBG
#
# GENERIC -- Custom configuration for the arm64/aarch64
#
include "GENERIC"
ident GENERIC-NODBG
makeoptions DEBUG=3D-g # Build kernel with gdb(1) =
debug symbols
options ALT_BREAK_TO_DEBUGGER
options KDB # Enable kernel debugger support
# For minimum debugger support (stable branch) use:
#options KDB_TRACE # Print a stack trace for a =
panic
options DDB # Enable the kernel debugger
# Extra stuff:
#options VERBOSE_SYSINIT # Enable verbose sysinit =
messages
#options BOOTVERBOSE=3D1
#options BOOTHOWTO=3DRB_VERBOSE
#options KTR
#options KTR_MASK=3DKTR_TRAP
##options KTR_CPUMASK=3D0xF
#options KTR_VERBOSE
# Disable any extra checking for. . .
nooptions DEADLKRES # Enable the deadlock resolver
nooptions INVARIANTS # Enable calls of extra sanity =
checking
nooptions INVARIANT_SUPPORT # Extra sanity checks of =
internal structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect =
deadlocks and cycles
nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks =
for speed
nooptions DIAGNOSTIC
nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
nooptions BUF_TRACKING
nooptions FULL_BUF_TRACKING
>> # uname -apKU
>> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r325700M arm64 =
aarch64 1200053 1200053
>=20
> modified?
I normally run based on the same sources
on all my builds, most of the modifications
are tied to powerpc64 and powerpc. Some are
tied to the BPI-M3 (that is currently
unsupported in various respects). One is
tied to my not having updated past -r325700
yet so I have fixes for things found
in -r325700 that were checked in
later (bcm2835_cpufreq.c).
# svnlite status | sort
? sys/amd64/conf/GENERIC-DBG
? sys/amd64/conf/GENERIC-NODBG
? sys/arm/conf/GENERIC-DBG
? sys/arm/conf/GENERIC-NODBG
? sys/arm64/conf/GENERIC-DBG
? sys/arm64/conf/GENERIC-NODBG
? sys/powerpc/conf/GENERIC64vtsc-DBG
? sys/powerpc/conf/GENERIC64vtsc-NODBG
? sys/powerpc/conf/GENERICvtsc-DBG
? sys/powerpc/conf/GENERICvtsc-NODBG
M contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
M contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
M crypto/openssl/crypto/armcap.c
M lib/libkvm/kvm_powerpc.c
M lib/libkvm/kvm_private.c
M sys/arm/allwinner/aw_usbphy.c
M sys/arm/broadcom/bcm2835/bcm2835_cpufreq.c
M sys/arm64/arm64/identcpu.c
M sys/boot/defs.mk
M sys/boot/fdt/dts/arm/a83t.dtsi
M sys/boot/powerpc/boot1.chrp/Makefile
M sys/boot/powerpc/kboot/Makefile
M sys/conf/kmod.mk
M sys/conf/ldscript.powerpc
M sys/kern/subr_pcpu.c
M sys/modules/dtb/allwinner/Makefile
M sys/powerpc/aim/mmu_oea64.c
M sys/powerpc/ofw/ofw_machdep.c
M sys/powerpc/powerpc/interrupt.c
M sys/powerpc/powerpc/mp_machdep.c
M sys/powerpc/powerpc/trap.c
>> # sysctl dev.cpu.0
>> dev.cpu.0.%parent: cpulist0
>> dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,cortex-a53
>> dev.cpu.0.%location:=20
>> dev.cpu.0.%driver: cpu
>> dev.cpu.0.%desc: Open Firmware CPU
>>=20
>> Looking, /usr/ports -r447122 moved
>> sysutils/u-boot-pine64 over to be
>> us-boot-master based back on 2017-Aug-2.
>> May be we have differing:
>>=20
>> u-boot-sunxi-with-spl.bin
>>=20
>> vintages dd'd to seek=3D8 on the
>> sdcards? Some other difference
>> someplace else?
>=20
> Latest u-boot-sunxi-with-spl.bin was not working for me, I'm using an =
older=20
> one. Maybe a dtb processing problem, mine is up to date (created from =
the=20
> dts).
For my context the DTB is from:
EFI at 0x48000000
More fully:
>> FreeBSD EFI boot block
Loader path: /boot/loader.efi
Initializing modules: ZFS UFS
Probing 4 block devices......+ done
ZFS found no pools
UFS found 1 partition
Consoles: EFI console =20
Command line arguments: loader.efi
Image base: 0xb6dbb008
EFI version: 2.05
EFI Firmware: Das U-boot (rev 0.00)
FreeBSD/arm64 EFI loader, Revision 1.1
EFI boot environment
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=3D0x7fd808 data=3D0xb21e0+0x39b39c =
syms=3D[0x8+0x10cfc8+0x8+0x103122]
/boot/entropy size=3D0x1000
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]... =20
Using DTB provided by EFI at 0x48000000.
. . .
I expect that the above is why we have a
difference. It may be an example of updated
materials from elsewhere no longer supporting
everything that older FreeBSD materials did.
(This might might wait for upstream materials
to update and be picked up by FreeBSD before
the functionality returns.)
One nice thing about our different contexts is
that both have time working for what the Pine64+
2GB's are being used for. (Not necessarily strongly
overlapping usage patterns.) This suggests that
DTB issues are not a likely cause of time breakage.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0897088-D1C3-4577-8BFE-25298C392604>