Date: Wed, 17 Jul 2019 09:57:12 -0600 From: Ian Lepore <ian@freebsd.org> To: Stefan Parvu <sparvu@kronometrix.org>, freebsd-arm@freebsd.org Subject: Re: Rasclock (PCF2127 ) Hardware Clock FreeBSD 12.0 Message-ID: <d71fc4e3db26242ffa817814d6cd92b8899fc2ab.camel@freebsd.org> In-Reply-To: <BD0BE075-9E69-4CB0-826A-5DF2D160E9B1@kronometrix.org> References: <41A4CA5C-B487-490F-8A19-2D51F43E1004@kronometrix.org> <95616620-bbaf-dbc3-49eb-3e2562638d49@bunyatech.com.au> <AB510253-52D9-469C-B06E-5EC73C5F188E@kronometrix.org> <fd9991c4e6aaccb812a59ff86c9c8564ebd1d767.camel@freebsd.org> <74E3E782-8481-4B5B-A0AF-A04590C27D6D@kronometrix.org> <790afcb5f0809a89b45982958a85f1539fec05c7.camel@freebsd.org> <36088812-2135-4433-BC49-0BC433EC6767@kronometrix.org> <c52f9d9ab358ac0dc09af411bf97625945579b4e.camel@freebsd.org> <86CC4711-47AC-45C6-B6D3-71C9FFDD4A91@kronometrix.org> <BE321299-8569-4B2E-98FD-FD5210E1B6AF@kronometrix.org> <A9FD7D2B-9382-4EAE-B245-5F4DE643DBB7@gromit.dlib.vt.edu> <C93E2C64-6280-464D-AB5F-B1E968690CEF@kronometrix.org> <2ec7d7f63de31065b9cab396c662fe24f0107078.camel@freebsd.org> <BD0BE075-9E69-4CB0-826A-5DF2D160E9B1@kronometrix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2019-07-17 at 18:45 +0300, Stefan Parvu wrote: > fixed the svn. thanks for tips. > > and applied the patched, make and make install worked fine: > > # patch < /home/krmx/nxprtc.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > > --- sys/dev/iicbus/nxprtc.c 2019/05/23 18:24:27 348184 > > +++ sys/dev/iicbus/nxprtc.c 2019/07/15 21:47:40 350016 > > -------------------------- > Patching file sys/dev/iicbus/nxprtc.c using Plan A... > Hunk #1 succeeded at 33. > Hunk #2 succeeded at 42. > Hunk #3 succeeded at 243. > Hunk #4 succeeded at 312. > Hunk #5 succeeded at 478. > Hunk #6 succeeded at 534. > Hunk #7 succeeded at 805. > done > > # cd /usr/src/sys/modules/i2c/nxprtc > # make > machine -> /usr/src/sys/arm64/include > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/clock_if.m -h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/iicbus/iicbus_if.m -h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/ofw/ofw_bus_if.m -h > :> opt_platform.h > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fPIC -MD -MF.depend.nxprtc.o -MTnxprtc.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -std=iso9899:1999 -c /usr/src/sys/dev/iicbus/nxprtc.c -o nxprtc.o > ld -m aarch64elf -d -warn-common --build-id=sha1 -r -d -o nxprtc.kld nxprtc.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk nxprtc.kld export_syms | xargs -J% objcopy % nxprtc.kld > ld -m aarch64elf -Bshareable -znotext -d -warn-common --build-id=sha1 -o nxprtc.ko nxprtc.kld > objcopy --strip-debug nxprtc.ko > > # make install > install -T release -o root -g wheel -m 555 nxprtc.ko /boot/modules/ > kldxref /boot/modules > > > Bingo. Let me try now the new ko module file on another system. Will report back the findings. > thanks all for help. What worries me about that output is this line: > :> opt_platform.h that looks like it created a completely empty opt_platform.h, but that file must contain #define FDT 1 for the nxprtc module to build with fdt support. That's why I have been lifelong-skeptical about the whole concept of trying to build a single module separate from the kernel. Maybe it mostly works for amd64, but I've never thought it was a safe thing to do on arm systems. You might be able to work around it by hand-editing that file and then rebuilding the module. The file will be in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/modules/i2c/nxprtc/opt_platform.h -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d71fc4e3db26242ffa817814d6cd92b8899fc2ab.camel>