From owner-freebsd-arm@freebsd.org Sun Jan 29 06:33:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB937CC62BB for ; Sun, 29 Jan 2017 06:33:08 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3132D1312 for ; Sun, 29 Jan 2017 06:33:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id v0T69nlB071030; Sun, 29 Jan 2017 06:09:49 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id szazmsursrvs5jikjg3kc3f8fe; Sun, 29 Jan 2017 06:09:48 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black From: Tim Kientzle In-Reply-To: <20170125221350.GA92571@bluezbox.com> Date: Sat, 28 Jan 2017 22:10:06 -0800 Cc: =?utf-8?B?T3RhY8OtbGlv?= , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 06:33:08 -0000 > On Jan 25, 2017, at 2:13 PM, Oleksandr Tymoshenko = wrote: >=20 > Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: >> Dears >>=20 >> I'm trying boot a FreeBSD12-armv6-r312227=20 >> (u-boot-beaglebone-2017.01.00.1) on a beaglebone black. The snapshot=20= >> FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170105-r311461.img that I=20= >> downloaded from=20 >> = ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0/=20= >> works fine, but when I try boot the image that I build on my machine=20= >> using crouchet I get: >>=20 >> U-Boot SPL 2017.01-rc3 (Jan 22 2017 - 23:17:18) >> Trying to boot from MMC1MMC partition switch failed >> *** Warning - MMC partition switch failed, using default environment >>=20 >> reading u-boot.img >> reading u-boot.img >>=20 >> And boot stops. Someone can confirm that the revision 312227 is = working=20 >> fine? >=20 > I did some digging at the breakage is caused by this commit in U-Boot: > https://www.mail-archive.com/u-boot@lists.denx.de/msg234317.html >=20 > Crochet is using FAT12 for Beaglebone Black. Switching to FAT16 fixes > the problem. Try applying this patch to crochet and re-build image: >=20 > https://people.freebsd.org/~gonzo/patches/crochet-bbb-fat16.diff I just pushed this patch to Crochet master. Tim From owner-freebsd-arm@freebsd.org Sun Jan 29 13:56:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D763FCC7AD7 for ; Sun, 29 Jan 2017 13:56:11 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98EDD1F7 for ; Sun, 29 Jan 2017 13:56:10 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-vk0-x234.google.com with SMTP id k127so201688963vke.0 for ; Sun, 29 Jan 2017 05:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9CDyLB77XhUtn+Rm15PvsdJCxJwIagIT4K4nzRJjBMo=; b=AtgnqEzE1S685TeZIIikrNUV3yc4brz3nVmIHTH4e2/87qun1KZFgb6eXZQ4zOqLqG 5q+2B7gEfxt42+810q0jRpvFR1KDWMlcqYwiVZlpiuA4NzJKw2bh1i5leBpye+fcIJob MyFVmwilk9kBXo13IhRofn3375A/03saZ+Rwg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9CDyLB77XhUtn+Rm15PvsdJCxJwIagIT4K4nzRJjBMo=; b=hPr1EtUuVPzaRME6CQ2hUbNko++bq51TRxL80nQeSL6h/cJ5rJd4zi0RI7pp3SUzCP mvNW1iw0qoF+B61ID4seuLPnPYEmsUN27d95aD1GiDky9OpQjL04hqCgUmvA/cFUh0Qi td08HLxPlWQECJWxdC9x+WwEnMN59Smbk47WmSiVgGaqFYn/BPRsWqiX/NtTFOg+1JhA VXk7ouqrzx7HXVoezmBtSAcokZ5WURjqSbYHZhLasQVySnsSIMtNKdpFgMdT1fjEOe+y 51l0Vqg2zY9ivzUX8Va5F7FJjd7KBRclM9BPac/La2GljfYN9C7qAECpiR+YAFamS6vV WvQQ== X-Gm-Message-State: AIkVDXI8z8W3xAZzwjtSVOCzdI4+KarbkodseYKq+iS4Z2kMZvThjCyP71vKIl+n66TgDUCtdbr4+USUWF35/w== X-Received: by 10.31.156.201 with SMTP id f192mr8150190vke.14.1485698169743; Sun, 29 Jan 2017 05:56:09 -0800 (PST) MIME-Version: 1.0 References: <51d197a2-1332-617a-32a8-9901f474afa2@bsd.com.br> <20170125221350.GA92571@bluezbox.com> <3ad9c97c-e40c-0a37-f603-a08b5a72ebd3@bsd.com.br> <20170127013142.GA2921@bluezbox.com> <13aa921f-b65f-8bf6-f298-ccb286c7ed6e@bsd.com.br> <20170127020035.GA3187@bluezbox.com> <55637733-f4f5-6bcc-1d00-4c4b7d1b1b3d@bsd.com.br> <20170127022746.GA3433@bluezbox.com> <20170128035431.GA13176@bluezbox.com> In-Reply-To: <20170128035431.GA13176@bluezbox.com> From: =?UTF-8?Q?Otac=C3=ADlio_de_Ara=C3=BAjo_Ramos_Neto?= Date: Sun, 29 Jan 2017 13:55:59 +0000 Message-ID: Subject: Re: FreeBSD 12 r312227 dont boots on Beaglebone black To: Oleksandr Tymoshenko Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 13:56:11 -0000 Em s=C3=A1b, 28 de jan de 2017 00:54, Oleksandr Tymoshenko escreveu: > Oleksandr Tymoshenko (gonzo@bluezbox.com) wrote: > > Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: > > > Em 26/01/2017 23:00, Oleksandr Tymoshenko escreveu: > > > > Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: > > > >> Em 26/01/2017 22:31, Oleksandr Tymoshenko escreveu: > > > >>> Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: > > > >>>> Em 25/01/2017 19:13, Oleksandr Tymoshenko escreveu: > > > >>>>> Otac=C3=ADlio (otacilio.neto@bsd.com.br) wrote: > > ... skipped ... > > > > >>>> I have applied the patch and now I'm getting this error. Some > hints? > > > >>> FreeBSD uses dtb names that do not match upstream ones. After > updating > > > >>> to 2017.01 that change was lost in progress. Possible workaround > (HACK > > > >>> ALERT!!!) would be to do something like this: > > > >>> > > > >>> =3D> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > > > >>> =3D> saveenv > > > >>> > > > >>> Copy-paste to U-Boot serial console does not work for me on BBB, = so > > > >>> you'll have have to enter these commands > > > >>> > > > >>> I will submit update to u-boot ports so all these workarounds wil= l > > > >>> not be required. > > > >>> > > > >> I'm getting this: > > > >> > > > >> Type '?' for a list of commands, 'help' for more detailed help. > > > >> loader> setenv findfdt 'setenv fdtfile beaglebone-black.dtb' > > > >> Error: stack underflow > > > >> loader> > > > > No, setenv/saveenv should be done in u-boot. But this gave me > > > > an idea. You can also mount root partition on SD card and > > > > add following line to /boot/loader.conf: > > > > > > > > fdt_file=3D"beaglebone-black.dtb" > > > > > > > > That should do the trick as well > > > > > > > I have added > > > > > > fdt_file=3D"bboneblk.dtb" > > > > > > (because this is the name that I found on fat partition) to > > > /boot/loader.conf but still getting > > > > No, in this case it's not about what's on FAT it's what in > > /boot/dtb/ on root partition. That's where loader looks for > > DTB files. > > > > I don't have crochet setup handy right now so can't check > > end-to-end procedure, but I'll do it tomorrow. > > I tried building crochet image from scratch and can confirm > that adding fdt_file=3D"beaglebone-black.dtb" to /boot/loader.conf > works around this issue. Proper fix should be available soon. > > -- > gonzo > This works for me also. Thanks a lot! []'s -Otacilio > From owner-freebsd-arm@freebsd.org Sun Jan 29 21:09:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5D09CC6BFE for ; Sun, 29 Jan 2017 21:09:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-74.reflexion.net [208.70.210.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAE3CEA1 for ; Sun, 29 Jan 2017 21:09:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31859 invoked from network); 29 Jan 2017 21:11:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jan 2017 21:11:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sun, 29 Jan 2017 16:09:38 -0500 (EST) Received: (qmail 23659 invoked from network); 29 Jan 2017 21:09:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jan 2017 21:09:38 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B46E5EC77A4; Sun, 29 Jan 2017 13:09:37 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: head -r312942: install: link /usr/obj/DESTDIRs/.../boot/dtb/am3335x-bone.dtb -> /usr/obj/DESTDIRs/.../boot/dtb/beaglebone.dtb: No such file or directory Message-Id: <9F808021-FA63-4569-B277-8A784DD32479@dsl-only.net> Date: Sun, 29 Jan 2017 13:09:36 -0800 To: FreeBSD Toolchain , freebsd-arm X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 21:09:46 -0000 For a prior amd64 -> armv6 cross build and I tried a local file system install of the kernel via DESTDIR=3D use: > Script started on Sun Jan 29 12:51:42 2017 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRCCONF=3D/dev/null = SRC_ENV_CONF=3D/root/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host= WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/bpim3_clang make -j 4 = installkernel DESTDIR=3D/usr/obj/DESTDIRs/clang-bpim3-installkernel . . . But the install stopped early with: > --- realinstall_subdir_dtb/am335x --- > install: link = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/am3335x-bone.dtb -> = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/beaglebone.dtb: No = such file or directory > *** [_installlinks] Error code 71 >=20 > make[4]: stopped in /usr/src/sys/modules/dtb/am335x > 1 error >=20 > make[4]: stopped in /usr/src/sys/modules/dtb/am335x > *** [realinstall_subdir_dtb/am335x] Error code 2 >=20 > make[3]: stopped in /usr/src/sys/modules Retrying without -j 4 failed the same way: > =3D=3D=3D> dtb/am335x (install) > test -d /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb || = install -d -o root -g wheel = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb > install -o root -g wheel -m 444 am335x-bone.dtb = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/ > install -o root -g wheel -m 444 am335x-boneblack.dtb = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/ > install -o root -g wheel -m 444 am335x-bonegreen.dtb = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/ > install -o root -g wheel -m 444 ufw.dtb = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/ > /boot/dtb/beaglebone.dtb -> /boot/dtb/am3335x-bone.dtb > install: link = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/am3335x-bone.dtb -> = /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/beaglebone.dtb: No = such file or directory > *** Error code 71 >=20 > Stop. > make[4]: stopped in /usr/src/sys/modules/dtb/am335x > *** Error code 1 >=20 > Stop. > make[3]: stopped in /usr/src/sys/modules > *** Error code 1 >=20 > Stop. > make[2]: stopped in = /usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src Details: > # more /usr/src/sys/arm/conf/BPIM3-NODBG > # > # BPIM3 -- Custom configuration for the Banana Pi M3 > # >=20 > include "GENERIC" >=20 > ident BPIM3-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # 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 >=20 > # 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 > # more /root/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host > TO_TYPE=3Darmv6 > # > KERNCONF=3DBPIM3-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > #CPUTYPE=3Dsoft > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_ELFTOOLCHAIN_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > # > # Linking lldb fails for armv6(/v7) (historical binutils) > WITHOUT_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > WITHOUT_LIBSOFT=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -mcpu=3Dcortex-a7 > XCXXFLAGS+=3D -mcpu=3Dcortex-a7 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > # more /root/src.configs/make.conf > #MALLOC_PRODUCTION=3D > #NO_WERROR=3D > #WERROR=3D > CFLAGS.gcc+=3D -v =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Jan 29 21:50:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 401F0CC7A10; Sun, 29 Jan 2017 21:50:15 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAF7D883; Sun, 29 Jan 2017 21:50:14 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id v77so12081544wmv.0; Sun, 29 Jan 2017 13:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MQF/43RKPGZDbWLx8q7cw+6+YWEoMpweFTJb//Nx95M=; b=LuLpXQId3sHl+jBrnckQ+YlgpK0nS438nsRWVjTFgHtXc/NKw8nWs9+NzSvoGma12P r6B+hDWJ/d2Kjfff1Tgsb1OmmcB7ZeEBxUhEKYp8zMpD3uniQ1aYTa6owlIUvyyWT5Ej Ugz/PgyhpoFJ4TrxDdwIpwvkHdNBj1XW/vcSYjUNkJ6DgIFmU4zAd/6O6Ax+O+FcMXE9 P6ySmEyVoBS0AGW42WbYwHoaP8r1Vvy48PcTiWhQtR+JoLoa/RAv5jiWsy4KxKJ3vyb4 RsYz9mGuryF2NrvSz4FkEfXP8g3sIoX0X+9UezHHCLw2j+QtZppoqPWSTwOw0ZbsQaCi QWZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MQF/43RKPGZDbWLx8q7cw+6+YWEoMpweFTJb//Nx95M=; b=CZjsNuM2CmoypfbJ2ZKOftNqV8bc32bd2RANv98oXiuA3gezEBxJburVAfBwQ7XXid dCSXLA3GiFs/n9txBdX8qplbIjinTxzsntil8g9fts85UXluLVIxBUs1hKTfoiLOFvsH XWJ3LKY8YQmy5n+FR8tpd+Y2wigz/iRoZqHCNNKoX3OWMbHzZDS/ZXkXWVJ7sQ+hcxCZ CyoWJwDBm5iMhBCoXPDxy0PK7zEuMbhxvFLj/iifzEtziPUqFawuoi54Gv+zeatjXwhF bizDHA0T6ufCJRB3hvXKo4lrX1WjMjs26Ym6sH1R4W9L3GaGtigdmOqqEqWDna4hAGq9 Bjfg== X-Gm-Message-State: AIkVDXKLXj/K+3cgNcpqYwXfeqWw4TE33SwuyzcsdFOSyhMNhHxMDUF43SqQQtx2tPhBLbNp/R0wjNP23/1yaA== X-Received: by 10.223.165.138 with SMTP id g10mr17523947wrc.105.1485726613122; Sun, 29 Jan 2017 13:50:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.24.6 with HTTP; Sun, 29 Jan 2017 13:50:12 -0800 (PST) In-Reply-To: <9F808021-FA63-4569-B277-8A784DD32479@dsl-only.net> References: <9F808021-FA63-4569-B277-8A784DD32479@dsl-only.net> From: Guy Yur Date: Sun, 29 Jan 2017 23:50:12 +0200 Message-ID: Subject: Re: head -r312942: install: link /usr/obj/DESTDIRs/.../boot/dtb/am3335x-bone.dtb -> /usr/obj/DESTDIRs/.../boot/dtb/beaglebone.dtb: No such file or directory To: Mark Millard , Warner Losh Cc: FreeBSD Toolchain , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 21:50:15 -0000 Hi, On Sun, Jan 29, 2017 at 11:09 PM, Mark Millard wrote: > For a prior amd64 -> armv6 cross build and I tried a local > file system install of the kernel via DESTDIR=3D use: > >> Script started on Sun Jan 29 12:51:42 2017 >> Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/nu= ll SRC_ENV_CONF=3D/root/src.configs/src.conf.bpim3-clang-bootstrap.amd64-ho= st WITH_META_MODE=3Dyes MAKEOBJDIRPREFIX=3D/usr/obj/bpim3_clang make -j 4 i= nstallkernel DESTDIR=3D/usr/obj/DESTDIRs/clang-bpim3-installkernel > . . . > > But the install stopped early with: > >> --- realinstall_subdir_dtb/am335x --- >> install: link /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/am333= 5x-bone.dtb -> /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/beagleb= one.dtb: No such file or directory >> *** [_installlinks] Error code 71 >> >> ... > > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" In r312915 changes there is an extra '3' in the LINKS=3D section of sys/modules/dtb/am335x/Makefile ${DTBDIR}/am3335x-bone.dtb should be ${DTBDIR}/am335x-bone.dtb ${DTBDIR}/am3335x-boneblack.dtb should be ${DTBDIR}/am335x-boneblack.dtb Regards, Guy From owner-freebsd-arm@freebsd.org Sun Jan 29 22:07:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 307FECC7EBE; Sun, 29 Jan 2017 22:07:50 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06D9812E2; Sun, 29 Jan 2017 22:07:49 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cXxdP-0007fu-A0; Sun, 29 Jan 2017 14:07:44 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0TM7gpj029505; Sun, 29 Jan 2017 14:07:42 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 29 Jan 2017 14:07:42 -0800 From: Oleksandr Tymoshenko To: Guy Yur Cc: Mark Millard , Warner Losh , freebsd-arm , FreeBSD Toolchain Subject: Re: head -r312942: install: link /usr/obj/DESTDIRs/.../boot/dtb/am3335x-bone.dtb -> /usr/obj/DESTDIRs/.../boot/dtb/beaglebone.dtb: No such file or directory Message-ID: <20170129220742.GA29484@bluezbox.com> References: <9F808021-FA63-4569-B277-8A784DD32479@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Guy Yur (guyyur@gmail.com) wrote: > Hi, > > On Sun, Jan 29, 2017 at 11:09 PM, Mark Millard wrote: > > For a prior amd64 -> armv6 cross build and I tried a local > > file system install of the kernel via DESTDIR= use: > > > >> Script started on Sun Jan 29 12:51:42 2017 > >> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null SRC_ENV_CONF=/root/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/bpim3_clang make -j 4 installkernel DESTDIR=/usr/obj/DESTDIRs/clang-bpim3-installkernel > > . . . > > > > But the install stopped early with: > > > >> --- realinstall_subdir_dtb/am335x --- > >> install: link /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/am3335x-bone.dtb -> /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/beaglebone.dtb: No such file or directory > >> *** [_installlinks] Error code 71 > >> > >> ... > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > In r312915 changes there is an extra '3' in the LINKS= section > of sys/modules/dtb/am335x/Makefile > > ${DTBDIR}/am3335x-bone.dtb should be ${DTBDIR}/am335x-bone.dtb > ${DTBDIR}/am3335x-boneblack.dtb should be ${DTBDIR}/am335x-boneblack.dtb [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: dsl-only.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 22:07:50 -0000 Guy Yur (guyyur@gmail.com) wrote: > Hi, > > On Sun, Jan 29, 2017 at 11:09 PM, Mark Millard wrote: > > For a prior amd64 -> armv6 cross build and I tried a local > > file system install of the kernel via DESTDIR= use: > > > >> Script started on Sun Jan 29 12:51:42 2017 > >> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null SRC_ENV_CONF=/root/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/bpim3_clang make -j 4 installkernel DESTDIR=/usr/obj/DESTDIRs/clang-bpim3-installkernel > > . . . > > > > But the install stopped early with: > > > >> --- realinstall_subdir_dtb/am335x --- > >> install: link /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/am3335x-bone.dtb -> /usr/obj/DESTDIRs/clang-bpim3-installkernel/boot/dtb/beaglebone.dtb: No such file or directory > >> *** [_installlinks] Error code 71 > >> > >> ... > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > In r312915 changes there is an extra '3' in the LINKS= section > of sys/modules/dtb/am335x/Makefile > > ${DTBDIR}/am3335x-bone.dtb should be ${DTBDIR}/am335x-bone.dtb > ${DTBDIR}/am3335x-boneblack.dtb should be ${DTBDIR}/am335x-boneblack.dtb Fixed in r312969, thanks -- gonzo From owner-freebsd-arm@freebsd.org Mon Jan 30 06:57:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C214CC728B for ; Mon, 30 Jan 2017 06:57:58 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1D0F1E for ; Mon, 30 Jan 2017 06:57:58 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: by mail-io0-x244.google.com with SMTP id q20so13668525ioi.3 for ; Sun, 29 Jan 2017 22:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Bm0ypbgmCP9gw8QxIUPainbbVvqxDLf2RdA3qY/95xQ=; b=eXc7v6fWhtEawTwrytY2qzrxEJqm9ldw/g5EjBRsEq/lf7OUoJ62l8MsAt+PqgOGz+ /hN9ST22RM0CCjMfRkoKdDdy/+C1FE/bk5asZOlv2wFQHEPTrKThwOyFDCaUDfey+fDk /SDSA5OS+8f6x2mbj0wgOWZSc1qDrpZ+QCfYqhUuOZvGB5/O9WRjkvJtK71mMY9gA+vi 6EEvHz67x/Y3kBSA5qDRP5ruF7Lmdat6/nkKl+U4Y5OmTJIl4ijh1Lz3+1rFQ5V0I1pp bZxUIl9ph09ogmiXA5cMEe4WXOKztes1w+/qn7VENO2cae3DYDw8O2q72s2BfVkFJZv1 7Omw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bm0ypbgmCP9gw8QxIUPainbbVvqxDLf2RdA3qY/95xQ=; b=mG5b23/MRpmayu+4JTCcm6v6fwMPFFylU7r7Pbpa4R5MJY07uXynTol0rs7t5hsTpQ 0et4ZLw22uBv8kuuV/y8Bjm2WQekCg6LQpER2rLmYUzMCMu5SjhO6m7JMi0SuHgVdWp1 aSnRs+ycijzgA2Jx7REA4YJT02fU3fZl9lwroWH6OxUhEcy7jf5TVSKdQDwCKOFejgy3 bqfl4LkvXMllAniqDaP4G0uyHkxduZeQIIwnd4hA004xj97X/DbfVGjsHEC9u3zMPaCg lG23I+jCwzEmgMqzLTW+Vo4d41t7GT5Vwwq+cfCyzOmfABax+0ghjmo2moJKxSnqbecO UcMg== X-Gm-Message-State: AIkVDXJ7LqVB4es9mU/Enc0lrWM4B+x9mP4WbufYqwKQChQRNfrXq2BeMHQMd61QL4tUiW5/OC8mfpNZyZt8PQ== X-Received: by 10.107.20.202 with SMTP id 193mr20278197iou.152.1485759477349; Sun, 29 Jan 2017 22:57:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.70.84 with HTTP; Sun, 29 Jan 2017 22:57:56 -0800 (PST) From: Balaji Palaniswami Date: Sun, 29 Jan 2017 22:57:56 -0800 Message-ID: Subject: Creating bootable vm disk To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 06:57:58 -0000 Hi All, I followed this https://wiki.freebsd.org/FreeBSD/arm/crossbuild. buildworld, buildkernel, distribution, installkernel (TARGET=arm and arch= armv6) went fine. I have compiled stuff at /home/username/nfsroot. Instead of writing into sdcard or USB, i want to create bootable vm disk to boot in bhyve. To create i tried mkimg sudo mkimg -s gpt -b nfsroot/boot/mbr -p freebsd-boot:=nfsroot/boot/gptboot -p freebsd-ufs:=root-file-system.ufs -p freebsd-swap::1G -o fbsd-2.img Here i created root filesystem using makefs which provided the rootfilesystem.ufs. Then i verified those contents by mounting which looks as it is in /nfsroot. But mkimg did not create boot partition properly. Because when i tried to mount those partition it threw I/O error and when i was trying to boot using beehive it says "kernel not found". Is there any script or list of commands to accomplish this task ? Thanks, Balaji From owner-freebsd-arm@freebsd.org Mon Jan 30 14:16:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE351CC82DB for ; Mon, 30 Jan 2017 14:16:03 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8F551982 for ; Mon, 30 Jan 2017 14:16:03 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id D7CA431D25; Mon, 30 Jan 2017 07:16:01 -0700 (MST) Date: Mon, 30 Jan 2017 07:16:01 -0700 From: Brad Davis To: Balaji Palaniswami Cc: freebsd-arm@freebsd.org Subject: Re: Creating bootable vm disk Message-ID: <20170130141601.GT70816@corpmail.liquidneon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 14:16:03 -0000 On Sun, Jan 29, 2017 at 10:57:56PM -0800, Balaji Palaniswami wrote: > Hi All, > > I followed this https://wiki.freebsd.org/FreeBSD/arm/crossbuild. > buildworld, buildkernel, distribution, installkernel (TARGET=arm and arch= > armv6) went fine. I have compiled stuff at /home/username/nfsroot. Instead > of writing into sdcard or USB, i want to create bootable vm disk to boot in > bhyve. To create i tried mkimg > > sudo mkimg -s gpt -b nfsroot/boot/mbr -p > freebsd-boot:=nfsroot/boot/gptboot -p freebsd-ufs:=root-file-system.ufs -p > freebsd-swap::1G -o fbsd-2.img > > Here i created root filesystem using makefs which provided the > rootfilesystem.ufs. Then i verified those contents by mounting which looks > as it is in /nfsroot. But mkimg did not create boot partition properly. > Because when i tried to mount those partition it threw I/O error and when i > was trying to boot using beehive it says "kernel not found". > > Is there any script or list of commands to accomplish this task ? Hi Balaji, I'd recommend you use crochet: https://github.com/freebsd/crochet Regards, Brad Davis From owner-freebsd-arm@freebsd.org Mon Jan 30 16:00:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A10D4CC8718 for ; Mon, 30 Jan 2017 16:00:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7478036C for ; Mon, 30 Jan 2017 16:00:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id l66so110368337ioi.1 for ; Mon, 30 Jan 2017 08:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=czANGxtUJiQZ0FtCSM3TtyV42KJqJlF8PRpCw678Mmk=; b=flqZy2E7dQ1yln7l2YS3CFOvh72mSES97Nk5wDYODFhN8GRfLjFp3Ka0DqnE8BzkvB gw+7SwKH1ekSQjOpW+/qQS2evqqMWkVzO7n/a9TNfoLX8L8coR0EWL3K2GCO5GuPafgs VS0zzI8R8TZ5RgHPsFkTvRFOX12dsRpaAvYTS2vQTLs6gW1nNlI+mthWG/hnSLMVQ+HK KrZf9VniViIhHJ0dvunLbm49fshbTOh7Xi3TbkA9S+E+myLBHF3hTM66j0sWz+g9PDrR h3Aj0KxKJGgIqyGo010OEFOtPjXMa++szvIHKr4BOITGyL5nnrFd6CXxIdsfXX75MjLj Rzzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=czANGxtUJiQZ0FtCSM3TtyV42KJqJlF8PRpCw678Mmk=; b=BBaTmQvXYkXa0iYQPVgG7WrVOqhMIdCfuqZxdajjg6+cjwvrO0gsbVNPChVM9VoUvL BgWaCUDgWAr88Eeg1Ej8EHFYXMKBd4GvSQeJC0aguR6zNB/SnPxqGsRZ5jCNEiyh4djN hMK8YzHjoQEX/TR5wbB1APx+5WJdbCKK711x0dEUM2ZaqZ/4D7h2RKCzrrdJ0YPunLHj IAUt/BVNOUM5hMT8312kNIwi67Usfl0Qxg8kS+RVkRtnhW3dhK4I0+nF088+lGruupGi hLUHnwjsguetGo7B7AkQrQJUBISdMhBv/nlgfv9UqB1PZXlUAlF8heZOc6L+N2eNM755 j0bw== X-Gm-Message-State: AIkVDXJu3r3AUqzLSRt52WR2lqDw6suyacrTof3kL/qBJBcB/RNrEaQTl/libKuI8v7E2pgqAiywWdVV6WBktw== X-Received: by 10.107.198.195 with SMTP id w186mr19933014iof.19.1485792026858; Mon, 30 Jan 2017 08:00:26 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Mon, 30 Jan 2017 08:00:26 -0800 (PST) X-Originating-IP: [50.205.115.50] In-Reply-To: References: From: Warner Losh Date: Mon, 30 Jan 2017 09:00:26 -0700 X-Google-Sender-Auth: S5qFV58uuK9uaMIehIeU4tuJ4x0 Message-ID: Subject: Re: Creating bootable vm disk To: Balaji Palaniswami Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 16:00:28 -0000 On Sun, Jan 29, 2017 at 11:57 PM, Balaji Palaniswami wrote: > Hi All, > > I followed this https://wiki.freebsd.org/FreeBSD/arm/crossbuild. > buildworld, buildkernel, distribution, installkernel (TARGET=arm and arch= > armv6) went fine. I have compiled stuff at /home/username/nfsroot. Instead > of writing into sdcard or USB, i want to create bootable vm disk to boot in > bhyve. To create i tried mkimg > > sudo mkimg -s gpt -b nfsroot/boot/mbr -p > freebsd-boot:=nfsroot/boot/gptboot -p freebsd-ufs:=root-file-system.ufs -p > freebsd-swap::1G -o fbsd-2.img > > Here i created root filesystem using makefs which provided the > rootfilesystem.ufs. Then i verified those contents by mounting which looks > as it is in /nfsroot. But mkimg did not create boot partition properly. > Because when i tried to mount those partition it threw I/O error and when i > was trying to boot using beehive it says "kernel not found". > > Is there any script or list of commands to accomplish this task ? NanoBSD can create images for non-VM targets for arm. Which board are you looking at? Did you put the right u-boot on the images that you are creating? Warner From owner-freebsd-arm@freebsd.org Mon Jan 30 20:22:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A034CC8487 for ; Mon, 30 Jan 2017 20:22:51 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6F0D972 for ; Mon, 30 Jan 2017 20:22:50 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id 203so202436798ith.0 for ; Mon, 30 Jan 2017 12:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0nrlYbAZyRSvZpU7QYjqTp8o+SeVtej8DjvKUH8gMUk=; b=NLSptGNn05px5Cx2YIvgo9vvzpGCY5OvmzjYeV0peTdD1Y3QviFLFIPJcmNFI2H8Gd i+CUMqhMWEXeWnqmzo24U5F6Q8bbMRkEN2iaIu768UnZwer+BfCOwtshIT35cWaoNsqO ourLp8f/sIZIfoyoetU9OiNU0zO0hoMjkSU/6xfKi0jehP6WeWuzLc7sD/Ht35kEuO3G +xyIR8LPvE3UhAVod0B7HD0tMi2V9mu4KU7a/HkllYEClbE2yv3/aD5Z5vBp5LqU4SGk AsAHIYJp7DFT87xFNC/UWv9fo602n9Elt9qWOyyEg0c5zwisGa+9O0BryYyfUPgxQ85B oz8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0nrlYbAZyRSvZpU7QYjqTp8o+SeVtej8DjvKUH8gMUk=; b=DZ3Mpv7+6Aq/G6oeYiq1PPsNmXBWN6ybj3wQNHmVOqcVg/Vhsdx/8RTn32UyynMomC LMEa6o1Bt8OmNul42PmemVbX8BWw5Ov6IFaicyklkAzc/cdQ4MnWaRcOpBymr3j3Pn2b 2x5atwFO/QNnEJEfjPJE5reVn7gAJ+WQ/mv71ylY0H1yWZklH4UBlR7FrZuV1BqX5GAO WUGnn/cM8XYxaFAwrnQgrxYfnfs3Hr5FS+gOtUBiygxgg+93GeY8d/vKb+tbEdrOzYab AsGP4QtGz+KrqeL6DTiCqRkkDfNidDsZNyaA5oWGHosS6lLDIim1qvBg9wxUzlzWCsE2 /2SQ== X-Gm-Message-State: AIkVDXJ76h9u7v8TUAVoB/5L3igSXD0O6jDTFRHvMIw+MqK2UhP2I1NwojDpM0OnIxAuhYuFpZGwaD0XAcnCQg== X-Received: by 10.36.107.131 with SMTP id v125mr6140534itc.73.1485807770252; Mon, 30 Jan 2017 12:22:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.70.84 with HTTP; Mon, 30 Jan 2017 12:22:49 -0800 (PST) In-Reply-To: References: From: Balaji Palaniswami Date: Mon, 30 Jan 2017 12:22:49 -0800 Message-ID: Subject: Re: Creating bootable vm disk To: Warner Losh Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:22:51 -0000 I am trying to boot using bhyve instead of hardware. So i am looking at constructing vm disk from the output of cross compilation steps as mentioned in wiki. Just skimmed over crochet repo, it is also constructing the vmdisk from freebsd source tree.I am trying to figure out the way to build vm disk in crochet which is compatible bhyve (raw). On Mon, Jan 30, 2017 at 8:00 AM, Warner Losh wrote: > On Sun, Jan 29, 2017 at 11:57 PM, Balaji Palaniswami > wrote: > > Hi All, > > > > I followed this https://wiki.freebsd.org/FreeBSD/arm/crossbuild. > > buildworld, buildkernel, distribution, installkernel (TARGET=arm and > arch= > > armv6) went fine. I have compiled stuff at /home/username/nfsroot. > Instead > > of writing into sdcard or USB, i want to create bootable vm disk to > boot in > > bhyve. To create i tried mkimg > > > > sudo mkimg -s gpt -b nfsroot/boot/mbr -p > > freebsd-boot:=nfsroot/boot/gptboot -p freebsd-ufs:=root-file-system.ufs > -p > > freebsd-swap::1G -o fbsd-2.img > > > > Here i created root filesystem using makefs which provided the > > rootfilesystem.ufs. Then i verified those contents by mounting which > looks > > as it is in /nfsroot. But mkimg did not create boot partition properly. > > Because when i tried to mount those partition it threw I/O error and > when i > > was trying to boot using beehive it says "kernel not found". > > > > Is there any script or list of commands to accomplish this task ? > > NanoBSD can create images for non-VM targets for arm. Which board are > you looking at? > > Did you put the right u-boot on the images that you are creating? > > Warner > From owner-freebsd-arm@freebsd.org Mon Jan 30 20:25:13 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E64F2CC84E1 for ; Mon, 30 Jan 2017 20:25:13 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE3409FF for ; Mon, 30 Jan 2017 20:25:13 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id j13so116258259iod.3 for ; Mon, 30 Jan 2017 12:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yCVVIKvGzCZgUTftvsBFKftpgbAICjVylILhBTx4UBM=; b=iZh2qnIfk2GHMareRiEYTieDqcCv1M+6Z7+NEW1nXnYh6oiZeRMPWPCuaclG+tlif0 Qg1CUWp9MYrjJThg0znjtCd3pVC5HM/fh5KM9SIN4s/tdzbIfbkRvPpyktlOoQ94Sx3m DKw09K2mZtV0m1GBQHqw2DqHMvU9vCAA4L+RFFQA6PW0yIrsrjP3zrteWfyvkzZ5PIMO KdHcbDNqXRYL0LSb6HjPyxHuFHmB6kOW/7z7kxsU3Ke6kjcB/Vje9GS9uBjgK2pxdEIe MB2VEeBmG+7iiOYG8eUXcFtibj42Gys7+FHUcMg4mkykFDG20HtWerH3K29iwShcZdv/ lGOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yCVVIKvGzCZgUTftvsBFKftpgbAICjVylILhBTx4UBM=; b=hcEemym99skWRkUhV9okOWHz2+Fh9MrdwQ8nJD66MXW+fl4WjbMuYaDLK02BIJZAM4 OQbXLhMotGi8fBOSGYciszXnT6ydHXFvv8FwwO1Xu2SBKXxNBDQssksN+mMW7sLws+WW U4HJi7dfmZZWRtKZIO7ZqP4dz/HhZ/0fzwooHx951iWC26lDmJjOi9liNSRe01Yr9NcZ enAgY5mA9e4Xn/Rvdnx7VZYA6X6YFJb3fYm0HvHSnq0Kcpnj7LgljH++WCNZGFZbe0nC /fxZCv20hS/ZAtmXcC5KTjUEFP20iJxEkuW/jbrHVKbixPXh4ql64RFVtB+1l25rzDXu hXJg== X-Gm-Message-State: AIkVDXI5NH6orkoz7JXJUxCeQZu8AwX5MUnd1X8N1VFSslBbUBWpJQmM9PiAOzVZwghX8vT94i8jvSDBOzVZgw== X-Received: by 10.107.20.202 with SMTP id 193mr23436644iou.152.1485807912819; Mon, 30 Jan 2017 12:25:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.70.84 with HTTP; Mon, 30 Jan 2017 12:25:12 -0800 (PST) In-Reply-To: References: From: Balaji Palaniswami Date: Mon, 30 Jan 2017 12:25:12 -0800 Message-ID: Subject: Re: Creating bootable vm disk To: Warner Losh Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:25:14 -0000 > > On Mon, Jan 30, 2017 at 8:00 AM, Warner Losh wrote: > >> On Sun, Jan 29, 2017 at 11:57 PM, Balaji Palaniswami >> wrote: >> > Hi All, >> > >> > I followed this https://wiki.freebsd.org/FreeBSD/arm/crossbuild. >> > buildworld, buildkernel, distribution, installkernel (TARGET=arm and >> arch= >> > armv6) went fine. I have compiled stuff at /home/username/nfsroot. >> Instead >> > of writing into sdcard or USB, i want to create bootable vm disk to >> boot in >> > bhyve. To create i tried mkimg >> > >> > sudo mkimg -s gpt -b nfsroot/boot/mbr -p >> > freebsd-boot:=nfsroot/boot/gptboot -p freebsd-ufs:=root-file-system.ufs >> -p >> > freebsd-swap::1G -o fbsd-2.img >> > >> > Here i created root filesystem using makefs which provided the >> > rootfilesystem.ufs. Then i verified those contents by mounting which >> looks >> > as it is in /nfsroot. But mkimg did not create boot partition properly. >> > Because when i tried to mount those partition it threw I/O error and >> when i >> > was trying to boot using beehive it says "kernel not found". >> > >> > Is there any script or list of commands to accomplish this task ? >> >> NanoBSD can create images for non-VM targets for arm. Which board are >> you looking at? >> >> Did you put the right u-boot on the images that you are creating? >> >> Warner >> > > apologize for top posting. I am trying to boot using bhyve instead of hardware. So i am looking at constructing vm disk from the output of cross compilation steps as mentioned in wiki. Just skimmed over crochet repo, it is also constructing the vmdisk from freebsd source tree.I am trying to figure out the way to build vm disk in crochet which is compatible bhyve (raw). From owner-freebsd-arm@freebsd.org Tue Jan 31 07:46:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEB20CC997B for ; Tue, 31 Jan 2017 07:46:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB7151E67 for ; Tue, 31 Jan 2017 07:46:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from sgi-2.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1cYT8s-0007KY-9R; Tue, 31 Jan 2017 09:46:18 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Creating bootable vm disk From: Daniel Braniss In-Reply-To: Date: Tue, 31 Jan 2017 09:46:18 +0200 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Balaji Palaniswami X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 07:46:34 -0000 > On 30 Jan 2017, at 22:25, Balaji Palaniswami = wrote: >=20 >>=20 >> On Mon, Jan 30, 2017 at 8:00 AM, Warner Losh wrote: >>=20 >>> On Sun, Jan 29, 2017 at 11:57 PM, Balaji Palaniswami >>> wrote: >>>> Hi All, >>>>=20 >>>> I followed this https://wiki.freebsd.org/FreeBSD/arm/crossbuild. >>>> buildworld, buildkernel, distribution, installkernel (TARGET=3Darm = and >>> arch=3D >>>> armv6) went fine. I have compiled stuff at /home/username/nfsroot. >>> Instead >>>> of writing into sdcard or USB, i want to create bootable vm disk to >>> boot in >>>> bhyve. To create i tried mkimg >>>>=20 >>>> sudo mkimg -s gpt -b nfsroot/boot/mbr -p >>>> freebsd-boot:=3Dnfsroot/boot/gptboot -p = freebsd-ufs:=3Droot-file-system.ufs >>> -p >>>> freebsd-swap::1G -o fbsd-2.img >>>>=20 >>>> Here i created root filesystem using makefs which provided the >>>> rootfilesystem.ufs. Then i verified those contents by mounting = which >>> looks >>>> as it is in /nfsroot. But mkimg did not create boot partition = properly. >>>> Because when i tried to mount those partition it threw I/O error = and >>> when i >>>> was trying to boot using beehive it says "kernel not found". >>>>=20 >>>> Is there any script or list of commands to accomplish this task ? >>>=20 >>> NanoBSD can create images for non-VM targets for arm. Which board = are >>> you looking at? >>>=20 >>> Did you put the right u-boot on the images that you are creating? >>>=20 >>> Warner >>>=20 >>=20 >> apologize for top posting. > I am trying to boot using bhyve instead of hardware. So i am looking = at > constructing vm disk from the output of cross compilation steps as > mentioned in wiki. Just skimmed over crochet repo, it is also = constructing > the vmdisk from freebsd source tree.I am trying to figure out the way = to > build vm disk in crochet which is compatible bhyve (raw). > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" stupid question, on what hardware are you running bhyve? danny From owner-freebsd-arm@freebsd.org Tue Jan 31 07:58:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB7FBCC9E69 for ; Tue, 31 Jan 2017 07:58:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-76.reflexion.net [208.70.210.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F70D7F9 for ; Tue, 31 Jan 2017 07:58:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8488 invoked from network); 31 Jan 2017 07:58:01 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Jan 2017 07:58:01 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Tue, 31 Jan 2017 02:58:01 -0500 (EST) Received: (qmail 23426 invoked from network); 31 Jan 2017 07:58:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Jan 2017 07:58:00 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 0EB2CEC825A; Mon, 30 Jan 2017 23:58:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) From: Mark Millard In-Reply-To: Date: Mon, 30 Jan 2017 23:57:59 -0800 Cc: Shawn Webb , Andrew Turner , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> To: Tom Vijlbrief X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 07:58:09 -0000 I updated to head -r312982 on the pine64 that I have access to: # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 after several months of not using the pine64. ( -mcpu=3Dcortex-a53 used for buildworld buildkernel; non-debug variant of GENERIC [GENERIC included then overridden]; usb SSD root file system) I find that any time some of the cores are busy I get thousands of the gic0 spurious interrupt messages in fairly sort order. (This is not new: it is unchanged.) For example during either of: openssl speed or: cp /dev/zero /dev/null (similarly for copying actual files around, local or nfs involved) Once the cores are no longer busy the gic0 messages stop. The "on CPU" varies. The "last irq: " varies. (But 27 is the most common by far.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: Note that on the pine64 the network interface hangs from time to time = and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". Note that I had = similar issues on the ODroid-C2. Currently rebuilding world without MALLOC_PRODUCTION. The arm64 port is getting close to working 100%, just a last few = glitches. Op 22:03 ZA 28 Jan 2017 schreef Mark Millard : [About: "gic0: Spurious interrupt detected" on armv6 as well.] On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief = wrote: > Did a build/install world/kernel with r312916 and = MALLOC_PRODUCTION=3DYES on > a pine64, removed /etc/malloc.conf, rebooted > > and I am now rebuilding the python2 port without problems so far = (except > the "gic0: Spurious interrupt detected" messages which reappeared = shortly > after my previous post) While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) during large builds (with -j 4). Recently I got a: gic0: Spurious interrupt detected: last irq: 29 on CPU1 on: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 = 20:57:48 PST 2017 = markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG = arm armv6 1200020 1200020 while building devel/gcc6 (via a full bootstrap) via -j 4 . This is from a non-debug buildworld buildkernel context and has = MALLOC_PRODUCTION=3D in /etc/make.conf . No /etc/malloc.conf present. I do use = -mcpu=3Dcortex-a7 . Details if you care: # more /usr/src/sys/arm/conf/BPIM3-NODBG # # BPIM3 -- Custom configuration for the Banana Pi M3 # include "GENERIC" ident BPIM3-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 It was a from cross build for buildworld buildkernel : (I've not checked on lldb builds linking recently.) # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host TO_TYPE=3Darmv6 # KERNCONF=3DBPIM3-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. Used for buildworld buildkernel : # more ~/src.configs/make.conf #MALLOC_PRODUCTION=3D #NO_WERROR=3D #WERROR=3D CFLAGS.gcc+=3D -v Used for port builds: # more /etc/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/ofw/ofw_machdep.c The M's are generally tied to powerpc64 and powerpc explorations. I tend to use the same source for all the TARGET_ARCH's that I build. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jan 31 08:13:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B7AACCA5D6 for ; Tue, 31 Jan 2017 08:13:19 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD6541102 for ; Tue, 31 Jan 2017 08:13:18 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbKXI-1cr6NJ2aRw-00Imup; Tue, 31 Jan 2017 09:13:05 +0100 Date: Tue, 31 Jan 2017 09:13:04 +0100 From: "O. Hartmann" To: Mark Millard Cc: Tom Vijlbrief , freebsd-arm Subject: OT: HowTo: FreeBSD status for/on ODroid-C2?) Message-ID: <20170131091304.7c5349cf@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:z6fjCvVuIL75+Oi9R6+ly3+MP/v2uUcmh/XfNP3ERXGZDfRfc2A A5GwD/9/TUYKt7M5E1yVkUoWJcJPWfJBGcsogy4vLFNRZHHcbUCjITIev5pflJOnkbJtfnL RvLKYciV3e5wva051H7Fnp8JPmawI1Dn4MJVd8UpZ6xhBPwV/iX8LPQ560gxXXOFhQhELsv fIoT+1c7ZRSyH0TNyXO9A== X-UI-Out-Filterresults: notjunk:1;V01:K0:ylkjTssGlSM=:mS0Hb60p/MIoZFG8Wf3X0i IWubzWqYG2RtQkUAwIFQDvjC/cPC+3jCofafmKb54cRMCchPGGyJsroV/1KfUm6TYPoCz+BW+ plJauiweGRAorbOiGt7zHkae/j962/wa1lsEfEa1eCXkCHxZtuhTDP63vGSOjYyP7oxxp6aUs rev7bkbPBH+LyC0hrhE7y3VppwzWLKSeXxhoKlGwTe5e2tIdPE35Uyda+pT0NXr777GhQv6Ak h/Er2p5XZNF7HuJW34ZnhBpgOZZyrrCtmM9Y2rsaU8FVf5bLkB2MRddxrx2EQR+SFLAARNy/w BO/ukKOYlzt8IXdA2U7gBPQhFQBuxUk1BwDfcqFwV3W0ncp2v8CyxERz1SerFzH5sIR80Lztv aOB7zbwOFPCFkD1IkQx9ZgDTuF78SDc9zj7i/WbhfmrOiPQopL0qlLfsbYMBXKoc8D/eUf07T OSuMGSHOipump2LlKtU4XMoLV1D3G/a/l24fS71kSZKgivlMbl3xUce5bI79mc7PiEKwYvK8p Fz/6sr7q1QRDPruMiEbpYq32J3nA3qsiMrv2UPfsF75J/rWIbgfQO0tycq8ZJ+FOsdolZDjSj xia/xX+7A+hlGaoi7T7CSBLA4HSSjLapi22s3s7aI1Z9nOGBw/DV3YALKJyKWDNJCrGv0wYlR YsjJ6HQYTtGBC2gqylMmE4TUNLfZIsrAnAsM98OtHyQuY+P1kiZj5mXlFViBPLxS54gK3B8Mt ZzcSuqanRVq1afxVnkMdZKBMfUb0gsN/Mwaa5pRWPMc0MBMo20dYCw91n/TJ5gXaqss/fw+lp LEolbqbXgRq/ASIC3t52sfgAT5MEhtcI/tZ0cfDPuwj2km+Aym2ePXbIrb5QhEvOft9aICPJj OEVwrgL6F3cZux4kAvjFYv2ija9KY08TyEGvzL5155ykWVdUFAI0CZuWUeFJ/PfLdOQBPJTD7 uBXZ7TQMJSveo2Yrq0AOShgeb3WdP+VEXO5bKTTxZxrqLS4fsSAUYSjO3ivVfN2ASN6Oxg981 x9GbOLXfXPYH/A4Dh4xvvYIJIqZjh/opvGRp0Uq89l7VaJ7WdIloRXPgo2Yr4Tvlrw== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 08:13:19 -0000 On Mon, 30 Jan 2017 23:57:59 -0800 Mark Millard wrote: Hello, I'm fairly new to ARM based SoCs and I have an Odroid-C2 at hand. I try to build the boot images by cloning/copying and adapting the process I found in the sysutils/u-boot-pine64 port, but my knowledge about how to build u-boot to provide the desired is weak. I was wondering if someone could give a little help in a HowTo for the Odroid-C2. I already prepared a NanoBSD build for ARM64. I guess this would be the minor task compared to get the right boot image to bootstrap the Odroid-C2 from an USB oder SD. Or, if possible, could you delegate me to the thread/wiki/webpage where those first steps are explained? Well, thank you very much in advance, Oliver Hartmann > I updated to head -r312982 on the pine64 that I have access to: > > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 aarch64 > 1200020 1200020 > > after several months of not using the pine64. > ( -mcpu=cortex-a53 used for buildworld buildkernel; > non-debug variant of GENERIC [GENERIC included > then overridden]; usb SSD root file system) > > I find that any time some of the cores are busy I get thousands > of the gic0 spurious interrupt messages in fairly sort order. > (This is not new: it is unchanged.) > > For example during either of: > > openssl speed > > or: > > cp /dev/zero /dev/null > (similarly for copying actual files around, > local or nfs involved) > > Once the cores are no longer busy the gic0 messages stop. > > The "on CPU" varies. The "last irq: " varies. > (But 27 is the most common by far.) > > > === > Mark Millard > markmi at dsl-only.net > > On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief wrote: > > Note that on the pine64 the network interface hangs from time to time and I > get a core dump with very low frequency from long running processes, eg the > shell that invokes "make world". Note that I had similar issues on the > ODroid-C2. > > Currently rebuilding world without MALLOC_PRODUCTION. > > The arm64 port is getting close to working 100%, just a last few glitches. > > > Op 22:03 ZA 28 Jan 2017 schreef Mark Millard : > [About: "gic0: Spurious interrupt detected" on armv6 as well.] > > On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief wrote: > > > Did a build/install world/kernel with r312916 and MALLOC_PRODUCTION=YES on > > a pine64, removed /etc/malloc.conf, rebooted > > > > and I am now rebuilding the python2 port without problems so far (except > > the "gic0: Spurious interrupt detected" messages which reappeared shortly > > after my previous post) > > While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) > during large builds (with -j 4). Recently I got a: > > gic0: Spurious interrupt detected: last irq: 29 on CPU1 > > on: > > # uname -apKU > FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 > 20:57:48 PST 2017 > markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG arm > armv6 1200020 1200020 > > while building devel/gcc6 (via a full bootstrap) via -j 4 . > > This is from a non-debug buildworld buildkernel context and has > MALLOC_PRODUCTION= in /etc/make.conf . No /etc/malloc.conf present. I do use > -mcpu=cortex-a7 . > > > > Details if you care: > > # more /usr/src/sys/arm/conf/BPIM3-NODBG > # > # BPIM3 -- Custom configuration for the Banana Pi M3 > # > > include "GENERIC" > > ident BPIM3-NODBG > > makeoptions DEBUG=-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=1 > #options BOOTHOWTO=RB_VERBOSE > #options KTR > #options KTR_MASK=KTR_TRAP > ##options KTR_CPUMASK=0xF > #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 > > > It was a from cross build for buildworld buildkernel : > (I've not checked on lldb builds linking recently.) > > # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host > TO_TYPE=armv6 > # > KERNCONF=BPIM3-NODBG > TARGET=arm > .if ${.MAKE.LEVEL} == 0 > TARGET_ARCH=${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER= > WITHOUT_SYSTEM_COMPILER= > # > #CPUTYPE=soft > WITH_LIBCPLUSPLUS= > WITH_BINUTILS_BOOTSTRAP= > WITH_CLANG_BOOTSTRAP= > WITH_CLANG= > WITH_CLANG_IS_CC= > WITH_CLANG_FULL= > WITH_CLANG_EXTRAS= > WITH_LLD= > # > # Linking lldb fails for armv6(/v7) > WITHOUT_LLDB= > # > WITH_BOOT= > WITHOUT_LIB32= > WITHOUT_LIBSOFT= > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP= > WITHOUT_GCC_BOOTSTRAP= > WITHOUT_GCC= > WITHOUT_GCC_IS_CC= > WITHOUT_GNUCXX= > # > NO_WERROR= > #WERROR= > MALLOC_PRODUCTION= > # > WITH_REPRODUCIBLE_BUILD= > WITH_DEBUG_FILES= > # > XCFLAGS+= -mcpu=cortex-a7 > XCXXFLAGS+= -mcpu=cortex-a7 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > > > Used for buildworld buildkernel : > > # more ~/src.configs/make.conf > #MALLOC_PRODUCTION= > #NO_WERROR= > #WERROR= > CFLAGS.gcc+= -v > > > Used for port builds: > > # more /etc/make.conf > WANT_QT_VERBOSE_CONFIGURE=1 > # > DEFAULT_VERSIONS+=perl5=5.24 > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > WITH_DEBUG_FILES= > MALLOC_PRODUCTION= > > > # svnlite status /usr/src/ | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/BPIM3-DBG > ? /usr/src/sys/arm/conf/BPIM3-NODBG > ? /usr/src/sys/arm/conf/RPI2-DBG > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp > M /usr/src/lib/csu/powerpc64/Makefile > M /usr/src/libexec/rtld-elf/Makefile > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > M /usr/src/sys/modules/zfs/Makefile > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > > The M's are generally tied to powerpc64 and powerpc > explorations. I tend to use the same source for all > the TARGET_ARCH's that I build. > > > === > Mark Millard > markmi at dsl-only.net > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Jan 31 08:34:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF961CCAB8B for ; Tue, 31 Jan 2017 08:34:59 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B8081B15 for ; Tue, 31 Jan 2017 08:34:59 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-yb0-x22f.google.com with SMTP id j82so114887152ybg.1 for ; Tue, 31 Jan 2017 00:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p6z+URi3wzfHWzEwiw5BOdMaAEEFX7Uz4fKhDPLMC5A=; b=FnfZwj03cJPHhiKcwLOUqnqwc58ePvGTk7e+aCLSX8vOW7mj8h7DFOJzvPjvSmuLBr 6tfFn5GXbCA8SRcRrgt2DhC3TlMJjb0Hb9hxsQBpiz8koRjyHhTjDSREy8KmQWWooM7s dYwWL5Eol0MAU5sKjwIvwAbdDPv9gzVbD7lCut24jpBOaGeUYUEpAqS6IOYDxGMUcMmO sTwM+hF9DKpc5iRNBqCuRsNaDjAqwelAJbkCrK8xQ/GKYjGh7zgVbw0vqhwiYrz11LP3 IqDikV7p2SBk3rABurhto/sMrBa+6kNMElP13M5wIdJTKm13aILt6xBgndTbeT1V+v8I xy4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p6z+URi3wzfHWzEwiw5BOdMaAEEFX7Uz4fKhDPLMC5A=; b=s+BgUFFVDut+fPHz059xT+myHrVFt/U06K17Wvq91m95MDcZWiE+hiIcCEaBT4JWBP e0HDtgJcwOntr9sDiH0XD2uz4tBl+vNaNk7BPpd76Q7J5wJpKkwAHxnHZ76Yb/zAji9b i2emc2b5T6dgUfXiRS8CTG14goJMO0DpIehksGAWvGAFLHv7vudspvv6aS+USjqhimss T1yHCi/0NWVqLJ2ulJLng9I3kA/CruyQPaN4sbW9TQeJbvwtft9fTSuU1EDOjSBLzCHw 11OjgNAXtbBQOfOnN+yBlQvzR8dHi9MUOb9MjSL4JSq4LdGNBPjiL3r/TnCw7YieAm9w TVzQ== X-Gm-Message-State: AIkVDXLDZn/QvE3j3DPkgoY2guPSA3dKByUatdoQiQd7vA62aRXjH7dtcP6AeraMU26L0SyQRZ+bv2C64e9vVg== X-Received: by 10.129.75.147 with SMTP id y141mr16658633ywa.86.1485851698375; Tue, 31 Jan 2017 00:34:58 -0800 (PST) MIME-Version: 1.0 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <20170131091304.7c5349cf@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170131091304.7c5349cf@freyja.zeit4.iv.bundesimmobilien.de> From: Tom Vijlbrief Date: Tue, 31 Jan 2017 08:34:46 +0000 Message-ID: Subject: Re: OT: HowTo: FreeBSD status for/on ODroid-C2?) To: "O. Hartmann" , Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 08:34:59 -0000 Op di 31 jan. 2017 09:13 schreef O. Hartmann : > On Mon, 30 Jan 2017 23:57:59 -0800 > Mark Millard wrote: > > > Hello, > > I'm fairly new to ARM based SoCs and I have an Odroid-C2 at hand. I try to > build the boot images by cloning/copying and adapting the process I found > in > the sysutils/u-boot-pine64 port, but my knowledge about how to build > u-boot to > provide the desired is weak. > > I was wondering if someone could give a little help in a HowTo for the > Odroid-C2. > There is no support for the ODroid-C2 in the current FreeBSD tree. About 6 months ago I wrote on this list about my experiments. I managed to get the console and USB working, so I could boot from a USB disk and use a USB ethernet adapter. > From owner-freebsd-arm@freebsd.org Tue Jan 31 09:21:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 385A4CC6C28 for ; Tue, 31 Jan 2017 09:21:51 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85E5716C6 for ; Tue, 31 Jan 2017 09:21:49 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LwW8p-1cPVXW45Ox-018N62; Tue, 31 Jan 2017 10:16:30 +0100 Date: Tue, 31 Jan 2017 10:16:28 +0100 From: "O. Hartmann" To: Tom Vijlbrief Cc: Mark Millard , freebsd-arm Subject: Re: OT: HowTo: FreeBSD status for/on ODroid-C2?) Message-ID: <20170131101628.79d22fa1@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <20170131091304.7c5349cf@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:myfWVJDIY4ncnmBDN4f+7S4wojFOeQuevKI7y/B36sqtJXwFOg9 QiD+lonRWVHVA2jBdsjdUmCjw26D9qkVCjgVG2/ZSHLdMnT1zSfY1h0exT0YF9ZdBWokfwp EJV+ZUD/ctKi5ZOXSzqB3aDFhyhoSu31EvNs/4add9W7Ym32Zf5XR+JL31z7VyLUpL5wk7p opduFsSUQNxbWHqVKS62A== X-UI-Out-Filterresults: notjunk:1;V01:K0:21k0m0fVH38=:PxTQDkO1r+by9L1VqMzgfy RvJgj/kuHSWWAssJ/K6jX3zW1nGZmWMkkjGxsUXfApdy0/3EiYYFktEei84CLKcaJUp2e2RWo lcSAz9KPumo0D10zoRVg/LJewX2FKXYld0hQIUq8Enhe5j42AIvGYD6wQe1i0c7hjDj6gWtJJ 9LCmMpVdQ8mhF04qQDX02Vi3mK7Pa+HuNeAU55UwFOog5rbvZiDk8TFkTavQVu2Eq+c+jquK5 qh7g2NaEMy5/GHV/lxpxmTvyuDN+9kjhdWJAE8z73fJfuC5KimbrokbsSnKnbHF2U1WsUw+H6 axx5hOSncoyFPslCkOH3etayVZUP+bgEP6ulwEmKB2osrgjJ6/SMAD7BDzoD+tDpv2RMkLokP gbY4hA9IeSrqgmS+DqBXCtjobKeo2Gw5dVn0ODFsByuTTlAA993r4nu2uIXOSWQumxRbT8WDE jnLOG2aCC1RVO+i4c00kLJMJrOpr8kq4+qltQwNW7ZRkXmnpI5YMFPneojtGME1CAJlI78IFr D0VrtqZmhm2oBvwZlBQEIyIeDJBRaO/YDiAMbNorni7rhVLrn8DWkGc4qdG0emS7VY17kmSzf 63xCT/R+ZOOiNfnY3Gj9X6qJ8dEfz7aDZ0iYGVIlvDB+L5bjpsuHWSdZElcYPc8dHRjl4/ikO WehkV7t7RuDUiEkP6Uu+6MW12yfjVamPN3z8BGZTMQ7Jvk9pYXegWUMH3/qCm+Ul6gHMAnV8A OfWuVTAbXF17qP0pgAOnxavXwIOOwCZdvKVcu804J+eUJ4JLnXCrEJzVAqtyupASatWhjrVyv ir8g5ULLRW0uF1gbjRqkT2atEzoeWWWnbSYp0jhVBxrMM4ijodf7G/jpM0uv73qV5AmAEl9v/ 19uBFiBPYdrDYBYHG/ZjWU6PtJVJdeMyFsWiBsVaBvtk/oEBMa5jQJ3gXYYiFZLZJf3uX05tx GZf0/DSWQXDUL96YGE85ZEp1CpEbnHl/usUswPsqq8QUIGxL/Hm/vCB8odz8v2hUZUxBIqsxt V+Ks8Ci40MS5x9l1QhouGQFHLmtZiuIEYXDIZ7CspzPRzbdemy0NuPG2l7LrmA4qqw== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 09:21:51 -0000 On Tue, 31 Jan 2017 08:34:46 +0000 Tom Vijlbrief wrote: > Op di 31 jan. 2017 09:13 schreef O. Hartmann : > > > On Mon, 30 Jan 2017 23:57:59 -0800 > > Mark Millard wrote: > > > > > > Hello, > > > > I'm fairly new to ARM based SoCs and I have an Odroid-C2 at hand. I try to > > build the boot images by cloning/copying and adapting the process I found > > in > > the sysutils/u-boot-pine64 port, but my knowledge about how to build > > u-boot to > > provide the desired is weak. > > > > I was wondering if someone could give a little help in a HowTo for the > > Odroid-C2. > > > > There is no support for the ODroid-C2 in the current FreeBSD tree. > > About 6 months ago I wrote on this list about my experiments. I managed to > get the console and USB working, so I could boot from a USB disk and use a > USB ethernet adapter. > > O, what a pity. I didn't get even that far. I checked on hardkernel's web page and git repo and found that their u-boot support is also quite old (2015.01). Do you know how the status of the Pine64 is with FreeBSD? As Mark Millard's comment in the last message let me reckon, the support seems much better and overall, the Pine64 seems to me the best choice for the moment if someone desires a A64 architecure with 2GB RAM and 1Gbit NIC (compared to the Raspberry Pi3B). Anyway, thanks for your response. Kind regards, Oliver Hartmann From owner-freebsd-arm@freebsd.org Tue Jan 31 14:30:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3660DCC95A4 for ; Tue, 31 Jan 2017 14:30:15 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F31F39F for ; Tue, 31 Jan 2017 14:30:14 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 19A142E9D3; Tue, 31 Jan 2017 07:30:08 -0700 (MST) Date: Tue, 31 Jan 2017 07:30:08 -0700 From: Brad Davis To: Balaji Palaniswami Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: Creating bootable vm disk Message-ID: <20170131143007.GU70816@corpmail.liquidneon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 14:30:15 -0000 On Mon, Jan 30, 2017 at 12:22:49PM -0800, Balaji Palaniswami wrote: > I am trying to boot using bhyve instead of hardware. So i am looking at > constructing vm disk from the output of cross compilation steps as > mentioned in wiki. Just skimmed over crochet repo, it is also constructing > the vmdisk from freebsd source tree.I am trying to figure out the way to > build vm disk in crochet which is compatible bhyve (raw). What hardware are you trying to target? Bhyve can only run x86 or x86-64 Operating Systems. If you want something other than those you'll need to use Qemu. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Tue Jan 31 15:54:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39DC7CC89DC for ; Tue, 31 Jan 2017 15:54:55 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm19-vm2.bullet.mail.ne1.yahoo.com (nm19-vm2.bullet.mail.ne1.yahoo.com [98.138.91.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FFACF0E for ; Tue, 31 Jan 2017 15:54:54 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1485877917; bh=WGdj4vgfsJlxar84Pt31tplxHlyDoAw/FtMbyP4+t+s=; h=From:Subject:To:Date:From:Subject; b=EftuPFL9jcO/uh1O+UGpQ6RRaXekFI1Iv+TtyavdsJKx+8kzEpc5oMBRmnZrhpZJ0FeaCaQlX3MWfX6DQoUaiZguY6e/9DBWaSE6uAYtLBtNbgUex1AxN1YTGg4TtceYlmhT4DJu4+i/FbvH7Y1t+RVzrw4i2Vul54JmVZatFM3c6GH3Rg3VlvG85PJMTouy09slfVwAMr/Sirpzeq0XOBdzkOTsH8EON2+SSPquj8AT/0cL/oRKnsoClTnhCqAl4ikJtFbfAB5Rx72i0umKINORItRvRPxuSR9dIvLgKybFRSfowDuh7V5b6ix6KI1aHtHt81Qn5lhNHWEx7TtCAQ== Received: from [98.138.101.132] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2017 15:51:57 -0000 Received: from [98.138.104.113] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2017 15:51:57 -0000 Received: from [127.0.0.1] by smtp222.mail.ne1.yahoo.com with NNFMP; 31 Jan 2017 15:51:57 -0000 X-Yahoo-Newman-Id: 464541.44334.bm@smtp222.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MsT_gIcVM1kLLmeyM_TeXioE3fErBUzGmWUx30vvwAa04ra v4.u2IL8R.JoYrSgO8NULVQkN2a.oMnFDp1htx8w.t4CQx7.fgKMdMjNNEAO CA5FcM67RxXLIe6nYZV27_Lkejxq1WaeTZ0sPKTEyRHGsVZgnYLCRdwsYojn Ur0nfO5h2w9gL.8Ob.A9PHnZ7vnNzGL0WLUC6gqoq1JzkrWU06_bhDUXYQv4 NeeRWXYf_dX5zSLIfjBq1omFn02bFo4OmocH.PAvbR2J9Qgxv1JRAqGInatj nK9CJRDfMctBNtObk15O1X6z2x_rhjtjv6vP_P__LNu0NtMVF_gTVfHfxGZR QTsLDbWfJAUWOCd_BVFJlMivR9mCNtcDIiz63hEvRQgMcmy6Jz8D9lNY1vOn frBOWtknL9UUSe21ARHIrsxwxC8k_7kXl3AHCaVEhX_qnPsjHYYfpy.7C7DR q9SBpId2gZVJOcV8H2aX1lXDy0SZ5FeUkeKK4uXbwa1gky6tlsEL40inh2Vw UcXynJrGfbmEU8teybyVJeVX3zGzCcdUZqUUlSgnCtUXqwQI- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf From: Pedro Giffuni Subject: OpenOffice for FreeBSD ARM: any taker? To: freebsd-arm@FreeBSD.org Message-ID: Date: Tue, 31 Jan 2017 10:54:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:54:55 -0000 Hello; Recently a volunteer had success in bringing FreeBSD PPC support to Apache OpenOffice. There is some interest in maintaining better support for FreeBSD and AOO has support for ARM32. It appears openjdk works too so I gave a try on copying the internal necessary code from the linux/gcc port and provide the start of a FreeBSD arm32 port (aarch64 is not available, sorry). It is likely to take quite a long time to build and I suspect there may be some effort required to build the "bridges" code with arm-clang as well. It is completely untested but, as of today, the editors/openoffice-devel (upstream r1780246)port should be in good shape to get a real port started, should any volunteer wish to step in and finish it. Of course, I would be glad to help upstream changes as required: I just don't have an ARM platform but I am sure it would be nice to have OpenOffice on it ;). Regards, Pedro. From owner-freebsd-arm@freebsd.org Tue Jan 31 19:14:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 311CCCCABBA for ; Tue, 31 Jan 2017 19:14:50 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E91E814B0; Tue, 31 Jan 2017 19:14:49 +0000 (UTC) (envelope-from heisenbug.bala@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id j13so139107871iod.3; Tue, 31 Jan 2017 11:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y6QYas6IxsfoWlxvxCPr6/2fqORuTvtYLlrsTJo657k=; b=Q8NPqcpEk0QhDy4aOdLOG817RD/w7GjJ8gHW7x94rfdQCx7igVK8hqJk51VICKJ9Ef RP43x5PoPQxRZaIrzNbkwF/LjlAFO4NieZ5LcAEeuwyvS8S1vFnIF1LJbbQqlwpjTpKj QGtyX9sfCXgrKW0zh8pQdCQ+ChGjB9sHtNFlQSkfHtDgyQKBF2c0oo9B0lLBws7c4Nkq GWJg593DL3ljqMeXegkChGs8jXoM39s7TepJAmXayh148f3ZSNEE60jKUKDzRQx7DztV OGNpHEfShqYZOtlOLReQsJlvGiGlYGgLBu+wuLVB11LVCfOu/PG9Sa2luspQV1oaBjkI nI2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y6QYas6IxsfoWlxvxCPr6/2fqORuTvtYLlrsTJo657k=; b=jARmiAHMm/S1trWbqG9EqehRs93JEyOpscgFhTL0mUvnDPOA1wJTPAYEOyf8uNl5mN l+2Ces+PB156+suwHMP6IaKmptRPR/xZWVBuJTyWw+KZroR13QkUdPHtAZ1adFS0bypI IZg6tm/CUWbYyZmtD+v9GhDEVUqs0lQm+8Gpl/OSPiCxeQfsh75+mqSKeohK0P/4eQ/5 jgfEFLis5zdo7f6pymgeqdu3e0djqOmQiZ2kOZBzo3mDJzOq6VnrBAqY1/+Y7J8+syKf xX1snceSBycaxf1X+15nIgr6hFUp8f0BCKdHwVAUP09/SLiQRbM5mVTtprqXC+PeloJk gjOQ== X-Gm-Message-State: AIkVDXKbxtLLKJCk0uoRSs4hX4nRNeN9QJvXJBL+1nPI6rz42gzUHaQD5LSwhEWPb96CzQlYoVnbBo+10tRVnw== X-Received: by 10.107.136.90 with SMTP id k87mr23218728iod.34.1485890089143; Tue, 31 Jan 2017 11:14:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.70.84 with HTTP; Tue, 31 Jan 2017 11:14:48 -0800 (PST) In-Reply-To: <20170131143007.GU70816@corpmail.liquidneon.com> References: <20170131143007.GU70816@corpmail.liquidneon.com> From: Balaji Palaniswami Date: Tue, 31 Jan 2017 11:14:48 -0800 Message-ID: Subject: Re: Creating bootable vm disk To: Brad Davis Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:14:50 -0000 On Tue, Jan 31, 2017 at 6:30 AM, Brad Davis wrote: > On Mon, Jan 30, 2017 at 12:22:49PM -0800, Balaji Palaniswami wrote: > > I am trying to boot using bhyve instead of hardware. So i am looking at > > constructing vm disk from the output of cross compilation steps as > > mentioned in wiki. Just skimmed over crochet repo, it is also > constructing > > the vmdisk from freebsd source tree.I am trying to figure out the way to > > build vm disk in crochet which is compatible bhyve (raw). > > What hardware are you trying to target? Bhyve can only run x86 or x86-64 > Operating Systems. If you want something other than those you'll need to > use Qemu. > > > Regards, > Brad Davis > > BeagleBone Black. Thanks for your info. From owner-freebsd-arm@freebsd.org Tue Jan 31 20:35:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 144B7CCA7D7 for ; Tue, 31 Jan 2017 20:35:40 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D496BE4B for ; Tue, 31 Jan 2017 20:35:39 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id 19so29581336pfo.3 for ; Tue, 31 Jan 2017 12:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=yRBBYk23C6zk1IzSBpQY6uSnjpjI4uj65PjG6j3Tsrw=; b=mrSGJZ6x4Nj7HqQvZ2CmiDnobBtpBSUdQ3kRO+4Q3Qm+nPyTd96SN5kQvs/05uCKwd CFAQaXNRqZX0UNGPkPrPyS0K11WRykRKPDrsRPCrZaZve5l8rPHjPT46e3iywlv2LHD5 gw6eyn50MAoP2uZE7EEW9Xzr/o0zpH8FXxSpqOd0+1HehAjsrITmT7NGjFDozQtqoXMO HkdUobQjaP+9TRFDs1DZIS45lvKt34uj4rrWZOVQ/Usdy6fhK2sgtImdkQXrXpSp7zEk z3XdsL0c7eJEkjLfEcY7nPfxNjOD9xmMcegQML0G/2/QRqDd7TKYmbCOb+5bCdZIUkN5 g3og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=yRBBYk23C6zk1IzSBpQY6uSnjpjI4uj65PjG6j3Tsrw=; b=VXDQvuJpnb6QgOREWCdIwTzjbCG09TfDRoFPkU3+h7wDk53Bk7Kyu+CbXAkLcBKe1B VHm06bV3NRf+ZECGcn1RDPNQf8P1TdYCzewAkPt+lMM5OAl93J5p3egINIunVouSwYXw 4GRypqfzNBuCcYBmb/kYNVpkbJ166G43lUT0hfzZXSZ/lPEsptJJkpULG/896CH1/7hB uw2oMq7hYQY+p+gm67MZtW+SMcunmvRKEGVprBNc7Vk+ouoDZ/AsLLFpqnIcCDngIy+X w3vL2/vIFWaSi6o2/Lr2vE291I7HOBzKdsZhb+upGprDtgo5g7YESm7dI2u3joIrozBX bzsQ== X-Gm-Message-State: AIkVDXJg8quHgNL21RRkHX31K/hXlwn2kdBMfp5YHdZ0DG3rjXapf0zDCnI6VmTbkNtNFA== X-Received: by 10.84.232.201 with SMTP id x9mr42405392plm.102.1485894939181; Tue, 31 Jan 2017 12:35:39 -0800 (PST) Received: from ?IPv6:2601:1c0:ce01:a5b7:3450:d3e9:2ae0:c9fb? ([2601:1c0:ce01:a5b7:3450:d3e9:2ae0:c9fb]) by smtp.gmail.com with ESMTPSA id o24sm43311975pfj.78.2017.01.31.12.35.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 12:35:38 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Tue, 31 Jan 2017 12:35:37 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: Message-Id: <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:35:40 -0000 [More notes on what I observe on a pine64 from head -r312982 .] On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: > Note that on the pine64 the network interface hangs from time to time = and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". I got sh crashes (multiple processes in the same time frame) from just trying to build pkg: make[5]: stopped in = /usr/obj/portswork/usr/ports/ports-mgmt/pkg/work/pkg-1.9.4/libpkg *** [all-recursive] Error code 1 # ls -lt /var/crash/ total 41764 -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13676.core -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13511.core -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13499.core -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.12095.core -rw-r--r-- 1 root wheel 5 Nov 3 10:18 minfree In all the crashes lldb on the .core shows that the pc was no longer pointing a memory with code in it. It is interesting that all 4 sh instances died at about the same time. SIGILL, SIGSEGV, SIGBUS, and SIGILL (again) from the non-code consequences. The two SIGILL's have some interesting similarities to each other. So I list them first below. x0-x3, x8-x9, x13, x17, x27, and cpsr all match in these two. x1=3Dld-elf.so.1`_rtld_tlsdesc, x17=3Dlibc.so.7`__free at jemalloc_jemalloc.c:2007, x23=3Dld-elf.so.1`symlook_global + 124 at rtld.c:3916, x27=3Dsh..bss + 6336. The other two have the following in common: x10-x12, x16-x17. x17=3Dlibc.so.7`close at close.c:48 . x18 =3D 0xaaaaaaaaaaaaaaab is common between one SIGILL and one not. Only one does not have x27=3Dsh..bss + 6336. It instead has: x28=3Dsh..bss + 6336 . (lldb) bt * thread #1: tid =3D 100142, 0x000000004044f800, name =3D 'sh', stop = reason =3D signal SIGILL * frame #0: 0x000000004044f800 (lldb) register read General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc x2 =3D 0x0000000040a00000 x3 =3D 0x0000000000000002 x4 =3D 0x0000000000000050 x5 =3D 0x0000000040a4c9c0 x6 =3D 0x2e2e2f2e2e2f2e2e x7 =3D 0x6c6f6f7462696c2f x8 =3D 0x0000000000000001 x9 =3D 0x0000000000000000 x10 =3D 0x00000000000000df x11 =3D 0x000000000000002f x12 =3D 0x0000000040a0e690 x13 =3D 0x0000000000000427 x14 =3D 0x0000000000000001 x15 =3D 0x0000000000000000 x16 =3D 0x0000000000432340 =20 x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 x18 =3D 0x0000000000000000 x19 =3D 0x000000004044e330 x20 =3D 0x000000001c93deed x21 =3D 0x0000000007ab9b5c x22 =3D 0x00000000404ba7b0 =20 x23 =3D 0x000000004043c4b0 ld-elf.so.1`symlook_global + 124 at = rtld.c:3916 x24 =3D 0x0000ffffffffd2d0 x25 =3D 0x0000ffffffffd370 x26 =3D 0x0000ffffffffd340 x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a4c1b0 fp =3D 0x0000ffff00000001 lr =3D 0x000000004044f800 sp =3D 0x0000ffffffffd2a0 pc =3D 0x000000004044f800 cpsr =3D 0x60000000 (lldb) disass -> 0x4044f800: .long 0xd550b87a ; unknown opcode 0x4044f804: .long 0x00000000 ; unknown opcode 0x4044f808: .long 0x00000001 ; unknown opcode 0x4044f80c: .long 0x00000000 ; unknown opcode 0x4044f810: .long 0x4044fc00 ; unknown opcode 0x4044f814: .long 0x00000000 ; unknown opcode 0x4044f818: .long 0x4044f410 ; unknown opcode 0x4044f81c: .long 0x00000000 ; unknown opcode (lldb) thread list Process 0 stopped * thread #1: tid =3D 100161, 0x0000ffffffffee68, name =3D 'sh', stop = reason =3D signal SIGILL (lldb) register read General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc x2 =3D 0x0000000040a00000 x3 =3D 0x0000000000000002 x4 =3D 0x0000000000000017 x5 =3D 0x00080002a0290a00 x6 =3D 0x0000000000434c28 sh..bss + 9448 x7 =3D 0x000000000005e1cd x8 =3D 0x0000000000000001 x9 =3D 0x0000000000000000 x10 =3D 0x0000000000000000 x11 =3D 0x0000000040a5c000 x12 =3D 0x0000000040a0e670 x13 =3D 0x0000000000000427 x14 =3D 0x000000000000000d x15 =3D 0x0000000000432740 sh..bss + 0 x16 =3D 0x0000000000432340 =20 x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 x18 =3D 0xaaaaaaaaaaaaaaab x19 =3D 0x0000ffffffffee18 x20 =3D 0x0000ffffffffedb4 x21 =3D 0x0000ffffffffed80 x22 =3D 0x0000ffffffffed59 x23 =3D 0x0000ffffffffed47 x24 =3D 0x0000ffffffffed38 x25 =3D 0x0000ffffffffed28 x26 =3D 0x0000ffffffffed20 x27 =3D 0x0000000000434000 sh..bss + 6336 x28 =3D 0x0000000040a803a0 fp =3D 0x0000ffffffffee59 lr =3D 0x0000ffffffffee68 sp =3D 0x0000ffffffffe1a0 pc =3D 0x0000ffffffffee68 cpsr =3D 0x60000000 (lldb) disass -> 0xffffffffee68: .long 0x44504d54 ; unknown opcode 0xffffffffee6c: .long 0x2f3d5249 ; unknown opcode 0xffffffffee70: .long 0x00706d74 ; unknown opcode 0xffffffffee74: .long 0x4c454853 ; unknown opcode 0xffffffffee78: .long 0x622f3d4c ; unknown opcode 0xffffffffee7c: .long 0x732f6e69 ; unknown opcode 0xffffffffee80: .long 0x4f430068 ; unknown opcode 0xffffffffee84: .long 0x4749464e ; unknown opcode (lldb) bt * thread #1: tid =3D 100088, 0x356c7265702f676e, name =3D 'sh', stop = reason =3D signal SIGBUS * frame #0: 0x356c7265702f676e (lldb) register read General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x0000000000000000 x2 =3D 0x0000000040a00000 x3 =3D 0x0000000000000005 x4 =3D 0x0000000000000038 x5 =3D 0x0000000040a754e5 x6 =3D 0x584946455250442d x7 =3D 0x6c2f7273752f223d x8 =3D 0x0000000000000000 x9 =3D 0x0000000000000000 x10 =3D 0x0000000000434000 sh..bss + 6336 x11 =3D 0x0000000000000000 x12 =3D 0x0000000000434217 sh..bss + 6871 x13 =3D 0x0000000000434000 sh..bss + 6336 x14 =3D 0x0000000000432000 sh`__frame_dummy_init_array_entry x15 =3D 0x000000000000003d x16 =3D 0x00000000004322b0 =20 x17 =3D 0x000000004050d090 libc.so.7`close at close.c:48 x18 =3D 0xaaaaaaaaaaaaaaab x19 =3D 0x766564206f666e69 x20 =3D 0x7865646e692f746e x21 =3D 0x69727020676b702f x22 =3D 0x746d676d2d737472 x23 =3D 0x6f7020656d69746e x24 =3D 0x75722d7478657474 x25 =3D 0x65672f6c65766564 x26 =3D 0x206e6f7369622f6c x27 =3D 0x0000000040a53716 x28 =3D 0x0000000000434000 sh..bss + 6336 fp =3D 0x616c20346d2f6c65 lr =3D 0x356c7265702f676e sp =3D 0x0000ffffffffe740 pc =3D 0x356c7265702f676e cpsr =3D 0x20000000 (lldb) disass error: core file does not contain 0x356c7265702f676e error: Failed to disassemble memory at 0xffffffffffffffff. (lldb) bt * thread #1: tid =3D 100186, 0x0000000000000000, name =3D 'sh', stop = reason =3D signal SIGSEGV * frame #0: 0x0000000000000000 (lldb) disass error: core file does not contain 0x0 error: Failed to disassemble memory at 0xffffffffffffffff. (lldb) register read General Purpose Registers: x0 =3D 0x0000000000000000 x1 =3D 0x0000000000000000 x2 =3D 0x0000000000000002 x3 =3D 0x0000000000006c6f x4 =3D 0x0000000040a50bb3 x5 =3D 0x0000000040a499ba x6 =3D 0x6f7462696c2f2e2e x7 =3D 0x6c6f6f7462696c2f x8 =3D 0x0000000000000000 x9 =3D 0x0000000000000000 x10 =3D 0x0000000000434000 sh..bss + 6336 x11 =3D 0x0000000000000000 x12 =3D 0x0000000040a499f8 x13 =3D 0x0000000000434000 sh..bss + 6336 x14 =3D 0x0000000000000001 x15 =3D 0x0000000000000000 x16 =3D 0x00000000004322b0 =20 x17 =3D 0x000000004050d090 libc.so.7`close at close.c:48 x18 =3D 0x0000000000000000 x19 =3D 0x0000000000000065 x20 =3D 0x0000000000000065 x21 =3D 0x00000000004168f0 sh`readtoken1 + 5212 at parser.c:1602 x22 =3D 0x0000ffffffffda90 x23 =3D 0x0000000040a498c0 x24 =3D 0x000000000000000a x25 =3D 0x0000000000000000 x26 =3D 0x0000000000000000 x27 =3D 0x0000000040a49258 x28 =3D 0x0000000000434000 sh..bss + 6336 fp =3D 0x0000ffffffffda08 lr =3D 0x0000000000000000 sp =3D 0x0000ffffffffd970 pc =3D 0x0000000000000000 cpsr =3D 0x20000000 Looks to me like something major is wrong. On 2017-Jan-30, at 11:57 PM, Mark Millard = wrote: > I updated to head -r312982 on the pine64 that I have access to: >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 >=20 > after several months of not using the pine64. > ( -mcpu=3Dcortex-a53 used for buildworld buildkernel; > non-debug variant of GENERIC [GENERIC included > then overridden]; usb SSD root file system) >=20 > I find that any time some of the cores are busy I get thousands > of the gic0 spurious interrupt messages in fairly sort order. > (This is not new: it is unchanged.) >=20 > For example during either of: >=20 > openssl speed >=20 > or: >=20 > cp /dev/zero /dev/null > (similarly for copying actual files around, > local or nfs involved) >=20 > Once the cores are no longer busy the gic0 messages stop. >=20 > The "on CPU" varies. The "last irq: " varies. > (But 27 is the most common by far.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: Note that on the pine64 the network interface hangs from time to time = and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". Note that I had = similar issues on the ODroid-C2. Currently rebuilding world without MALLOC_PRODUCTION. The arm64 port is getting close to working 100%, just a last few = glitches. Op 22:03 ZA 28 Jan 2017 schreef Mark Millard : [About: "gic0: Spurious interrupt detected" on armv6 as well.] On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief = wrote: > Did a build/install world/kernel with r312916 and = MALLOC_PRODUCTION=3DYES on > a pine64, removed /etc/malloc.conf, rebooted >=20 > and I am now rebuilding the python2 port without problems so far = (except > the "gic0: Spurious interrupt detected" messages which reappeared = shortly > after my previous post) While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) during large builds (with -j 4). Recently I got a: gic0: Spurious interrupt detected: last irq: 29 on CPU1 on: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 = 20:57:48 PST 2017 = markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG = arm armv6 1200020 1200020 while building devel/gcc6 (via a full bootstrap) via -j 4 . This is from a non-debug buildworld buildkernel context and has = MALLOC_PRODUCTION=3D in /etc/make.conf . No /etc/malloc.conf present. I do use = -mcpu=3Dcortex-a7 . Details if you care: # more /usr/src/sys/arm/conf/BPIM3-NODBG # # BPIM3 -- Custom configuration for the Banana Pi M3 # include "GENERIC" ident BPIM3-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 It was a from cross build for buildworld buildkernel : (I've not checked on lldb builds linking recently.) # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host TO_TYPE=3Darmv6 # KERNCONF=3DBPIM3-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. Used for buildworld buildkernel : # more ~/src.configs/make.conf #MALLOC_PRODUCTION=3D #NO_WERROR=3D #WERROR=3D CFLAGS.gcc+=3D -v Used for port builds: # more /etc/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/ofw/ofw_machdep.c The M's are generally tied to powerpc64 and powerpc explorations. I tend to use the same source for all the TARGET_ARCH's that I build. =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Feb 1 02:30:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D9B5CCB37A for ; Wed, 1 Feb 2017 02:30:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EE27330 for ; Wed, 1 Feb 2017 02:30:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16771 invoked from network); 1 Feb 2017 02:30:41 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Feb 2017 02:30:41 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Tue, 31 Jan 2017 21:30:41 -0500 (EST) Received: (qmail 7642 invoked from network); 1 Feb 2017 02:30:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Feb 2017 02:30:41 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9F6C1EC7D4D; Tue, 31 Jan 2017 18:30:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) From: Mark Millard In-Reply-To: <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> Date: Tue, 31 Jan 2017 18:30:39 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> To: Tom Vijlbrief X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 02:30:49 -0000 [Just adding more accurate/precise times for the .core files.] [The original was accidentally sent from the "wrong" E-mail account but I've adjusted that here.] On 2017-Jan-31, at 12:35 PM, Mark Millard = wrote: > [More notes on what I observe on a pine64 from head -r312982 .] >=20 > On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: >=20 >> Note that on the pine64 the network interface hangs from time to time = and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". >=20 > I got sh crashes (multiple processes in the same time frame) from > just trying to build pkg: >=20 > make[5]: stopped in = /usr/obj/portswork/usr/ports/ports-mgmt/pkg/work/pkg-1.9.4/libpkg > *** [all-recursive] Error code 1 >=20 > # ls -lt /var/crash/ > total 41764 > -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13676.core > -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13511.core > -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13499.core > -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.12095.core > -rw-r--r-- 1 root wheel 5 Nov 3 10:18 minfree >=20 > In all the crashes lldb on the .core shows that the pc was no longer > pointing a memory with code in it. It is interesting that all > 4 sh instances died at about the same time. More time detail (using -T): -rw------- 1 root wheel 4702208 Jan 31 03:15:44 2017 sh.13676.core -rw------- 1 root wheel 4702208 Jan 31 03:15:43 2017 sh.13511.core -rw------- 1 root wheel 4702208 Jan 31 03:15:42 2017 sh.13499.core -rw------- 1 root wheel 4702208 Jan 31 03:15:32 2017 sh.12095.core > SIGILL, SIGSEGV, SIGBUS, and SIGILL (again) from the non-code > consequences. >=20 > The two SIGILL's have some interesting similarities to each other. > So I list them first below. x0-x3, x8-x9, x13, x17, x27, and cpsr > all match in these two. x1=3Dld-elf.so.1`_rtld_tlsdesc, > x17=3Dlibc.so.7`__free at jemalloc_jemalloc.c:2007, > x23=3Dld-elf.so.1`symlook_global + 124 at rtld.c:3916, > x27=3Dsh..bss + 6336. >=20 > The other two have the following in common: > x10-x12, x16-x17. x17=3Dlibc.so.7`close at close.c:48 . >=20 > x18 =3D 0xaaaaaaaaaaaaaaab is common between one SIGILL and one not. >=20 > Only one does not have x27=3Dsh..bss + 6336. It instead has: > x28=3Dsh..bss + 6336 . >=20 > (lldb) bt > * thread #1: tid =3D 100142, 0x000000004044f800, name =3D 'sh', stop = reason =3D signal SIGILL > * frame #0: 0x000000004044f800 > (lldb) register read > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc > x2 =3D 0x0000000040a00000 > x3 =3D 0x0000000000000002 > x4 =3D 0x0000000000000050 > x5 =3D 0x0000000040a4c9c0 > x6 =3D 0x2e2e2f2e2e2f2e2e > x7 =3D 0x6c6f6f7462696c2f > x8 =3D 0x0000000000000001 > x9 =3D 0x0000000000000000 > x10 =3D 0x00000000000000df > x11 =3D 0x000000000000002f > x12 =3D 0x0000000040a0e690 > x13 =3D 0x0000000000000427 > x14 =3D 0x0000000000000001 > x15 =3D 0x0000000000000000 > x16 =3D 0x0000000000432340 =20 > x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 > x18 =3D 0x0000000000000000 > x19 =3D 0x000000004044e330 > x20 =3D 0x000000001c93deed > x21 =3D 0x0000000007ab9b5c > x22 =3D 0x00000000404ba7b0 =20 > x23 =3D 0x000000004043c4b0 ld-elf.so.1`symlook_global + 124 at = rtld.c:3916 > x24 =3D 0x0000ffffffffd2d0 > x25 =3D 0x0000ffffffffd370 > x26 =3D 0x0000ffffffffd340 > x27 =3D 0x0000000000434000 sh..bss + 6336 > x28 =3D 0x0000000040a4c1b0 > fp =3D 0x0000ffff00000001 > lr =3D 0x000000004044f800 > sp =3D 0x0000ffffffffd2a0 > pc =3D 0x000000004044f800 > cpsr =3D 0x60000000 > (lldb) disass > -> 0x4044f800: .long 0xd550b87a ; unknown opcode > 0x4044f804: .long 0x00000000 ; unknown opcode > 0x4044f808: .long 0x00000001 ; unknown opcode > 0x4044f80c: .long 0x00000000 ; unknown opcode > 0x4044f810: .long 0x4044fc00 ; unknown opcode > 0x4044f814: .long 0x00000000 ; unknown opcode > 0x4044f818: .long 0x4044f410 ; unknown opcode > 0x4044f81c: .long 0x00000000 ; unknown opcode >=20 > (lldb) thread list > Process 0 stopped > * thread #1: tid =3D 100161, 0x0000ffffffffee68, name =3D 'sh', stop = reason =3D signal SIGILL > (lldb) register read > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc > x2 =3D 0x0000000040a00000 > x3 =3D 0x0000000000000002 > x4 =3D 0x0000000000000017 > x5 =3D 0x00080002a0290a00 > x6 =3D 0x0000000000434c28 sh..bss + 9448 > x7 =3D 0x000000000005e1cd > x8 =3D 0x0000000000000001 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000000000 > x11 =3D 0x0000000040a5c000 > x12 =3D 0x0000000040a0e670 > x13 =3D 0x0000000000000427 > x14 =3D 0x000000000000000d > x15 =3D 0x0000000000432740 sh..bss + 0 > x16 =3D 0x0000000000432340 =20 > x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 > x18 =3D 0xaaaaaaaaaaaaaaab > x19 =3D 0x0000ffffffffee18 > x20 =3D 0x0000ffffffffedb4 > x21 =3D 0x0000ffffffffed80 > x22 =3D 0x0000ffffffffed59 > x23 =3D 0x0000ffffffffed47 > x24 =3D 0x0000ffffffffed38 > x25 =3D 0x0000ffffffffed28 > x26 =3D 0x0000ffffffffed20 > x27 =3D 0x0000000000434000 sh..bss + 6336 > x28 =3D 0x0000000040a803a0 > fp =3D 0x0000ffffffffee59 > lr =3D 0x0000ffffffffee68 > sp =3D 0x0000ffffffffe1a0 > pc =3D 0x0000ffffffffee68 > cpsr =3D 0x60000000 > (lldb) disass > -> 0xffffffffee68: .long 0x44504d54 ; unknown opcode > 0xffffffffee6c: .long 0x2f3d5249 ; unknown opcode > 0xffffffffee70: .long 0x00706d74 ; unknown opcode > 0xffffffffee74: .long 0x4c454853 ; unknown opcode > 0xffffffffee78: .long 0x622f3d4c ; unknown opcode > 0xffffffffee7c: .long 0x732f6e69 ; unknown opcode > 0xffffffffee80: .long 0x4f430068 ; unknown opcode > 0xffffffffee84: .long 0x4749464e ; unknown opcode >=20 > (lldb) bt > * thread #1: tid =3D 100088, 0x356c7265702f676e, name =3D 'sh', stop = reason =3D signal SIGBUS > * frame #0: 0x356c7265702f676e > (lldb) register read > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x0000000000000000 > x2 =3D 0x0000000040a00000 > x3 =3D 0x0000000000000005 > x4 =3D 0x0000000000000038 > x5 =3D 0x0000000040a754e5 > x6 =3D 0x584946455250442d > x7 =3D 0x6c2f7273752f223d > x8 =3D 0x0000000000000000 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000434000 sh..bss + 6336 > x11 =3D 0x0000000000000000 > x12 =3D 0x0000000000434217 sh..bss + 6871 > x13 =3D 0x0000000000434000 sh..bss + 6336 > x14 =3D 0x0000000000432000 sh`__frame_dummy_init_array_entry > x15 =3D 0x000000000000003d > x16 =3D 0x00000000004322b0 =20 > x17 =3D 0x000000004050d090 libc.so.7`close at close.c:48 > x18 =3D 0xaaaaaaaaaaaaaaab > x19 =3D 0x766564206f666e69 > x20 =3D 0x7865646e692f746e > x21 =3D 0x69727020676b702f > x22 =3D 0x746d676d2d737472 > x23 =3D 0x6f7020656d69746e > x24 =3D 0x75722d7478657474 > x25 =3D 0x65672f6c65766564 > x26 =3D 0x206e6f7369622f6c > x27 =3D 0x0000000040a53716 > x28 =3D 0x0000000000434000 sh..bss + 6336 > fp =3D 0x616c20346d2f6c65 > lr =3D 0x356c7265702f676e > sp =3D 0x0000ffffffffe740 > pc =3D 0x356c7265702f676e > cpsr =3D 0x20000000 >=20 > (lldb) disass > error: core file does not contain 0x356c7265702f676e > error: Failed to disassemble memory at 0xffffffffffffffff. >=20 >=20 >=20 > (lldb) bt > * thread #1: tid =3D 100186, 0x0000000000000000, name =3D 'sh', stop = reason =3D signal SIGSEGV > * frame #0: 0x0000000000000000 > (lldb) disass > error: core file does not contain 0x0 > error: Failed to disassemble memory at 0xffffffffffffffff. > (lldb) register read > General Purpose Registers: > x0 =3D 0x0000000000000000 > x1 =3D 0x0000000000000000 > x2 =3D 0x0000000000000002 > x3 =3D 0x0000000000006c6f > x4 =3D 0x0000000040a50bb3 > x5 =3D 0x0000000040a499ba > x6 =3D 0x6f7462696c2f2e2e > x7 =3D 0x6c6f6f7462696c2f > x8 =3D 0x0000000000000000 > x9 =3D 0x0000000000000000 > x10 =3D 0x0000000000434000 sh..bss + 6336 > x11 =3D 0x0000000000000000 > x12 =3D 0x0000000040a499f8 > x13 =3D 0x0000000000434000 sh..bss + 6336 > x14 =3D 0x0000000000000001 > x15 =3D 0x0000000000000000 > x16 =3D 0x00000000004322b0 =20 > x17 =3D 0x000000004050d090 libc.so.7`close at close.c:48 > x18 =3D 0x0000000000000000 > x19 =3D 0x0000000000000065 > x20 =3D 0x0000000000000065 > x21 =3D 0x00000000004168f0 sh`readtoken1 + 5212 at = parser.c:1602 > x22 =3D 0x0000ffffffffda90 > x23 =3D 0x0000000040a498c0 > x24 =3D 0x000000000000000a > x25 =3D 0x0000000000000000 > x26 =3D 0x0000000000000000 > x27 =3D 0x0000000040a49258 > x28 =3D 0x0000000000434000 sh..bss + 6336 > fp =3D 0x0000ffffffffda08 > lr =3D 0x0000000000000000 > sp =3D 0x0000ffffffffd970 > pc =3D 0x0000000000000000 > cpsr =3D 0x20000000 >=20 >=20 > Looks to me like something major is wrong. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-30, at 11:57 PM, Mark Millard = wrote: > I updated to head -r312982 on the pine64 that I have access to: >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 >=20 > after several months of not using the pine64. > ( -mcpu=3Dcortex-a53 used for buildworld buildkernel; > non-debug variant of GENERIC [GENERIC included > then overridden]; usb SSD root file system) >=20 > I find that any time some of the cores are busy I get thousands > of the gic0 spurious interrupt messages in fairly sort order. > (This is not new: it is unchanged.) >=20 > For example during either of: >=20 > openssl speed >=20 > or: >=20 > cp /dev/zero /dev/null > (similarly for copying actual files around, > local or nfs involved) >=20 > Once the cores are no longer busy the gic0 messages stop. >=20 > The "on CPU" varies. The "last irq: " varies. > (But 27 is the most common by far.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: Note that on the pine64 the network interface hangs from time to time = and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". Note that I had = similar issues on the ODroid-C2. Currently rebuilding world without MALLOC_PRODUCTION. The arm64 port is getting close to working 100%, just a last few = glitches. Op 22:03 ZA 28 Jan 2017 schreef Mark Millard : [About: "gic0: Spurious interrupt detected" on armv6 as well.] On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief = wrote: > Did a build/install world/kernel with r312916 and = MALLOC_PRODUCTION=3DYES on > a pine64, removed /etc/malloc.conf, rebooted >=20 > and I am now rebuilding the python2 port without problems so far = (except > the "gic0: Spurious interrupt detected" messages which reappeared = shortly > after my previous post) While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) during large builds (with -j 4). Recently I got a: gic0: Spurious interrupt detected: last irq: 29 on CPU1 on: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 = 20:57:48 PST 2017 = markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG = arm armv6 1200020 1200020 while building devel/gcc6 (via a full bootstrap) via -j 4 . This is from a non-debug buildworld buildkernel context and has = MALLOC_PRODUCTION=3D in /etc/make.conf . No /etc/malloc.conf present. I do use = -mcpu=3Dcortex-a7 . Details if you care: # more /usr/src/sys/arm/conf/BPIM3-NODBG # # BPIM3 -- Custom configuration for the Banana Pi M3 # include "GENERIC" ident BPIM3-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 It was a from cross build for buildworld buildkernel : (I've not checked on lldb builds linking recently.) # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host TO_TYPE=3Darmv6 # KERNCONF=3DBPIM3-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. Used for buildworld buildkernel : # more ~/src.configs/make.conf #MALLOC_PRODUCTION=3D #NO_WERROR=3D #WERROR=3D CFLAGS.gcc+=3D -v Used for port builds: # more /etc/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/ofw/ofw_machdep.c The M's are generally tied to powerpc64 and powerpc explorations. I tend to use the same source for all the TARGET_ARCH's that I build. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Feb 1 02:39:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E30C2CCB658 for ; Wed, 1 Feb 2017 02:39:07 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE6D395A for ; Wed, 1 Feb 2017 02:39:07 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: by mail-pf0-x229.google.com with SMTP id e4so114031106pfg.1 for ; Tue, 31 Jan 2017 18:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=tJpUOdS8CYz3dbrP7CJW629MtwjWa0pmA5TxGfimqIo=; b=C4mM29dyjZPjA0Z4/WX+bjRC8J9IYL9MNpAWWat1uX4nIU3xMNfNh1+ZEyb7VXgdap JwXDld0ZkOoHPCPdZdbD7Wj1Eta2BKuYvsuAKwmLLD3F2qWFVwVrvuJPL84TSNO3v1Vp KgANCmE9GVsVFHpf2DEr6DHP+TNZ9OgDGDuIpMZ0TNn6bSrvhwaNfky8fKz0REFNYENn oq30XSnZF4dXexKwtrzdSafpjz63ufcpYbZfDmcAzq9HCF7oT6tFAdxRlszrM7DtC+64 3973suOPLAJ48itiqaXBygkAbp4pDJ66sAZQw6L9BR1Ps8PXIt0UBmtsoeJ1Dw6KB7yZ /z4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=tJpUOdS8CYz3dbrP7CJW629MtwjWa0pmA5TxGfimqIo=; b=DFP28sUet7P5jSbqlx420DBxK7q3uOfKywZeXxvCLN2iWRAJddF+GeDiDt3lmyLUe0 fkH5lUvIZ8xZDxr1Rz7UhuaK2T2SkJOK9Y6X/GRtjQXTGNoVOrK5ltn8zSNnV3kxUYlJ GU3znY+nRbX2EOWlsT5Ckj15FDMyMORsjk19PVkCcEF+HaWus3QHIJZh9jFsjGIzHjyK iLvQXqZ+irHhsyVLTIusjOI/6fMhGV9XwV5Oohbv+N4sEiXzNE9RfxEKOjwoB+kDGhMU wKpeHUilYGJTofDx2AdPqM4NJ6TKBYtaw1wxjclT4HLEJAXvTiiz1y9VMR3qJXqm9Etv XPsg== X-Gm-Message-State: AIkVDXKJgwqRS5WiO+sO31Se8tx4pLySqmbTHvQnt53NSkvaQIRtN8YxaXyZHCcR0xV2RQ== X-Received: by 10.84.231.205 with SMTP id g13mr867969pln.118.1485916746934; Tue, 31 Jan 2017 18:39:06 -0800 (PST) Received: from ?IPv6:2601:1c0:ce01:a5b7:3450:d3e9:2ae0:c9fb? ([2601:1c0:ce01:a5b7:3450:d3e9:2ae0:c9fb]) by smtp.gmail.com with ESMTPSA id z127sm29599457pgz.29.2017.01.31.18.39.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 18:39:06 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Tue, 31 Jan 2017 18:39:05 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 02:39:08 -0000 [Show .core file creation times instead.] On 2017-Jan-31, at 6:30 PM, Mark Millard wrote: > [Just adding more accurate/precise times for the .core files.] > [The original was accidentally sent from the "wrong" E-mail account > but I've adjusted that here.] >=20 > On 2017-Jan-31, at 12:35 PM, Mark Millard = wrote: >=20 >> [More notes on what I observe on a pine64 from head -r312982 .] >>=20 >> On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: >>=20 >>> Note that on the pine64 the network interface hangs from time to = time and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". >>=20 >> I got sh crashes (multiple processes in the same time frame) from >> just trying to build pkg: >>=20 >> make[5]: stopped in = /usr/obj/portswork/usr/ports/ports-mgmt/pkg/work/pkg-1.9.4/libpkg >> *** [all-recursive] Error code 1 >>=20 >> # ls -lt /var/crash/ >> total 41764 >> -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13676.core >> -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13511.core >> -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.13499.core >> -rw------- 1 root wheel 4702208 Jan 31 03:15 sh.12095.core >> -rw-r--r-- 1 root wheel 5 Nov 3 10:18 minfree >>=20 >> In all the crashes lldb on the .core shows that the pc was no longer >> pointing a memory with code in it. It is interesting that all >> 4 sh instances died at about the same time. >=20 > More time detail (using -T): >=20 > -rw------- 1 root wheel 4702208 Jan 31 03:15:44 2017 sh.13676.core > -rw------- 1 root wheel 4702208 Jan 31 03:15:43 2017 sh.13511.core > -rw------- 1 root wheel 4702208 Jan 31 03:15:42 2017 sh.13499.core > -rw------- 1 root wheel 4702208 Jan 31 03:15:32 2017 sh.12095.core I should have used creation times: # ls -UTlt /var/crash/ . . . -rw------- 1 root wheel 4702208 Jan 31 03:15:42 2017 sh.13676.core -rw------- 1 root wheel 4702208 Jan 31 03:15:41 2017 sh.13511.core -rw------- 1 root wheel 4702208 Jan 31 03:15:41 2017 sh.13499.core -rw------- 1 root wheel 4702208 Jan 31 03:15:30 2017 sh.12095.core >> SIGILL, SIGSEGV, SIGBUS, and SIGILL (again) from the non-code >> consequences. >>=20 >> The two SIGILL's have some interesting similarities to each other. >> So I list them first below. x0-x3, x8-x9, x13, x17, x27, and cpsr >> all match in these two. x1=3Dld-elf.so.1`_rtld_tlsdesc, >> x17=3Dlibc.so.7`__free at jemalloc_jemalloc.c:2007, >> x23=3Dld-elf.so.1`symlook_global + 124 at rtld.c:3916, >> x27=3Dsh..bss + 6336. >>=20 >> The other two have the following in common: >> x10-x12, x16-x17. x17=3Dlibc.so.7`close at close.c:48 . >>=20 >> x18 =3D 0xaaaaaaaaaaaaaaab is common between one SIGILL and one not. >>=20 >> Only one does not have x27=3Dsh..bss + 6336. It instead has: >> x28=3Dsh..bss + 6336 . >>=20 >> (lldb) bt >> * thread #1: tid =3D 100142, 0x000000004044f800, name =3D 'sh', stop = reason =3D signal SIGILL >> * frame #0: 0x000000004044f800 >> (lldb) register read >> General Purpose Registers: >> x0 =3D 0x0000000000000000 >> x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc >> x2 =3D 0x0000000040a00000 >> x3 =3D 0x0000000000000002 >> x4 =3D 0x0000000000000050 >> x5 =3D 0x0000000040a4c9c0 >> x6 =3D 0x2e2e2f2e2e2f2e2e >> x7 =3D 0x6c6f6f7462696c2f >> x8 =3D 0x0000000000000001 >> x9 =3D 0x0000000000000000 >> x10 =3D 0x00000000000000df >> x11 =3D 0x000000000000002f >> x12 =3D 0x0000000040a0e690 >> x13 =3D 0x0000000000000427 >> x14 =3D 0x0000000000000001 >> x15 =3D 0x0000000000000000 >> x16 =3D 0x0000000000432340 =20 >> x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 >> x18 =3D 0x0000000000000000 >> x19 =3D 0x000000004044e330 >> x20 =3D 0x000000001c93deed >> x21 =3D 0x0000000007ab9b5c >> x22 =3D 0x00000000404ba7b0 =20 >> x23 =3D 0x000000004043c4b0 ld-elf.so.1`symlook_global + 124 at = rtld.c:3916 >> x24 =3D 0x0000ffffffffd2d0 >> x25 =3D 0x0000ffffffffd370 >> x26 =3D 0x0000ffffffffd340 >> x27 =3D 0x0000000000434000 sh..bss + 6336 >> x28 =3D 0x0000000040a4c1b0 >> fp =3D 0x0000ffff00000001 >> lr =3D 0x000000004044f800 >> sp =3D 0x0000ffffffffd2a0 >> pc =3D 0x000000004044f800 >> cpsr =3D 0x60000000 >> (lldb) disass >> -> 0x4044f800: .long 0xd550b87a ; unknown opcode >> 0x4044f804: .long 0x00000000 ; unknown opcode >> 0x4044f808: .long 0x00000001 ; unknown opcode >> 0x4044f80c: .long 0x00000000 ; unknown opcode >> 0x4044f810: .long 0x4044fc00 ; unknown opcode >> 0x4044f814: .long 0x00000000 ; unknown opcode >> 0x4044f818: .long 0x4044f410 ; unknown opcode >> 0x4044f81c: .long 0x00000000 ; unknown opcode >>=20 >> (lldb) thread list >> Process 0 stopped >> * thread #1: tid =3D 100161, 0x0000ffffffffee68, name =3D 'sh', stop = reason =3D signal SIGILL >> (lldb) register read >> General Purpose Registers: >> x0 =3D 0x0000000000000000 >> x1 =3D 0x00000000404346e8 ld-elf.so.1`_rtld_tlsdesc >> x2 =3D 0x0000000040a00000 >> x3 =3D 0x0000000000000002 >> x4 =3D 0x0000000000000017 >> x5 =3D 0x00080002a0290a00 >> x6 =3D 0x0000000000434c28 sh..bss + 9448 >> x7 =3D 0x000000000005e1cd >> x8 =3D 0x0000000000000001 >> x9 =3D 0x0000000000000000 >> x10 =3D 0x0000000000000000 >> x11 =3D 0x0000000040a5c000 >> x12 =3D 0x0000000040a0e670 >> x13 =3D 0x0000000000000427 >> x14 =3D 0x000000000000000d >> x15 =3D 0x0000000000432740 sh..bss + 0 >> x16 =3D 0x0000000000432340 =20 >> x17 =3D 0x000000004054cd00 libc.so.7`__free at = jemalloc_jemalloc.c:2007 >> x18 =3D 0xaaaaaaaaaaaaaaab >> x19 =3D 0x0000ffffffffee18 >> x20 =3D 0x0000ffffffffedb4 >> x21 =3D 0x0000ffffffffed80 >> x22 =3D 0x0000ffffffffed59 >> x23 =3D 0x0000ffffffffed47 >> x24 =3D 0x0000ffffffffed38 >> x25 =3D 0x0000ffffffffed28 >> x26 =3D 0x0000ffffffffed20 >> x27 =3D 0x0000000000434000 sh..bss + 6336 >> x28 =3D 0x0000000040a803a0 >> fp =3D 0x0000ffffffffee59 >> lr =3D 0x0000ffffffffee68 >> sp =3D 0x0000ffffffffe1a0 >> pc =3D 0x0000ffffffffee68 >> cpsr =3D 0x60000000 >> (lldb) disass >> -> 0xffffffffee68: .long 0x44504d54 ; unknown opcode >> 0xffffffffee6c: .long 0x2f3d5249 ; unknown opcode >> 0xffffffffee70: .long 0x00706d74 ; unknown opcode >> 0xffffffffee74: .long 0x4c454853 ; unknown opcode >> 0xffffffffee78: .long 0x622f3d4c ; unknown opcode >> 0xffffffffee7c: .long 0x732f6e69 ; unknown opcode >> 0xffffffffee80: .long 0x4f430068 ; unknown opcode >> 0xffffffffee84: .long 0x4749464e ; unknown opcode >>=20 >> (lldb) bt >> * thread #1: tid =3D 100088, 0x356c7265702f676e, name =3D 'sh', stop = reason =3D signal SIGBUS >> * frame #0: 0x356c7265702f676e >> (lldb) register read >> General Purpose Registers: >> x0 =3D 0x0000000000000000 >> x1 =3D 0x0000000000000000 >> x2 =3D 0x0000000040a00000 >> x3 =3D 0x0000000000000005 >> x4 =3D 0x0000000000000038 >> x5 =3D 0x0000000040a754e5 >> x6 =3D 0x584946455250442d >> x7 =3D 0x6c2f7273752f223d >> x8 =3D 0x0000000000000000 >> x9 =3D 0x0000000000000000 >> x10 =3D 0x0000000000434000 sh..bss + 6336 >> x11 =3D 0x0000000000000000 >> x12 =3D 0x0000000000434217 sh..bss + 6871 >> x13 =3D 0x0000000000434000 sh..bss + 6336 >> x14 =3D 0x0000000000432000 sh`__frame_dummy_init_array_entry >> x15 =3D 0x000000000000003d >> x16 =3D 0x00000000004322b0 =20 >> x17 =3D 0x000000004050d090 libc.so.7`close at close.c:48 >> x18 =3D 0xaaaaaaaaaaaaaaab >> x19 =3D 0x766564206f666e69 >> x20 =3D 0x7865646e692f746e >> x21 =3D 0x69727020676b702f >> x22 =3D 0x746d676d2d737472 >> x23 =3D 0x6f7020656d69746e >> x24 =3D 0x75722d7478657474 >> x25 =3D 0x65672f6c65766564 >> x26 =3D 0x206e6f7369622f6c >> x27 =3D 0x0000000040a53716 >> x28 =3D 0x0000000000434000 sh..bss + 6336 >> fp =3D 0x616c20346d2f6c65 >> lr =3D 0x356c7265702f676e >> sp =3D 0x0000ffffffffe740 >> pc =3D 0x356c7265702f676e >> cpsr =3D 0x20000000 >>=20 >> (lldb) disass >> error: core file does not contain 0x356c7265702f676e >> error: Failed to disassemble memory at 0xffffffffffffffff. >>=20 >>=20 >>=20 >> (lldb) bt >> * thread #1: tid =3D 100186, 0x0000000000000000, name =3D 'sh', stop = reason =3D signal SIGSEGV >> * frame #0: 0x0000000000000000 >> (lldb) disass >> error: core file does not contain 0x0 >> error: Failed to disassemble memory at 0xffffffffffffffff. >> (lldb) register read >> General Purpose Registers: >> x0 =3D 0x0000000000000000 >> x1 =3D 0x0000000000000000 >> x2 =3D 0x0000000000000002 >> x3 =3D 0x0000000000006c6f >> x4 =3D 0x0000000040a50bb3 >> x5 =3D 0x0000000040a499ba >> x6 =3D 0x6f7462696c2f2e2e >> x7 =3D 0x6c6f6f7462696c2f >> x8 =3D 0x0000000000000000 >> x9 =3D 0x0000000000000000 >> x10 =3D 0x0000000000434000 sh..bss + 6336 >> x11 =3D 0x0000000000000000 >> x12 =3D 0x0000000040a499f8 >> x13 =3D 0x0000000000434000 sh..bss + 6336 >> x14 =3D 0x0000000000000001 >> x15 =3D 0x0000000000000000 >> x16 =3D 0x00000000004322b0 =20 >> x17 =3D 0x000000004050d090 libc.so.7`close at close.c:48 >> x18 =3D 0x0000000000000000 >> x19 =3D 0x0000000000000065 >> x20 =3D 0x0000000000000065 >> x21 =3D 0x00000000004168f0 sh`readtoken1 + 5212 at = parser.c:1602 >> x22 =3D 0x0000ffffffffda90 >> x23 =3D 0x0000000040a498c0 >> x24 =3D 0x000000000000000a >> x25 =3D 0x0000000000000000 >> x26 =3D 0x0000000000000000 >> x27 =3D 0x0000000040a49258 >> x28 =3D 0x0000000000434000 sh..bss + 6336 >> fp =3D 0x0000ffffffffda08 >> lr =3D 0x0000000000000000 >> sp =3D 0x0000ffffffffd970 >> pc =3D 0x0000000000000000 >> cpsr =3D 0x20000000 >>=20 >>=20 >> Looks to me like something major is wrong. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-30, at 11:57 PM, Mark Millard = wrote: > I updated to head -r312982 on the pine64 that I have access to: >=20 > # uname -apKU > FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r312982M arm64 = aarch64 1200020 1200020 >=20 > after several months of not using the pine64. > ( -mcpu=3Dcortex-a53 used for buildworld buildkernel; > non-debug variant of GENERIC [GENERIC included > then overridden]; usb SSD root file system) >=20 > I find that any time some of the cores are busy I get thousands > of the gic0 spurious interrupt messages in fairly sort order. > (This is not new: it is unchanged.) >=20 > For example during either of: >=20 > openssl speed >=20 > or: >=20 > cp /dev/zero /dev/null > (similarly for copying actual files around, > local or nfs involved) >=20 > Once the cores are no longer busy the gic0 messages stop. >=20 > The "on CPU" varies. The "last irq: " varies. > (But 27 is the most common by far.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jan-28, at 2:17 PM, Tom Vijlbrief = wrote: Note that on the pine64 the network interface hangs from time to time = and I get a core dump with very low frequency from long running = processes, eg the shell that invokes "make world". Note that I had = similar issues on the ODroid-C2. Currently rebuilding world without MALLOC_PRODUCTION. The arm64 port is getting close to working 100%, just a last few = glitches. Op 22:03 ZA 28 Jan 2017 schreef Mark Millard : [About: "gic0: Spurious interrupt detected" on armv6 as well.] On 2017-Jan-28, at 6:43 AM, Tom Vijlbrief = wrote: > Did a build/install world/kernel with r312916 and = MALLOC_PRODUCTION=3DYES on > a pine64, removed /etc/malloc.conf, rebooted >=20 > and I am now rebuilding the python2 port without problems so far = (except > the "gic0: Spurious interrupt detected" messages which reappeared = shortly > after my previous post) While very rare, I have seen the gic0 notices on armv6 (e.g., a bpim3) during large builds (with -j 4). Recently I got a: gic0: Spurious interrupt detected: last irq: 29 on CPU1 on: # uname -apKU FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312726M: Tue Jan 24 = 20:57:48 PST 2017 = markmi@FreeBSDx64:/usr/obj/bpim3_clang/arm.armv6/usr/src/sys/BPIM3-NODBG = arm armv6 1200020 1200020 while building devel/gcc6 (via a full bootstrap) via -j 4 . This is from a non-debug buildworld buildkernel context and has = MALLOC_PRODUCTION=3D in /etc/make.conf . No /etc/malloc.conf present. I do use = -mcpu=3Dcortex-a7 . Details if you care: # more /usr/src/sys/arm/conf/BPIM3-NODBG # # BPIM3 -- Custom configuration for the Banana Pi M3 # include "GENERIC" ident BPIM3-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 It was a from cross build for buildworld buildkernel : (I've not checked on lldb builds linking recently.) # more ~/src.configs/src.conf.bpim3-clang-bootstrap.amd64-host TO_TYPE=3Darmv6 # KERNCONF=3DBPIM3-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv6(/v7) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a7 XCXXFLAGS+=3D -mcpu=3Dcortex-a7 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. Used for buildworld buildkernel : # more ~/src.configs/make.conf #MALLOC_PRODUCTION=3D #NO_WERROR=3D #WERROR=3D CFLAGS.gcc+=3D -v Used for port builds: # more /etc/make.conf WANT_QT_VERBOSE_CONFIGURE=3D1 # DEFAULT_VERSIONS+=3Dperl5=3D5.24 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D MALLOC_PRODUCTION=3D # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/libexec/rtld-elf/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c M /usr/src/sys/ddb/db_script.c M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/ofw/ofw_machdep.c The M's are generally tied to powerpc64 and powerpc explorations. I tend to use the same source for all the TARGET_ARCH's that I build. =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Feb 1 19:00:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1E52CCBCCE for ; Wed, 1 Feb 2017 19:00:06 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5DE1ECE for ; Wed, 1 Feb 2017 19:00:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 715A8602FA for ; Wed, 1 Feb 2017 12:52:32 -0600 (CST) To: freebsd-arm@freebsd.org From: Karl Denninger Subject: New degeneration RPI2 Message-ID: Date: Wed, 1 Feb 2017 12:52:14 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050505000702070105090104" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:00:06 -0000 This is a cryptographically signed message in MIME format. --------------ms050505000702070105090104 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10= Load Average ||||| /0% /10 /20 /30 /40 /50 /60 /70 /80 /90 /10= 0 root idle XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX root idle XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX root idle XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX root idle XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX There is nothing running on the box. This is new; it did not do this (show a load average of 1.0 even when entirely idle) on a relatively-recent (Decemberish) kernel.=20 FreeBSD 11.0-STABLE #0 r313043M: Wed Feb 1 10:38:41 CST 2017 =20 karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/s= rc/sys/RPI2 It does, however, on this build. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050505000702070105090104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDExODUyMTRaME8GCSqGSIb3DQEJBDFCBEBsl9Er IFBTLBhnhel0k/6X1qTQ4V+LMOvOAgu27f8s0fmwCjm1uNi5Gx3IWH7eLbinPTlpATWg1tWe nmNhae9SMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAt+c6HMPZhyuc RpRjsk9S8J08NfKu+cRIJo52WqS2ZWudIiPFhXE8lPxxFR+OjWOr5lZsTIW8n+hrt4fLfwSe 77tvl7Zd2NrcSTz1cgeI+7z1otwNhyvIcj4zK80+i4+9jHxRiyAT32OvhBahw9mTULVJUoy6 SLfm+QSiBXSpmB7eAMOqLgAAK9LD8HsNM4Bq2C4qqFJvnQmao4+NNszQ9EjMeWp64fPXQ8xy 3OA9rhDwckUIDRc9zHQpBBfVa0lZdOD7NRZ+KqSsXowUW6c5Vso8yA2MJdoD9mggg0UZqhpq LDdPlDckJvAIggryKHbvhJlo4TjvDlgtz0+MyzZpwprASZFPhGCvtYGSgM3KyPW9vz2PmQZ3 4FRKNK27AdmfMemWKQ/uQztp1HYOoBBE6mBHWSwcQKWI6SdZtNohNMRza0PD3qQE96yNz5BQ CT+1f9rdEi0J57ovO2BRZqwi16REWfQJxL8UJKSAnOb+nwISrXrLrbc1YXo6KlHlx3zQL5Da yTxnhEqXpmYjHODPfDHz3UheQ6C96EqPKxYv/wifOlgeEVbWMIxg+/W/9THv10N8yjR43W38 rxAQSQ8nlFGb2RA6oJoM8H6eufN1bIudlby95fBFNtT2DQ41nsnjYeuPaU0CvmRYbo1VAyQf gwPlfn/KOQFMF2AEUDw4mbYAAAAAAAA= --------------ms050505000702070105090104-- From owner-freebsd-arm@freebsd.org Thu Feb 2 03:07:41 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEA54CCC8AE for ; Thu, 2 Feb 2017 03:07:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-73.reflexion.net [208.70.210.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4EAD22 for ; Thu, 2 Feb 2017 03:07:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4135 invoked from network); 2 Feb 2017 03:07:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Feb 2017 03:07:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 01 Feb 2017 22:07:34 -0500 (EST) Received: (qmail 11496 invoked from network); 2 Feb 2017 03:07:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Feb 2017 03:07:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C9E95EC909E; Wed, 1 Feb 2017 19:07:33 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Wed, 1 Feb 2017 19:07:33 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:07:41 -0000 I temporarily modified the Spurious-interrupt-detected notice to also = report irq and sc->nirqs : . . . #define gic_c_read_4(_sc, _reg) \ bus_space_read_4((_sc)->gic_c_bst, (_sc)->gic_c_bsh, (_reg)) . . . int arm_gic_intr(void *arg) { struct arm_gic_softc *sc =3D arg; struct gic_irqsrc *gi; uint32_t irq_active_reg, irq; struct trapframe *tf; irq_active_reg =3D gic_c_read_4(sc, GICC_IAR); irq =3D irq_active_reg & 0x3FF; =20 /* . . . */ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS device_printf(sc->gic_dev, "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n", irq, sc->nirqs, sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); #endif return (FILTER_HANDLED); } . . . The result was irq=3D=3D1023 and sc->nirqs=3D=3D224 in every message that I've seen so far. 1023=3D=3D0x3FF . Looking around I found in: = http://www.cl.cam.ac.uk/research/srg/han/ACS-P35/zynq/arm_gic_architecture= _specification.pdf the following on various reasons why 1023 would show up (quoting): =E2=80=A2 A processor reads the GICC_IAR and obtains the = interrupt ID 1023, indicating a spurious interrupt. The processor can = return from its interrupt service routine without writing to its = GICC_EOIR. The spurious interrupt ID indicates that the original interrupt is no = longer pending, typically because another target processor is handling = it. . . . The GIC architecture reserves interrupt ID numbers 1020-1023 for special = purposes. In a GICv1 implementation that does not implement the GIC = Security Extensions, the only one of these used is ID 1023. This value = is returned to a processor, in response to an interrupt acknowledge, if = there is no pending interrupt with sufficient priority for it to be = signaled to the processor. It is described as a response to a spurious = interrupt. Note A race condition can cause a spurious interrupt. For example, a spurious = interrupt can occur if a processor writes a 1 to a field in an = GICD_ICENABLERn that corresponds to a pending interrupt after the CPU = interface has signaled the interrupt to the processor and the processor = has recognized the interrupt, but before the processor has read from the = GICC_IAR. . . . =E2=80=A2 If a read of the GICC_IAR does not match the security = of the interrupt, the GICC_IAR read does not acknowledge any interrupt = and returns the value: =E2=80=A2 1022 for a Secure read when the highest = priority interrupt is Non-secure =E2=80=A2 1023 for a Non-secure read when the highest = priority interrupt is Secure. . . . A read of the GICC_IAR returns the interrupt ID of the highest priority = pending interrupt for the CPU interface. The read returns a spurious = interrupt ID of 1023 if any of the following apply: =E2=80=A2 forwarding of interrupts by the Distributor to the CPU = interface is disabled =E2=80=A2 signaling of interrupts by the CPU interface to the = connected processor is disabled =E2=80=A2 no pending interrupt on the CPU interface has = sufficient priority for the interface to signal it to the processor. =E2=80=A2 The following sequence of events is an example of when = the GIC returns an interrupt ID of 1023, and shows how reads of the = GICC_IAR can be timing critical: 1. A peripheral asserts a level-sensitive interrupt. 2. The interrupt has sufficient priority and therefore the GIC signals = it to a targeted processor. 3. The peripheral deasserts the interrupt. Because there is no other = pending interrupt of sufficient priority, the GIC deasserts the = interrupt request to the processor. 4. Before it has recognized the deassertion of the interrupt request = from stage 3, the targeted processor reads the GICC_IAR. Because there = is no interrupt with sufficient priority to signal to the processor, the = GIC returns the spurious ID value of 1023. The determination of the returned interrupt ID is more complex if the = GIC supports interrupt grouping . . . Interrupt signaling of the required interrupt group by CPU interface = disabled =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Feb 2 03:12:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75D4BCCCB5A for ; Thu, 2 Feb 2017 03:12:24 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C4DE104E for ; Thu, 2 Feb 2017 03:12:23 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x236.google.com with SMTP id x49so6909290qtc.2 for ; Wed, 01 Feb 2017 19:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=DFP4isgyk8pkhTSUO9Vsc0bo1Roz0PZgxF44Xei7QLM=; b=OXPEEXvQRidD63e+YTc87S+KK3RzoFlK7f9xSYVTkr2UgiWTLZ95aTzHbYF4Cu4LEP c1+gLvHUgb8uwvzKagkp7VWYhVcperQ1Sh0fkoMsdxKBaG8HuGGJpa6NW30CHflwE0Cy mRZFfZK5MNfav6N1zrqNmQINyHxeHOSyuGxEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=DFP4isgyk8pkhTSUO9Vsc0bo1Roz0PZgxF44Xei7QLM=; b=F4aBw7SOWWGFc7pt10/Hpkm9SgP9fMvdSwctRLEsX8zJAoeNS7ZRFL8+BfaoPBo0/R IURAm4HGGN81i7TNLFlIRMxhZPdcpvDE0IPZSpZof5hoE9+x2vTH+5NtQybjBHusU42F 6RO/9wpRdULrFcUJNww5xDfE5PpI4N4LWoyznziQecT26K2hnBdT1sewTMvMqh3tWVnI NqU7lg4tCP7dQtJRy2LJP/H5EwxrTbL1e812Gy2/evJ6R4nJgsy4X4gyakhtZnjwd5db GcX8+7Yvk+taAjsm6vZKXv3WPD4GJ0nCDapSOSGfg2rdeoEhIiLyh3JWNUizveI2TnXX b2AQ== X-Gm-Message-State: AIkVDXK8qn7Hp2Kx3NjpzuxvpvnDQnbhgl/kbRgTDdQLcERXv/Y2KqXXFFoQmlhkblAKoQ== X-Received: by 10.237.59.203 with SMTP id s11mr6179841qte.46.1486005143086; Wed, 01 Feb 2017 19:12:23 -0800 (PST) Received: from [192.168.0.11] ([187.60.94.34]) by smtp.googlemail.com with ESMTPSA id r131sm20394196qke.14.2017.02.01.19.12.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 19:12:22 -0800 (PST) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: SMP support on Raspberry PI 3 Message-ID: Date: Thu, 2 Feb 2017 00:12:18 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:12:24 -0000 Dears I did a build of 12 r312852 to my Raspberry PI 3 with SMP enabled. But, when the board is booting I get this message intermittent cpufreq0: rejecting change, SMP not started yet SMP is supposed to work? []'s -Otacilio From owner-freebsd-arm@freebsd.org Thu Feb 2 08:37:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 261BDCCCE33 for ; Thu, 2 Feb 2017 08:37:59 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA0CA1BE1 for ; Thu, 2 Feb 2017 08:37:58 +0000 (UTC) (envelope-from markmigm@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id 189so3733515pfu.3 for ; Thu, 02 Feb 2017 00:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=sTFCr8uxPOlnouhJRRxnmSKGUd0nm6UOvCQsEEilJTk=; b=FTBICr16EzgiDZRmG/OEixk2Hzcasx1ekFZUqSfFV9VWNd3FfnkHNxqjB0jX1X9TeM A+NZEqd8ztAPFg130J9pFP0dpHONqew6RV5aWVCYHo5gydi3lmvdeZGCRPFztMFiQxox x1sZgsIkeNpMrzL8INs4+Gw42nu/FoUUZ4IrTQl5w7BxElIJ3uaLHUBKRBIsNMlg0ZT5 qiDtrPT6hwIemiPFvfr/D4Qehcuxgnf5ibVrIpc7ZDUlSTCZqAWrRf88/ia8w3xWbiv6 1XGmqx5aFUQM7F3TDrPMahohuUVR6jo+BU45NxnoZHlDywCUwTjmtauCZ4vZMkG4w9jI zRcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=sTFCr8uxPOlnouhJRRxnmSKGUd0nm6UOvCQsEEilJTk=; b=LH0DPGyahsJ9ZNdz8cw7GFdIHv365hvWVRr95PPCDxzpz65VKuTrGm4ruxVL6S+IvD 3uqcht0P1lRGnU+qfRxurYQV9X9EU6r+muc8HUXc9zu28qXlhF1wY3NKy/QX1QOtgG+t W7qQAymXZ3gVlxJ4LEXofMBO/5rnQHUwMTahJGvUVEu34zKthSnNu+FmIZhOZewjnVc9 GiX6PRWYGJ8uBvu9sDFEiF+MkCAjRzjeBuqYCoxBiLx9oNY+CsbM6uSeNjox0QhjYvQe H5JvevzlFF7GUC7CYGaP0tT+I2peH519timd+CObga/AcX5bCL9PteZfduWEMcwHk0Fe NpBQ== X-Gm-Message-State: AIkVDXJpEPJKjsHdvQpWRAlZKYVeCEosQvl5JYbaGmEjKfvlQpyXRgCZmRRQVg2Nmem2/Q== X-Received: by 10.98.192.72 with SMTP id x69mr9106511pff.129.1486024678338; Thu, 02 Feb 2017 00:37:58 -0800 (PST) Received: from ?IPv6:2601:1c0:ce01:a5b7:6505:c813:e6a8:9eda? ([2601:1c0:ce01:a5b7:6505:c813:e6a8:9eda]) by smtp.gmail.com with ESMTPSA id t87sm55967688pfe.59.2017.02.02.00.37.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 00:37:57 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Arm64 stack issues (was Re: FreeBSD status for/on ODroid-C2?) Date: Thu, 2 Feb 2017 00:37:56 -0800 References: <20170124191357.0ec0abfd@zapp> <20170128010138.iublazyrhhqycn37@mutt-hardenedbsd> <20170128010223.tjivldnh7pyenbg6@mutt-hardenedbsd> <009857E3-35BB-4DE4-B3BB-5EC5DDBB5B06@dsl-only.net> <890B7D8A-27FF-41AC-8291-1858393EC7B1@gmail.com> <54642E5C-D5D6-45B7-BB74-2407CFB351C2@dsl-only.net> To: Tom Vijlbrief , freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 08:37:59 -0000 I'm out of my element here but I will note one difference between what I read in the likes of: = http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/DEN0024A_v8_arch= itecture_PG.pdf and what I see in /usr/src/sys/arm/arm/gic.c 's arm_gic_intr . The written description says (quoting 10.6 The Generic Interrupt Controller and 10.6.3 Interrupt Handling): > Interrupts can either be edge-triggered (considered to be asserted = when the GIC detects a rising edge on the relevant input, and to remain = asserted until cleared) or level-sensitive (considered to be asserted = only when the relevant input to the GIC is HIGH). >=20 > . . . >=20 > The priority and list of cores to which an interrupt can be delivered = to are all configured in the Distributor. An interrupt asserted to the = Distributor by a peripheral is in the Pending state (or Active and = Pending if it was already Active). The Distributor determines the = highest priority pending interrupt that can be delivered to a core and = forwards that to the CPU interface of the core. At the CPU interface, = the interrupt is in turn signaled to the core, at which point the core = takes the FIQ or IRQ exception. >=20 > The core executes the exception handler in response. The handler must = query the interrupt ID from a CPU interface register and begin servicing = the interrupt source. When finished, the handler must write to a CPU = interface register to report the end of processing. >=20 > =E2=80=A2 For a given interrupt the typical sequence is: >=20 > =E2=80=A2 Inactive -> Pending > When the interrupt is asserted by the peripheral. >=20 > =E2=80=A2 Pending -> Active > When the handler acknowledges the interrupt. >=20 > =E2=80=A2 Active -> Inactive > When the handle[r] has finished dealing with the interrupt. >=20 > . . . >=20 > The top-level interrupt handler reads the Interrupt Acknowledge = Register from the CPU Interface block to obtain the interrupt ID. >=20 > As well as returning the interrupt ID, the read causes the interrupt = to be marked as active in the Distributor. Once the interrupt ID is = known (identifying the interrupt source), the top-level handler can now = dispatch a device-specific handler to service the interrupt. >=20 > When the device-specific handler finishes execution, the top-level = handler writes the same interrupt ID to the End of Interrupt (EoI) = register in the CPU Interface block, indicating the end of interrupt = processing. So that wording indicates that the write to GICC_EOIR should be after the dispatched activity (after "servicing"), not before. I did not find anything indicating that edge-triggered vs. level triggered would be different for this, for example. (But being unfamiliar I could have missed something.) In two cases below the code has the write to the GICC_EOIR before the dispatch (so before the servicing activity), possibly allowing another interrupt during or even before the dispatched activity (say if the state for the irq is active-and-pending at the time of the GICC_EOIR write or if there is a lower priority interrupt pending at that time): > if (irq <=3D GIC_LAST_SGI) { > #ifdef SMP > /* Call EOI for all IPI before dispatch. */ > gic_c_write_4(sc, GICC_EOIR, irq_active_reg); > intr_ipi_dispatch(sgi_to_ipi[gi->gi_irq], tf); > goto next_irq; > #else > . . . > #endif > } >=20 > . . . > if ((gi->gi_flags & GI_FLAG_EARLY_EOI) =3D=3D = GI_FLAG_EARLY_EOI) > gic_c_write_4(sc, GICC_EOIR, irq_active_reg); >=20 > if (intr_isrc_dispatch(&gi->gi_isrc, tf) !=3D 0) { > gic_irq_mask(sc, irq); > if ((gi->gi_flags & GI_FLAG_EARLY_EOI) !=3D = GI_FLAG_EARLY_EOI) > gic_c_write_4(sc, GICC_EOIR, irq_active_reg); > device_printf(sc->gic_dev, "Stray irq %u disabled\n", = irq); > } >=20 > next_irq: . . . Note: GI_FLAG_EARLY_EOI was set for edge triggered: > /* For MSI/MSI-X we should have already configured these */ > if ((gi->gi_flags & GI_FLAG_MSI) =3D=3D 0) { > if (pol =3D=3D INTR_POLARITY_CONFORM) > pol =3D INTR_POLARITY_LOW; /* just pick = some */ > if (trig =3D=3D INTR_TRIGGER_CONFORM) > trig =3D INTR_TRIGGER_EDGE; /* just pick = some */ >=20 > gi->gi_pol =3D pol; > gi->gi_trig =3D trig; >=20 > /* Edge triggered interrupts need an early EOI sent */ > if (gi->gi_pol =3D=3D INTR_TRIGGER_EDGE) > gi->gi_flags |=3D GI_FLAG_EARLY_EOI; > } =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Feb-1, at 7:07 PM, Mark Millard wrote: > I temporarily modified the Spurious-interrupt-detected notice to also = report > irq and sc->nirqs : >=20 >=20 > . . . > #define gic_c_read_4(_sc, _reg) \ > bus_space_read_4((_sc)->gic_c_bst, (_sc)->gic_c_bsh, (_reg)) >=20 > . . . > int > arm_gic_intr(void *arg) > { > struct arm_gic_softc *sc =3D arg; > struct gic_irqsrc *gi; > uint32_t irq_active_reg, irq; > struct trapframe *tf; >=20 > irq_active_reg =3D gic_c_read_4(sc, GICC_IAR); > irq =3D irq_active_reg & 0x3FF; >=20 > /* > . . . > */ >=20 > if (irq >=3D sc->nirqs) { > #ifdef GIC_DEBUG_SPURIOUS > device_printf(sc->gic_dev, > "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n", > irq, sc->nirqs, > sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); > #endif > return (FILTER_HANDLED); > } > . . . >=20 >=20 > The result was irq=3D=3D1023 and sc->nirqs=3D=3D224 in every message > that I've seen so far. 1023=3D=3D0x3FF . >=20 > Looking around I found in: >=20 > = http://www.cl.cam.ac.uk/research/srg/han/ACS-P35/zynq/arm_gic_architecture= _specification.pdf >=20 > the following on various reasons why 1023 would show up (quoting): >=20 >=20 >=20 > =E2=80=A2 A processor reads the GICC_IAR and obtains the = interrupt ID 1023, indicating a spurious interrupt. The processor can = return from its interrupt service routine without writing to its = GICC_EOIR. >=20 > The spurious interrupt ID indicates that the original interrupt is no = longer pending, typically because another target processor is handling = it. >=20 > . . . >=20 > The GIC architecture reserves interrupt ID numbers 1020-1023 for = special purposes. In a GICv1 implementation that does not implement the = GIC Security Extensions, the only one of these used is ID 1023. This = value is returned to a processor, in response to an interrupt = acknowledge, if there is no pending interrupt with sufficient priority = for it to be signaled to the processor. It is described as a response to = a spurious interrupt. >=20 > Note >=20 > A race condition can cause a spurious interrupt. For example, a = spurious interrupt can occur if a processor writes a 1 to a field in an = GICD_ICENABLERn that corresponds to a pending interrupt after the CPU = interface has signaled the interrupt to the processor and the processor = has recognized the interrupt, but before the processor has read from the = GICC_IAR. >=20 > . . . >=20 > =E2=80=A2 If a read of the GICC_IAR does not match the security = of the interrupt, the GICC_IAR read does not acknowledge any interrupt = and returns the value: >=20 > =E2=80=A2 1022 for a Secure read when the highest = priority interrupt is Non-secure >=20 > =E2=80=A2 1023 for a Non-secure read when the highest = priority interrupt is Secure. > . . . >=20 > A read of the GICC_IAR returns the interrupt ID of the highest = priority pending interrupt for the CPU interface. The read returns a = spurious interrupt ID of 1023 if any of the following apply: >=20 > =E2=80=A2 forwarding of interrupts by the Distributor to the CPU = interface is disabled >=20 > =E2=80=A2 signaling of interrupts by the CPU interface to the = connected processor is disabled >=20 > =E2=80=A2 no pending interrupt on the CPU interface has = sufficient priority for the interface to signal it to the processor. >=20 >=20 > =E2=80=A2 The following sequence of events is an example of when = the GIC returns an interrupt ID of 1023, and shows how reads of the = GICC_IAR can be timing critical: >=20 > 1. A peripheral asserts a level-sensitive interrupt. >=20 > 2. The interrupt has sufficient priority and therefore the GIC signals = it to a targeted processor. >=20 > 3. The peripheral deasserts the interrupt. Because there is no other = pending interrupt of sufficient priority, the GIC deasserts the = interrupt request to the processor. >=20 > 4. Before it has recognized the deassertion of the interrupt request = from stage 3, the targeted processor reads the GICC_IAR. Because there = is no interrupt with sufficient priority to signal to the processor, the = GIC returns the spurious ID value of 1023. >=20 >=20 > The determination of the returned interrupt ID is more complex if the = GIC supports interrupt grouping >=20 > . . . >=20 >=20 > Interrupt signaling of the required interrupt group by CPU interface = disabled >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Feb 2 12:05:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59DFACCD49E for ; Thu, 2 Feb 2017 12:05:34 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E72181185 for ; Thu, 2 Feb 2017 12:05:33 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486037131; l=1943; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=9HGcuLc5Su9vrqAqEAm+DGetGTg/zVhHLn+D/pcC6mo=; b=oKdKue4l28i94g3IiqlYUkn3coObomk/3agRGGsFtMGNvYBu0PzOq+IDeDBGKy0vsj O0SVmnETBjCBiFjhccURTPth/7rnJ8/Dnv8ZggMTxSVnMVCzwHRighMN5tNVqe21xLkm W8no4zCCIvl/ou4/6WePibWfoeTNnsf1OVf4Y= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99HgKKA= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b584.virtua.com.br [187.2.181.132]) by smtp.strato.de (RZmta 39.12 DYNA|AUTH) with ESMTPSA id j0a57ft12C5UXd3 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 2 Feb 2017 13:05:30 +0100 (CET) Received: from [192.168.222.9] (unknown [192.168.222.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 5D5687506E74 for ; Thu, 2 Feb 2017 10:05:27 -0200 (BRST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: lldb on BeagleBone Black From: "Dr. Rolf Jansen" In-Reply-To: <82b64b54-d9cc-8cb6-6b6d-8817f1fbb4cc@freebsd.org> Date: Thu, 2 Feb 2017 10:05:26 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C37E5FD-E574-40BB-8A61-A3857609EDE1@obsigna.com> References: <3DA2368D-AE7B-4D69-A634-2861D2EFA9AE@obsigna.com> <8FDE5FCC-9BA8-4601-A32E-04FBAB5FFBEA@obsigna.com> <0ee18ae6-7588-97c9-bc04-3ad83b0c33b3@freebsd.org> <34EB351A-3BA9-4D38-AF1C-96B065564C42@obsigna.com> <06672183-F0A6-47C9-AC53-091515CBEBC3@obsigna.com> <82b64b54-d9cc-8cb6-6b6d-8817f1fbb4cc@freebsd.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:05:34 -0000 Am 24.01.2017 um 01:43 schrieb Michal Meloun: > On 23.01.2017 18:36, Ed Maste wrote: >> On 16 January 2017 at 09:20, Dr. Rolf Jansen wrote: >>>=20 >>> Building and installation of devel/llvm37 from the ports went well = without problems, however, lldb37 is only of minor usefulness since = stepping-into/over lines of code does not work. I can set breakpoint, = and execution stops fine on breakpoints, however, when I hit 'n' or 's', = the program simply continues execution in a normal fashion until end. >>=20 >> Yes. Single-stepping on ARM requires special support in the debugger, >> which does not yet exist in LLDB for FreeBSD. The good news is that >> there is a patch in review to add this support. I'm hoping to review, >> test and commit it this week to the upstream LLDB repository, and = I'll >> see about merging it into the LLDB in the FreeBSD base system from >> there. >>=20 >> -Ed >=20 > There are more problems with LLDB. >=20 > 1) Full LLVM suite, newer that 37, cannot be linked. The resultant = size > of shared library is bigger that 32MB, and our very old linker doesn't > implements big jump/call stubs. > For now, cmake .. -DLLVM_TARGETS_TO_BUILD=3D"ARM" works but I think = that > this is also very close to 32MB limit. >=20 >=20 > 2) LLDB uses UDF instruction as breakpoint, but FreeBSD kernel expects > BKPT (see g_arm_breakpoint_opcode in ProcessFreeBSD.cpp). That's why = you > get invalid opcode for single step (and/or breakpoint). My quick = attempt > to replace this with right BKPT opcode also failed, and I think that > this code also have problem with endianes. Unfortunately, I have no = free > time for this Finally, a build from SVN-trunk of LLDB went through on my BeagleBone = Black, and with that one single stepping works. I utilized ccmake in = order to configure -Os for the Release build. Best regards Rolf =20 Rolf= From owner-freebsd-arm@freebsd.org Thu Feb 2 15:36:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D05ACCD2F1 for ; Thu, 2 Feb 2017 15:36:39 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8F8F1E9A for ; Thu, 2 Feb 2017 15:36:37 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id D179437615D1 for ; Thu, 2 Feb 2017 16:36:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id C5723376127D for ; Thu, 2 Feb 2017 16:36:21 +0100 (CET) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uBGx9tZ4AFyo for ; Thu, 2 Feb 2017 16:36:21 +0100 (CET) Received: from pc-alex.localnet (fwlabo.stormshield.eu [10.2.0.1]) by work.stormshield.eu (Postfix) with ESMTP id A9DFB376107C for ; Thu, 2 Feb 2017 16:36:21 +0100 (CET) From: Alexandre Martins To: Freebsd arm Subject: Counter API Date: Thu, 02 Feb 2017 16:38:08 +0100 Message-ID: <2478341.4YUvIvO0Dr@pc-alex> Organization: STORMSHIELD User-Agent: KMail/4.14.10 (FreeBSD/10.3-RELEASE-p7; KDE/4.14.10; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1758152.g1Y9NJ3CVh"; micalg="sha256"; protocol="application/pkcs7-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:36:39 -0000 --nextPart1758152.g1Y9NJ3CVh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi all, Our companie is curently tracking performance issue with our ARM produc= t. We have seen that counter API was migrated from intrinsic to atomic. https://svnweb.freebsd.org/base?view=3Drevision&revision=3D269406 But there is still the calls to critical_enter/leave in the macro=20 counter_enter/leave. Is that needed ? Can we remove that ? Best regards =2D-=20 Alexandre Martins STORMSHIELD --nextPart1758152.g1Y9NJ3CVh Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCOUw ggSGMIICbqADAgECAgUA28zw7TANBgkqhkiG9w0BAQsFADBIMQswCQYDVQQGEwJGUjEUMBIGA1UE CgwLU1RPUk1TSElFTEQxIzAhBgNVBAMMGlN0b3Jtc2hpZWxkIFJvb3QgQXV0aG9yaXR5MB4XDTE0 MDkwNDE1MDcxMFoXDTI0MDkwMTE1MDcxMFowSTELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JN U0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVsZCBVc2VycyBBdXRob3JpdHkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDChwWgC/6VWKL7jgWI3eA2sVvRdOwuHcXsRAAXVWdlMC0ygg7u 45E78GhAnpdl8QbIu7x/Q2zOq6KttspwDEIjkoMLTZngLLlGjYJZPfuSoC6hl9R7vRd5f8Fhu3v0 xQ/7vzKYz4C836IGCrk31gmrPO0H0fxkyxCMfhoTTzue3oXW1IsmQwCrOPOu2Y82QANDhbifWLjI WJetnj58YRKR82KBs3Flbqxtp0mi9+IswMvCCRSoT+ORB73Cl6URt7Qm7BcD+qnkJ9uwlUC94dIl T2hX4ybY/w/ssA17Ew418fgyRCWQXzgjZgZ/XUcw2WP9dIggA7Pg+c/xeROJH1zvAgMBAAGjdjB0 MB0GA1UdDgQWBBShbYRsooCFBXx8dXWANMETW5fXgTAfBgNVHSMEGDAWgBS4Qqn6Z0Twf9NhjOyl x1CutL3sozAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjARBglghkgBhvhCAQEEBAMC AQYwDQYJKoZIhvcNAQELBQADggIBAE6C9zkt2J6dPm2KLbzRS6rBIYZNFi0X59g3ekQ2Sc4UWsq+ B3L86j5xnQSRnIM/DKV1+Q2UHbU/qsh4cto2fwTV6V+aJ07Vu/bJE1rAN4AI4V26ytf7VoBcBjVZ Jq8pHOMp/G2eQH7F1xqzml68DpKku66aUalkcC9IM82m7AW3YAyvDoYEAchv4qyL8qhVLLp6LNru 8ZOhMELhZLWl4ulw/SFDMhcBS6I4wC6icj71MLGSrr61vMktMdwQ+CGFQ5z5JbaxM61VgzKay8+g lw+xTbpnitrDfhkzHs2fdwOOur3vtNnNsrdBWiYPseJ2k4VGD7ov5kITQZckmZyF/V+Ir//agJQG VuwhDZCXgXOvrje+FLYp7tQ9pgSvLbluh1A+ywfyHnFI4n6tZy9SD3MIDgWR4KwFLM1Qmt3NQb32 tkq9Vm0jUcQXFfbnWKLA9krw3m8NmCqhL5PzpfOegYOc0QJWfMQamxeWxXMLk6uKisS//+VqfpCa 5Jx53t+9DmoN1+ob4jOprPaX6tfBBr5djah2yzPGjHEB52VgWXxIF9lCM2z7Qw+zFb2PIdNeSjIk NEFg/1orKAAa5gQXAQynN2J7E+aLf2XLhHcS0v+9yoisPEw9+Tb5F1uQh+gzYD5JUUYcYWncnX8g P8k6X+F5mQ/81IoNL/IejxJgy/LoMIIEVzCCAz+gAwIBAgIFAIUoy7swDQYJKoZIhvcNAQELBQAw STELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVs ZCBVc2VycyBBdXRob3JpdHkwHhcNMTYwOTAxMTUxMTA4WhcNMTcwOTAxMTUxMTA4WjBwMQswCQYD VQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElFTEQxGjAYBgNVBAMMEUFsZXhhbmRyZSBNQVJUSU5T MS8wLQYJKoZIhvcNAQkBFiBhbGV4YW5kcmUubWFydGluc0BzdG9ybXNoaWVsZC5ldTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMN+CnvE13jKEwJ+OyMzwBpC02dY+LpD5luJwnJTVnV2 9aUjEMI+xGFMMHd9kSIVInbk4WDe1ELOKerg0dzgnkRiOHECSGum1UhcZABxQgY2cmSffNQ6JVro 52UaBlt3aTOk3imYJCHUIGgOWMvOtRc8BxyBHdi15FZPj/F9I+AKufRFsBXUakplFIAPEwy3m2eR a/eCMLqGJUyK7YmsAlEnYn2mA38zIoqtKvL6KPHtrV8fw1SRLQ13+j9nu1LlCaqhmLtILFxhV0/9 uDTvx5cKtZ8Xj1nPM6NUUrso9qlXwm4On6Y34pVTtnYGMQRuljil3Hiz84RJjPDJYRGwbgkCAwEA AaOCAR0wggEZMB0GA1UdDgQWBBTmRLIwSfhNwbdfV13xt0G0JHYjPDAfBgNVHSMEGDAWgBShbYRs ooCFBXx8dXWANMETW5fXgTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwID6DARBglghkgBhvhCAQEE BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHBzOi8vcGtpLm5ldGFzcS5jb20vYXV0aC9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0LmNybDAR BgNVHSAECjAIMAYGBFUdIAAwKwYDVR0RBCQwIoEgYWxleGFuZHJlLm1hcnRpbnNAc3Rvcm1zaGll bGQuZXUwDQYJKoZIhvcNAQELBQADggEBALT9NWiAaE6nDev34vShhsyb9lWBOQfCnAMyKwtFy/cU uIoHsxyOanIIQHz0ZtB76GCHDo7RStMyp6RYIefIsxABLhSr4hHapJka9g/X/nxexyr0xyT3IpYQ dmyMSHRT18Z/ZaBlQdyfnS2PYkPHJAHl4iqB4SnQlh3rwFdKTJMgCz413cDxQHytgRPGTiXOhyV7 aS3ANJFha6ZHA8HU9sTslY8ZXSUu94iD3t2kcF3gBb432UKALwryKqnrwzFX68pFpqO5QAjEHaF6 6p1agMb2b3HlQGZrME5wSO6rsZJPYvJEyvrwHxCxjSTkOdPw6GriWGTMrVMU0fVrfptMS1gxggIT MIICDwIBATBSMEkxCzAJBgNVBAYTAkZSMRQwEgYDVQQKDAtTVE9STVNISUVMRDEkMCIGA1UEAwwb U3Rvcm1zaGllbGQgVXNlcnMgQXV0aG9yaXR5AgUAhSjLuzANBglghkgBZQMEAgEFAKCBkzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIxNTM4MDhaMCgGCSqG SIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCDSjXMT HbexhSLzbFiiQuGN6LOR27DEROO1mlNLhfBJyDANBgkqhkiG9w0BAQEFAASCAQBxMoNTNKXag3YQ XYS3DuE67qJf0QLTWcJYKboaT6WLLcPpcN7a1biKZI3rdcFlkOsHkwWBf/fCXaSBWdrxIUnrOnVe oOAuwGV0yiZiggC9qoZsFGBpcNXEInH2+o0AMUPeiUtlp//3f3ADahIpkHw6cpF3F2XTMM/XPS+Q tG2kRwp/0N2jENvmnUdCaUx74na44h8d9wv+MT+Rr4PS94g22SKCPwBzuCwoz9e8z45db8ZaIn97 H/+rQPf6zczM3hhs5wZCwm5wr3qCO/jlUlxt9JuzBXiYdQRSWa+my2RyZLxZ4Aivpqf8sS8IBoKa ZzmcIBEs1X74vVQsdn5roKXTAAAAAAAA --nextPart1758152.g1Y9NJ3CVh-- From owner-freebsd-arm@freebsd.org Thu Feb 2 16:02:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEEA3CCE0A3 for ; Thu, 2 Feb 2017 16:02:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6783E15CC for ; Thu, 2 Feb 2017 16:02:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v12G1xRI083097 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Feb 2017 18:01:59 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v12G1xRI083097 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v12G1xEA083096; Thu, 2 Feb 2017 18:01:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Feb 2017 18:01:59 +0200 From: Konstantin Belousov To: Alexandre Martins Cc: Freebsd arm Subject: Re: Counter API Message-ID: <20170202160159.GN2092@kib.kiev.ua> References: <2478341.4YUvIvO0Dr@pc-alex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2478341.4YUvIvO0Dr@pc-alex> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:02:09 -0000 On Thu, Feb 02, 2017 at 04:38:08PM +0100, Alexandre Martins wrote: > Hi all, > > Our companie is curently tracking performance issue with our ARM product. > > We have seen that counter API was migrated from intrinsic to atomic. > > https://svnweb.freebsd.org/base?view=revision&revision=269406 > > But there is still the calls to critical_enter/leave in the macro > counter_enter/leave. > > Is that needed ? Can we remove that ? Try this. I did not even compiled the patch. diff --git a/sys/arm/include/counter.h b/sys/arm/include/counter.h index c4da91f7a14..950516e1616 100644 --- a/sys/arm/include/counter.h +++ b/sys/arm/include/counter.h @@ -31,12 +31,9 @@ #include #include -#ifdef INVARIANTS -#include -#endif -#define counter_enter() critical_enter() -#define counter_exit() critical_exit() +#define counter_enter() do {} while (0) +#define counter_exit() do {} while (0) #ifdef IN_SUBR_COUNTER_C @@ -55,7 +52,7 @@ counter_u64_fetch_inline(uint64_t *p) int i; r = 0; - for (i = 0; i < mp_ncpus; i++) + CPU_FOREACH(i) r += counter_u64_read_one((uint64_t *)p, i); return (r); @@ -78,18 +75,13 @@ counter_u64_zero_inline(counter_u64_t c) } #endif -#define counter_u64_add_protected(c, inc) do { \ - CRITICAL_ASSERT(curthread); \ - atomic_add_64((uint64_t *)zpcpu_get(c), (inc)); \ -} while (0) +#define counter_u64_add_protected(c, inc) counter_u64_add(c, inc) static inline void counter_u64_add(counter_u64_t c, int64_t inc) { - counter_enter(); - counter_u64_add_protected(c, inc); - counter_exit(); + atomic_add_64((uint64_t *)zpcpu_get(c), inc); } #endif /* ! __MACHINE_COUNTER_H__ */ diff --git a/sys/arm64/include/counter.h b/sys/arm64/include/counter.h index 9d56cce3d3d..cfa521f9b73 100644 --- a/sys/arm64/include/counter.h +++ b/sys/arm64/include/counter.h @@ -30,12 +30,10 @@ #define _MACHINE_COUNTER_H_ #include -#ifdef INVARIANTS -#include -#endif +#include -#define counter_enter() critical_enter() -#define counter_exit() critical_exit() +#define counter_enter() do {} while (0) +#define counter_exit() do {} while (0) #ifdef IN_SUBR_COUNTER_C static inline uint64_t @@ -52,13 +50,12 @@ counter_u64_fetch_inline(uint64_t *p) int i; r = 0; - for (i = 0; i < mp_ncpus; i++) + CPU_FOREACH(i) r += counter_u64_read_one((uint64_t *)p, i); return (r); } -/* XXXKIB might interrupt increment */ static void counter_u64_zero_one_cpu(void *arg) { @@ -76,18 +73,13 @@ counter_u64_zero_inline(counter_u64_t c) } #endif -#define counter_u64_add_protected(c, inc) do { \ - CRITICAL_ASSERT(curthread); \ - *(uint64_t *)zpcpu_get(c) += (inc); \ -} while (0) +#define counter_u64_add_protected(c, inc) counter_u64_add(c, inc) static inline void counter_u64_add(counter_u64_t c, int64_t inc) { - counter_enter(); - counter_u64_add_protected(c, inc); - counter_exit(); + atomic_add_64((uint64_t *)zpcpu_get(c), inc); } #endif /* ! _MACHINE_COUNTER_H_ */ From owner-freebsd-arm@freebsd.org Fri Feb 3 00:06:41 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EC88CCC102 for ; Fri, 3 Feb 2017 00:06:41 +0000 (UTC) (envelope-from bauergreg786@yahoo.com) Received: from nm38-vm1.bullet.mail.gq1.yahoo.com (nm38-vm1.bullet.mail.gq1.yahoo.com [98.136.217.60]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A32B1881 for ; Fri, 3 Feb 2017 00:06:40 +0000 (UTC) (envelope-from bauergreg786@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1486080394; bh=rG/sWZ0oerpD+B8ZKoCJ7hhUHeVGuNqzTQc+5kyyXS8=; h=From:Subject:Date:To:From:Subject; b=HuHuHLYjzImBelZNcv/O+n/iLLAbcH5ASl8ZfetSacTtz89pyslUr99c83V48p18n8n6oaPINK2nHpxMozf/eijUSrRa/spZVSdz4fXvQIhNzausxjFmAF1lxejIJTENRTNmTEjY+JDk40O+FNwodqJ4twAkZpN14OqYPjyUYCJFqRkG8DE5TXOA8rFxiL2N9m1jLe5omvS8npirxu9mEOmL5yZVHS10cnjUQRF3Z/hbrBdQ7tk+xd7qZYXDN1lHLRyWDFwBnAGbgEOxODa0gfGbbFlAfnnB5w/Efmj/FmO6vP13wwxngrB3SFVrODTZXnvLDHcKIqPRQqaufgpUmw== Received: from [127.0.0.1] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 03 Feb 2017 00:06:34 -0000 Received: from [98.137.12.60] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 03 Feb 2017 00:03:34 -0000 Received: from [98.136.164.70] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 03 Feb 2017 00:03:34 -0000 Received: from [127.0.0.1] by smtp232.mail.gq1.yahoo.com with NNFMP; 03 Feb 2017 00:03:34 -0000 X-Yahoo-Newman-Id: 486682.99066.bm@smtp232.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: tRmsCQ0VM1lG9fWEXAEezv0.wDNJ6V3KmZRghb9lG1tyOyi RQfNyzVizFN35eU7RYoFxlTbqCQOevvV1fLQnd4ZK27pxMKiFK_BGjyOpsQk wu.AIf_rG0b0cigUMnjHgOBM6NyKxm7mcad2usuOFqk1IFYhJiiLVki0g94M tyfSLkvw5TgYynlihJqhnl9nx8qw64vT0D59DbnFBTzZYNT1rElXpYInpLTg VcNEOKyR1e6um7d3peCNxvZAADfx3BaP0G9hr4NB_EbcUcXnyzGmSAuE68Ws yVQZftpB_w5zpsfNN0MRzvgVKhMJXwpkubpnJYte2jJEx9AoCwLATU.W4zkS Kms.HaQTS32q97fmeewLXhT7U9dyuECEnBAe9lw1cTFux7i1cFMIWnHHlMGJ GzYSpdIwAjc0jY_HqSR1SjZ8MjH8jbYkQn9M9xrSOHqNrcpmKuMqo0TO5wEn SUsjRQ62wB4oMSNEpkkd_3quL2IQoOeeYPMre75usgeB8AEEf8QZi1Y5fQtA cE3aoufMB9Eyf4JxkpbhFsrPwi9OyJ213yONp.w7atBUoIxHdK6m_ia09_kj _60oE1D9hisNegD7PjdI- X-Yahoo-SMTP: qDz2MUuswBARL03QLj6PStJko8jkFVhKS27oj2b7nJ7JMIuxeaEPVIHVAfTh6yS_0rS9fEQ- From: greg bauer Mime-Version: 1.0 (1.0) Subject: Poudriere armv6 RPI2 Message-Id: Date: Thu, 2 Feb 2017 17:03:30 -0700 To: freebsd-arm@freebsd.org X-Mailer: iPad Mail (14D27) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:06:41 -0000 This is likely a novice question with an easy answer. I have used poudriere f= or i386 and amd64 builds successfully many times. I thought I would try buil= ding some packages for raspberry Pi.=20 I think I have qemu-arm-static setup correctly with binmiscctl=20 I have done=20 binmiscctl add armv6 \ --interpreter "/usr/local/bin/qemu-arm-static" \ --magic "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0= 2\x00\x28\x00" \ --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe= \xff\xff\xff" \ --size 20 --set-enabled And copied /usr/local/bin/qemu-arm-static into /poudriere/jail/(jail name)/u= sr/local/bin I have tried creating a jail with various combinations of the following and d= eleting unsuccessful attempts with the -d option and trying again=20 With and without=20 -x With both=20 -a arm.armv6 -a armv6 With the following sources=20 -m svn+https release/11.0.1 -m svn+https release/11.0.0 -m none -M /builds/releng/11.0/armv6 (files created with the below shell sc= ript) -m tar=3D/tmp/fbsd110R_arm6.tar (created following these instructions http:/= /phaq.phunsites.net/2015/08/31/freebsd-on-the-raspi-pt-2-crosscompiling-arm6= v-packages-for-freebsd/) ++++++++++++++ Shell script for -M option (I have an updated svn version in /svn/base/relen= g/11.0 ) #!/bin/sh CORES=3D6 TYPE=3Dreleng VERSION=3D11.0 TARGET=3Darm TARGET_ARCH=3Darmv6 UBLDR_LOADADDR=3D0x2000000 KERNCONF=3DRPI2 EMULATOR=3Dqemu-arm-static DESTDIR=3D/builds/${TYPE}/${VERSION}/${TARGET_ARCH} mkdir -p ${DESTDIR} cd ${DESTDIR} mkdir -p ${DESTDIR}/usr/obj export MAKEOBJDIRPREFIX=3D${DESTDIR}/usr/obj mkdir -p ${DESTDIR}/usr/local/bin cp /usr/local/bin/${EMULATOR} ${DESTDIR}/usr/local/bin cp /usr/local/bin/qemu-system-${TARGET} ${DESTDIR}/usr/local/bin mkdir -p ${DESTDIR}/usr/ ln -s /svn/base/${TYPE}/${VERSION}/ ${DESTDIR}/usr/src cd ${DESTDIR}/usr/src make -j ${CORES} -DNO_CLEAN UBLDR_LOADADDR=3D${UBLDR_LOADADDR} TARGET=3D${TA= RGET} TARGET_ARCH=3D${TARGET_ARCH} buildworld make -j ${CORES} -DNO_CLEAN KERNCONF=3D${KERNCONF} TARGET=3D${TARGET} TARGET= _ARCH=3D${TARGET_ARCH} buildkernel make DESTDIR=3D${DESTDIR} TARGET=3D${TARGET} TARGET_ARCH=3D${TARGET_ARCH} in= stallkernel make DESTDIR=3D${DESTDIR} TARGET=3D${TARGET} TARGET_ARCH=3D${TARGET_ARCH} in= stallworld make DESTDIR=3D${DESTDIR} TARGET=3D${TARGET} TARGET_ARCH=3D${TARGET_ARCH} di= stribution ++++++++++++ The error is always as follows.=20 # poudriere bulk -j fbsd110Rarmv6_RPI2 -p HEAD shells/bash [00:00:00] =3D=3D=3D=3D>> Cross-building ports for arm.armv6 on amd64 requir= es QEMU [00:00:00] =3D=3D=3D=3D>> Creating the reference jail... done [00:00:12] =3D=3D=3D=3D>> Mounting system devices for fbsd110Rarmv6_RPI2-HEA= D [00:00:12] =3D=3D=3D=3D>> Mounting ports/packages/distfiles [00:00:12] =3D=3D=3D=3D>> Using packages from previously failed build [00:00:12] =3D=3D=3D=3D>> Mounting packages from: /poudriere/data/packages/f= bsd110Rarmv6_RPI2-HEAD [00:00:12] =3D=3D=3D=3D>> Raising MAX_EXECUTION_TIME and NOHANG_TIME for QEM= U [00:00:12] =3D=3D=3D=3D>> Copying latest version of the emulator from: /usr/= local/bin/qemu-arm-static /etc/resolv.conf -> /poudriere/data/.m/fbsd110Rarmv6_RPI2-HEAD/ref/etc/resol= v.conf [00:00:12] =3D=3D=3D=3D>> Starting jail fbsd110Rarmv6_RPI2-HEAD [00:00:12] =3D=3D=3D=3D>> Error: Unable to execute id(1) in jail. Emulation o= r ABI wrong. [00:00:12] =3D=3D=3D=3D>> Cleaning up [00:00:12] =3D=3D=3D=3D>> Umounting file systems A few questions=20 Is my issue with qemu and binmiscctl or poudriere? Is the -x option necessary when creating the jail? Is -a arm.armv6 or -a armv6 correct? Is there a way to test qemu functionality? Thanks.=20 From owner-freebsd-arm@freebsd.org Fri Feb 3 00:07:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 496F5CCC17F for ; Fri, 3 Feb 2017 00:07:42 +0000 (UTC) (envelope-from free-food-alert-bounces@mailman.stanford.edu) Received: from smtp-grey.stanford.edu (smtp-grey.stanford.edu [171.67.219.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA251905 for ; Fri, 3 Feb 2017 00:07:41 +0000 (UTC) (envelope-from free-food-alert-bounces@mailman.stanford.edu) Received: from smtp.stanford.edu (smtp2.stanford.edu [171.67.219.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-grey.stanford.edu (Postfix) with ESMTPS id E0FFF244A4 for ; Thu, 2 Feb 2017 15:59:14 -0800 (PST) Received: from mailman.stanford.edu (mailman.stanford.edu [171.67.216.245]) by smtp.stanford.edu (Postfix) with ESMTP id 6A32D3437D2 for ; Thu, 2 Feb 2017 15:59:14 -0800 (PST) Subject: [SPAM:#####] 32471 free-food-alert From: free-food-alert-owner@lists.stanford.edu To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7729779330059924681==" Message-ID: Date: Thu, 02 Feb 2017 15:59:13 -0800 Precedence: bulk X-BeenThere: free-food-alert@lists.stanford.edu X-Mailman-Version: 2.1.15 X-List-Administrivia: yes Errors-To: free-food-alert-bounces@lists.stanford.edu Sender: "free-food-alert" X-BeenThere: freebsd-arm@freebsd.org List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:07:42 -0000 --===============7729779330059924681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at free-food-alert-owner@lists.stanford.edu. --===============7729779330059924681== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: free-food-alert@lists.stanford.edu Delivered-To: free-food-alert@lists.stanford.edu Received: from pps00.stanford.edu (pps00.stanford.edu [171.67.214.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailman.stanford.edu (Postfix) with ESMTPS id 67556804D8 for ; Thu, 2 Feb 2017 15:59:13 -0800 (PST) Received: from pps.filterd (pps00.stanford.edu [127.0.0.1]) by pps00.stanford.edu (8.16.0.17/8.16.0.17) with SMTP id v12NxDff008842 for ; Thu, 2 Feb 2017 15:59:13 -0800 Received: from ipcom.comunitel.net (static-52-26-62-95.ipcom.comunitel.net [95.62.26.52] (may be forged)) by pps00.stanford.edu with ESMTP id 288sb8pm3a-1 for ; Thu, 02 Feb 2017 15:59:11 -0800 From: Message-ID: <148607993706.5136.17943123377384346470@ipcom.comunitel.net> MIME-Version: 1.0 To: "free-food-alert" X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Date: Thu, 02 Feb 2017 23:58:57 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Content-Type: multipart/related;boundary="----=_NextPart_000_0001_01D27DE2.9B695DB4" X-MSMail-Priority: Normal Importance: High X-Priority: 3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-02_15:,, signatures=0 Subject: [SPAM:#####] 32471 free-food-alert X-Proofpoint-Spam-Details: rule=spam policy=default score=96 spamscore=96 suspectscore=0 malwarescore=0 phishscore=2 adultscore=0 bulkscore=11 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702020226 X-Grey: yes This is a multi-part message in MIME format. --===============7729779330059924681==-- From owner-freebsd-arm@freebsd.org Fri Feb 3 01:35:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E3AFCCD781 for ; Fri, 3 Feb 2017 01:35:10 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C9471D08 for ; Fri, 3 Feb 2017 01:35:10 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 1E3B1317A9; Thu, 2 Feb 2017 18:35:03 -0700 (MST) Date: Thu, 2 Feb 2017 18:35:03 -0700 From: Brad Davis To: greg bauer Cc: freebsd-arm@freebsd.org Subject: Re: Poudriere armv6 RPI2 Message-ID: <20170203013503.GW70816@corpmail.liquidneon.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 01:35:10 -0000 On Thu, Feb 02, 2017 at 05:03:30PM -0700, greg bauer via freebsd-arm wrote: > This is likely a novice question with an easy answer. I have used poudriere for i386 and amd64 builds successfully many times. I thought I would try building some packages for raspberry Pi. The first question is always, why not use the prebuilt pkgs? I think you are making it too complicated.. Try following these directions: https://planet.freebsd.org/brd/2015/08/25/building-arm-packages-with-poudriere-the-simple-way/ Regards, Brad Davis From owner-freebsd-arm@freebsd.org Fri Feb 3 13:02:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37F46CCDCB3 for ; Fri, 3 Feb 2017 13:02:25 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF21AC4D for ; Fri, 3 Feb 2017 13:02:24 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 047C23760B68; Fri, 3 Feb 2017 14:02:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id E66BD3761E08; Fri, 3 Feb 2017 14:02:09 +0100 (CET) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CGU_CCEWr1d5; Fri, 3 Feb 2017 14:02:09 +0100 (CET) Received: from pc-alex.localnet (fwlabo.stormshield.eu [10.2.0.1]) by work.stormshield.eu (Postfix) with ESMTP id C06173760B68; Fri, 3 Feb 2017 14:02:09 +0100 (CET) From: Alexandre Martins To: Konstantin Belousov Cc: Freebsd arm Subject: Re: Counter API Date: Fri, 03 Feb 2017 14:03:56 +0100 Message-ID: <59508065.2X8Qo0R8aR@pc-alex> Organization: STORMSHIELD User-Agent: KMail/4.14.10 (FreeBSD/10.3-RELEASE-p7; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170202160159.GN2092@kib.kiev.ua> References: <2478341.4YUvIvO0Dr@pc-alex> <20170202160159.GN2092@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2440787.jo5CHQqg38"; micalg="sha256"; protocol="application/pkcs7-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 13:02:25 -0000 --nextPart2440787.jo5CHQqg38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Kontantin. Your patch compille and run great in a 32 bit environment. I don't have= a 64=20 bit one to check. Thank you for your support. Best regards Alexandre Le jeudi 2 f=E9vrier 2017, 18:01:59 Konstantin Belousov a =E9crit : > On Thu, Feb 02, 2017 at 04:38:08PM +0100, Alexandre Martins wrote: > > Hi all, > >=20 > > Our companie is curently tracking performance issue with our ARM pr= oduct. > >=20 > > We have seen that counter API was migrated from intrinsic to atomic= . > >=20 > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D269406 > >=20 > > But there is still the calls to critical_enter/leave in the macro > > counter_enter/leave. > >=20 > > Is that needed ? Can we remove that ? >=20 > Try this. I did not even compiled the patch. >=20 > diff --git a/sys/arm/include/counter.h b/sys/arm/include/counter.h > index c4da91f7a14..950516e1616 100644 > --- a/sys/arm/include/counter.h > +++ b/sys/arm/include/counter.h > @@ -31,12 +31,9 @@ >=20 > #include > #include > -#ifdef INVARIANTS > -#include > -#endif >=20 > -#define=09counter_enter()=09critical_enter() > -#define=09counter_exit()=09critical_exit() > +#define=09counter_enter()=09do {} while (0) > +#define=09counter_exit()=09do {} while (0) >=20 > #ifdef IN_SUBR_COUNTER_C >=20 > @@ -55,7 +52,7 @@ counter_u64_fetch_inline(uint64_t *p) > =09int i; >=20 > =09r =3D 0; > -=09for (i =3D 0; i < mp_ncpus; i++) > +=09CPU_FOREACH(i) > =09=09r +=3D counter_u64_read_one((uint64_t *)p, i); >=20 > =09return (r); > @@ -78,18 +75,13 @@ counter_u64_zero_inline(counter_u64_t c) > } > #endif >=20 > -#define=09counter_u64_add_protected(c, inc)=09do {=09\ > -=09CRITICAL_ASSERT(curthread);=09=09=09\ > -=09atomic_add_64((uint64_t *)zpcpu_get(c), (inc));=09\ > -} while (0) > +#define=09counter_u64_add_protected(c, inc)=09counter_u64_add(c, inc= ) >=20 > static inline void > counter_u64_add(counter_u64_t c, int64_t inc) > { >=20 > -=09counter_enter(); > -=09counter_u64_add_protected(c, inc); > -=09counter_exit(); > +=09atomic_add_64((uint64_t *)zpcpu_get(c), inc); > } >=20 > #endif=09/* ! __MACHINE_COUNTER_H__ */ > diff --git a/sys/arm64/include/counter.h b/sys/arm64/include/counter.= h > index 9d56cce3d3d..cfa521f9b73 100644 > --- a/sys/arm64/include/counter.h > +++ b/sys/arm64/include/counter.h > @@ -30,12 +30,10 @@ > #define=09_MACHINE_COUNTER_H_ >=20 > #include > -#ifdef INVARIANTS > -#include > -#endif > +#include >=20 > -#define=09counter_enter()=09critical_enter() > -#define=09counter_exit()=09critical_exit() > +#define=09counter_enter()=09do {} while (0) > +#define=09counter_exit()=09do {} while (0) >=20 > #ifdef IN_SUBR_COUNTER_C > static inline uint64_t > @@ -52,13 +50,12 @@ counter_u64_fetch_inline(uint64_t *p) > =09int i; >=20 > =09r =3D 0; > -=09for (i =3D 0; i < mp_ncpus; i++) > +=09CPU_FOREACH(i) > =09=09r +=3D counter_u64_read_one((uint64_t *)p, i); >=20 > =09return (r); > } >=20 > -/* XXXKIB might interrupt increment */ > static void > counter_u64_zero_one_cpu(void *arg) > { > @@ -76,18 +73,13 @@ counter_u64_zero_inline(counter_u64_t c) > } > #endif >=20 > -#define=09counter_u64_add_protected(c, inc)=09do {=09\ > -=09CRITICAL_ASSERT(curthread);=09=09=09\ > -=09*(uint64_t *)zpcpu_get(c) +=3D (inc);=09=09\ > -} while (0) > +#define=09counter_u64_add_protected(c, inc)=09counter_u64_add(c, inc= ) >=20 > static inline void > counter_u64_add(counter_u64_t c, int64_t inc) > { >=20 > -=09counter_enter(); > -=09counter_u64_add_protected(c, inc); > -=09counter_exit(); > +=09atomic_add_64((uint64_t *)zpcpu_get(c), inc); > } >=20 > #endif=09/* ! _MACHINE_COUNTER_H_ */ =2D-=20 Alexandre Martins STORMSHIELD --nextPart2440787.jo5CHQqg38 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCOUw ggSGMIICbqADAgECAgUA28zw7TANBgkqhkiG9w0BAQsFADBIMQswCQYDVQQGEwJGUjEUMBIGA1UE CgwLU1RPUk1TSElFTEQxIzAhBgNVBAMMGlN0b3Jtc2hpZWxkIFJvb3QgQXV0aG9yaXR5MB4XDTE0 MDkwNDE1MDcxMFoXDTI0MDkwMTE1MDcxMFowSTELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JN U0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVsZCBVc2VycyBBdXRob3JpdHkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDChwWgC/6VWKL7jgWI3eA2sVvRdOwuHcXsRAAXVWdlMC0ygg7u 45E78GhAnpdl8QbIu7x/Q2zOq6KttspwDEIjkoMLTZngLLlGjYJZPfuSoC6hl9R7vRd5f8Fhu3v0 xQ/7vzKYz4C836IGCrk31gmrPO0H0fxkyxCMfhoTTzue3oXW1IsmQwCrOPOu2Y82QANDhbifWLjI WJetnj58YRKR82KBs3Flbqxtp0mi9+IswMvCCRSoT+ORB73Cl6URt7Qm7BcD+qnkJ9uwlUC94dIl T2hX4ybY/w/ssA17Ew418fgyRCWQXzgjZgZ/XUcw2WP9dIggA7Pg+c/xeROJH1zvAgMBAAGjdjB0 MB0GA1UdDgQWBBShbYRsooCFBXx8dXWANMETW5fXgTAfBgNVHSMEGDAWgBS4Qqn6Z0Twf9NhjOyl x1CutL3sozAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjARBglghkgBhvhCAQEEBAMC AQYwDQYJKoZIhvcNAQELBQADggIBAE6C9zkt2J6dPm2KLbzRS6rBIYZNFi0X59g3ekQ2Sc4UWsq+ B3L86j5xnQSRnIM/DKV1+Q2UHbU/qsh4cto2fwTV6V+aJ07Vu/bJE1rAN4AI4V26ytf7VoBcBjVZ Jq8pHOMp/G2eQH7F1xqzml68DpKku66aUalkcC9IM82m7AW3YAyvDoYEAchv4qyL8qhVLLp6LNru 8ZOhMELhZLWl4ulw/SFDMhcBS6I4wC6icj71MLGSrr61vMktMdwQ+CGFQ5z5JbaxM61VgzKay8+g lw+xTbpnitrDfhkzHs2fdwOOur3vtNnNsrdBWiYPseJ2k4VGD7ov5kITQZckmZyF/V+Ir//agJQG VuwhDZCXgXOvrje+FLYp7tQ9pgSvLbluh1A+ywfyHnFI4n6tZy9SD3MIDgWR4KwFLM1Qmt3NQb32 tkq9Vm0jUcQXFfbnWKLA9krw3m8NmCqhL5PzpfOegYOc0QJWfMQamxeWxXMLk6uKisS//+VqfpCa 5Jx53t+9DmoN1+ob4jOprPaX6tfBBr5djah2yzPGjHEB52VgWXxIF9lCM2z7Qw+zFb2PIdNeSjIk NEFg/1orKAAa5gQXAQynN2J7E+aLf2XLhHcS0v+9yoisPEw9+Tb5F1uQh+gzYD5JUUYcYWncnX8g P8k6X+F5mQ/81IoNL/IejxJgy/LoMIIEVzCCAz+gAwIBAgIFAIUoy7swDQYJKoZIhvcNAQELBQAw STELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVs ZCBVc2VycyBBdXRob3JpdHkwHhcNMTYwOTAxMTUxMTA4WhcNMTcwOTAxMTUxMTA4WjBwMQswCQYD VQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElFTEQxGjAYBgNVBAMMEUFsZXhhbmRyZSBNQVJUSU5T MS8wLQYJKoZIhvcNAQkBFiBhbGV4YW5kcmUubWFydGluc0BzdG9ybXNoaWVsZC5ldTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMN+CnvE13jKEwJ+OyMzwBpC02dY+LpD5luJwnJTVnV2 9aUjEMI+xGFMMHd9kSIVInbk4WDe1ELOKerg0dzgnkRiOHECSGum1UhcZABxQgY2cmSffNQ6JVro 52UaBlt3aTOk3imYJCHUIGgOWMvOtRc8BxyBHdi15FZPj/F9I+AKufRFsBXUakplFIAPEwy3m2eR a/eCMLqGJUyK7YmsAlEnYn2mA38zIoqtKvL6KPHtrV8fw1SRLQ13+j9nu1LlCaqhmLtILFxhV0/9 uDTvx5cKtZ8Xj1nPM6NUUrso9qlXwm4On6Y34pVTtnYGMQRuljil3Hiz84RJjPDJYRGwbgkCAwEA AaOCAR0wggEZMB0GA1UdDgQWBBTmRLIwSfhNwbdfV13xt0G0JHYjPDAfBgNVHSMEGDAWgBShbYRs ooCFBXx8dXWANMETW5fXgTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwID6DARBglghkgBhvhCAQEE BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHBzOi8vcGtpLm5ldGFzcS5jb20vYXV0aC9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0LmNybDAR BgNVHSAECjAIMAYGBFUdIAAwKwYDVR0RBCQwIoEgYWxleGFuZHJlLm1hcnRpbnNAc3Rvcm1zaGll bGQuZXUwDQYJKoZIhvcNAQELBQADggEBALT9NWiAaE6nDev34vShhsyb9lWBOQfCnAMyKwtFy/cU uIoHsxyOanIIQHz0ZtB76GCHDo7RStMyp6RYIefIsxABLhSr4hHapJka9g/X/nxexyr0xyT3IpYQ dmyMSHRT18Z/ZaBlQdyfnS2PYkPHJAHl4iqB4SnQlh3rwFdKTJMgCz413cDxQHytgRPGTiXOhyV7 aS3ANJFha6ZHA8HU9sTslY8ZXSUu94iD3t2kcF3gBb432UKALwryKqnrwzFX68pFpqO5QAjEHaF6 6p1agMb2b3HlQGZrME5wSO6rsZJPYvJEyvrwHxCxjSTkOdPw6GriWGTMrVMU0fVrfptMS1gxggIT MIICDwIBATBSMEkxCzAJBgNVBAYTAkZSMRQwEgYDVQQKDAtTVE9STVNISUVMRDEkMCIGA1UEAwwb U3Rvcm1zaGllbGQgVXNlcnMgQXV0aG9yaXR5AgUAhSjLuzANBglghkgBZQMEAgEFAKCBkzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDMxMzAzNTZaMCgGCSqG SIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCC4ICES r/F4vY5/oDKYnT4L50GYuba2eqmJUHgEV46eRDANBgkqhkiG9w0BAQEFAASCAQBfZnvu+JMW1RME I4rq13tafGAUaueWd+kBamDuu+Y6u50bDxTtumz8LVBPknzK266fqM9cGtFx6kmSVqMU8CLn7eV+ uauwwiPIo9dAlnm7YdZaxNLymh8iVRB4983rX0Fa9LkZbEY52HgzoSI0Xg/H+35u9uPv0jY+btL3 pGvxFHIoTQm4sl+AxOnrJw4gZj5NE9vQ5IsGjY/fO9k6d6Yul4HZU/hBJB1sRr5ZTlhdss7EjnCX nAbhrtl87RKZPrq3o3OhR3Tb2GNz5b4URbfrMQiVw5QG17ghZziYnyBt5rAzfjhU4rkD4g844LtT Rjetmc00lll/GrSbr6yQ101SAAAAAAAA --nextPart2440787.jo5CHQqg38-- From owner-freebsd-arm@freebsd.org Fri Feb 3 16:35:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D91CCFD9B for ; Fri, 3 Feb 2017 16:35:16 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 146E3E9F for ; Fri, 3 Feb 2017 16:35:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v13GENUJ072661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Feb 2017 08:14:24 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v13GEN0c072660; Fri, 3 Feb 2017 08:14:23 -0800 (PST) (envelope-from fbsd) Date: Fri, 3 Feb 2017 08:14:23 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Problems building world on 313159 Message-ID: <20170203161423.GA72630@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:35:16 -0000 For the last couple of days buildworld has been stopping with the error /usr/src/sys/boot/efi/libefi/env.c:97:50: error: format specifies type 'unsigned long' but the argument has type 'EFI_STATUS' (aka 'unsigned int') [-Werror,-Wformat] printf("Can't get the variable: error %#lx\n", status); ~~~~ ^~~~~~ %#x The sources are at 313159, the building system is at r312991. The first time it failed I ran a make clean, the second time I removed /usr/obj/usr, each time updating sources between tries. This is self-hosted on an RPI2, but the error looks hardware-independent to me. Absence of prior discussion suggests some local mistake. No intentional changes have been made for over a month, so I'm stumped. Thanks for reading, any suggestions appreciated. bob prohaska From owner-freebsd-arm@freebsd.org Fri Feb 3 18:19:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 385DBCCF91E for ; Fri, 3 Feb 2017 18:19:28 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id E87E1A2 for ; Fri, 3 Feb 2017 18:19:27 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id F314762E2E for ; Fri, 3 Feb 2017 12:19:20 -0600 (CST) To: freebsd-arm@freebsd.org From: Karl Denninger Subject: NanoBSD config script for RPI2 Message-ID: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> Date: Fri, 3 Feb 2017 12:19:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010902000404090702080108" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:19:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010902000404090702080108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anyone got a working one? Having some trouble getting usable output from it... For reference I have sources in /pics/CrossBuild and the "mk" script to crossbuild which *does* work; after doing an "install" (into nfsroot) I can then rsync that to a running unit and the update is successful. I'd like to be able to build off the same source tree since it's already there and distinct from my x86 stuff. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010902000404090702080108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDMxODE5MDBaME8GCSqGSIb3DQEJBDFCBEDD6wt0 J4MhngTPX1s1z8vlHq9cJy6Det/bzFkem1IuPH0oUini3F1YtHS1Ur/uAZS1ZZ8JzedlpAVE BFdrIzYrMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAbk/6ZDb8SkE3 EHAdPWB3aNi6m+GEGcgMTBCmCvrj/DuTEgaFA2lKTcTDxjZ/NSGzm7LkX9BNptxnFShFEuT5 DoGNVFYP8PyKiMacPw4Wygbjh7lD6fIYofC/URrvTRnnleZonZurlYMWV8QNK7mEcJzC1wWy pUnZYU8y+6kHqwLsKCdkVem0wvjjtd7QBZ/KuVsJak1v9hiSIPpTG4QZBrIJyzRa1LzOzQCN aswJrshWUneGTbAHAPUMnK2l92YC+DbIey2eq8ciZuKiPFV7Hrz4sZRtbSqNtE4plzX6ltwg P4y/4JNCLw8geGPz2p8X7aN1qSLoFmvq5LqaMTa+TixbElJA7q+d7dzPGzEVjMD836M0Ni0g LZypAkLyeuWGUU7g09rhcvB/qnqoEWf9UhOjBDo7Hf7MqTAlri3slKoAYn6foWcHQEZ2QPsf NtXxmqSREIEwFdr2jkkaCHurkQWovdyizHzgnR/H6H5AAiZLa8R9EhAU6QmkBiLJRujPaaDc 1zSTl6hmTabslTt6oY5g2im3SawTezPOixPElkPq36A1jsCG/oP9X2Hj6kXVCx0LRafKg4PO W117F1pwxy9AY8D8oDsMJuEzl9+p7w2m7VwKx8ZEfy34T6PuJXmeaMTv+SECY2KmJsgU2xWt tMPTfip7QAQUvSBwmMn9nncAAAAAAAA= --------------ms010902000404090702080108-- From owner-freebsd-arm@freebsd.org Fri Feb 3 18:21:17 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76E1BCCFAED for ; Fri, 3 Feb 2017 18:21:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19546670 for ; Fri, 3 Feb 2017 18:21:16 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8a41ef71-ea3d-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 8a41ef71-ea3d-11e6-95b5-6dfd7dbb0ee5; Fri, 03 Feb 2017 18:21:12 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v13IL5Hf024551; Fri, 3 Feb 2017 11:21:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1486146065.3017.194.camel@freebsd.org> Subject: Re: Problems building world on 313159 From: Ian Lepore To: bob prohaska , freebsd-arm@freebsd.org Date: Fri, 03 Feb 2017 11:21:05 -0700 In-Reply-To: <20170203161423.GA72630@www.zefox.net> References: <20170203161423.GA72630@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:21:17 -0000 On Fri, 2017-02-03 at 08:14 -0800, bob prohaska wrote: > For the last couple of days buildworld has been stopping with the > error > > /usr/src/sys/boot/efi/libefi/env.c:97:50: error: format specifies > type 'unsigned long' but the argument has type 'EFI_STATUS' (aka > 'unsigned int') [-Werror,-Wformat] >                 printf("Can't get the variable: error %#lx\n", > status); >                                                       ~~~~     ^~~~~~ >                                                       %#x > The sources are at 313159, the building system is at r312991. The > first  > time it failed I ran a make clean, the second time I removed > /usr/obj/usr, > each time updating sources between tries. > > This is self-hosted on an RPI2, but the error looks hardware- > independent > to me. Absence of prior discussion  suggests some  local mistake. > No intentional changes have been made for over a month, so I'm > stumped. > > Thanks for reading, any suggestions appreciated. > > bob prohaska Looks like a fix was committed in r313166. -- Ian From owner-freebsd-arm@freebsd.org Fri Feb 3 20:21:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E984CCEE45 for ; Fri, 3 Feb 2017 20:21:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 728B21880 for ; Fri, 3 Feb 2017 20:21:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id v96so26324798ioi.0 for ; Fri, 03 Feb 2017 12:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oyNNUKTvNQtEWEjwZCq8LwDfhdCdfpoTpFcmNRq4Z5c=; b=ZwdQ343wKToyJQbSm5tZAfev1FSx5P40iihRSgTIYXesjwG6MR9jDwR5S5Ph3zWeZH f1csqad7No8K7F+S6cIRVWq6QQeU9AubiHCAOyMY85eI+K52KZfM8ZEY2QCg+RVSYe6J vqqzv2fJx8kAHp1Umnxh0bu5kAwjDIOHumRLNJUhL+iCrqhGe8P1aEFhZPmdPTA//IJQ ymnpXimgNI+Im/LI5JqzgZEfttfa3rb63CfHjciLVmI+5BqkY4HbVmj4fDQn35DP7Cyw OnKR9F5gheWvu0FefqHhphJFzM+mBTlSEpqwz88wS4s6iWfv4h0flInOGmvbpMIK4S1y Eogg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oyNNUKTvNQtEWEjwZCq8LwDfhdCdfpoTpFcmNRq4Z5c=; b=iVzTq0uVlmS3wjT9IRY2gPzjZ4elXR/l5cwvZt6DAM/F68bXGI7+qfxhWreAzPpVdk G72IzTG6eGZ85TgcIzM/9x+ynyKPkUG3sDWZBUH35tW5bn0x26a8Lm52WPXTG7lLvfQH aj64D0QzwFISM2hqQ1g57INDN61pB9+uICAo/U9/jZ9050Cw83N5DV4udVzXeNMe3nyC +f1j5bybRICr7dtFHOMNV3sH+I1f0QpBaJVIjwbx1BH5MUpgMmk5G7JDcRpODfKCZT1n XtXHYMjma4d+8/35jZS2z7caU4CMRkzjutJZvv8eAN6UlHIk5W1YAPwOHRL7Bd2Pj/2i HfYQ== X-Gm-Message-State: AIkVDXI7cMM1JTdNnmxqBLBXw3w1ajGjG2MqXL8Rtuzlb3pXV+t67JU+ip3Oel4rjhmYXSrnRQwkSSMvItok/g== X-Received: by 10.107.20.13 with SMTP id 13mr11547304iou.0.1486153306631; Fri, 03 Feb 2017 12:21:46 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Fri, 3 Feb 2017 12:21:44 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> From: Warner Losh Date: Fri, 3 Feb 2017 13:21:44 -0700 X-Google-Sender-Auth: TCnp0tWMmzo21hgjbgTBwu-cp68 Message-ID: Subject: Re: NanoBSD config script for RPI2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:21:47 -0000 I've used tools/tools/nanobsd/embedded/rpi2.cfg in the past to create images for my rpi2. It has been a while, but I don't think anything should have broken it... Warner On Fri, Feb 3, 2017 at 11:19 AM, Karl Denninger wrote: > Anyone got a working one? Having some trouble getting usable output > from it... > > For reference I have sources in /pics/CrossBuild and the "mk" script to > crossbuild which *does* work; after doing an "install" (into nfsroot) I > can then rsync that to a running unit and the update is successful. I'd > like to be able to build off the same source tree since it's already > there and distinct from my x86 stuff. > > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Sat Feb 4 12:55:32 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3102CCDFF2 for ; Sat, 4 Feb 2017 12:55:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id B7053FBB for ; Sat, 4 Feb 2017 12:55:32 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id A3F8262979 for ; Sat, 4 Feb 2017 06:55:31 -0600 (CST) Subject: Re: NanoBSD config script for RPI2 References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> Date: Sat, 4 Feb 2017 06:55:10 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030702080204030000000100" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 12:55:33 -0000 This is a cryptographically signed message in MIME format. --------------ms030702080204030000000100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It fails here during image create.... Populating `/pics/CrossBuild/embedded/rpi2/_.s2' Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete + [ -n s1 ] + eval 's1=3Dfat16b' + s1=3Dfat16b + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP + mkimg -a 3 -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s1' -p= 'freebsd :=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p 'freebsd:=3D/pics/CrossBuild/embedded/rp i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP mkimg: invalid option -- a mkimg: error: unknown option usage: mkimg options: --formats - list image formats --schemes - list partition schemes --version - show version information -b - file containing boot code -c - capacity (in bytes) of the disk -f -o - file to write image into -p -s -v - increase verbosity -y - [developers] enable unit test -H - number of heads to simulate -P - physical sector size -S - logical sector size -T - number of tracks to simulate formats: qcow - QEMU Copy-On-Write, version 1 qcow2 - QEMU Copy-On-Write, version 2 raw - Raw Disk vhd - Virtual Hard Disk vhdf - Fixed Virtual Hard Disk vmdk - Virtual Machine Disk schemes: apm - Apple Partition Map bsd - BSD disk label ebr - Extended Boot Record gpt - GUID Partition Table mbr - Master Boot Record pc98 - PC-9800 disk partitions vtoc8 - SMI VTOC8 disk labels Is the "-a" flag attempting to set the active partition? It appears there's no option to do that in mkimg... On 2/3/2017 14:21, Warner Losh wrote: > I've used tools/tools/nanobsd/embedded/rpi2.cfg in the past to create > images for my rpi2. It has been a while, but I don't think anything > should have broken it... > > Warner > > On Fri, Feb 3, 2017 at 11:19 AM, Karl Denninger wr= ote: >> Anyone got a working one? Having some trouble getting usable output >> from it... >> >> For reference I have sources in /pics/CrossBuild and the "mk" script t= o >> crossbuild which *does* work; after doing an "install" (into nfsroot) = I >> can then rsync that to a running unit and the update is successful. I= 'd >> like to be able to build off the same source tree since it's already >> there and distinct from my x86 stuff. >> >> >> -- >> Karl Denninger >> karl@denninger.net >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030702080204030000000100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDQxMjU1MTBaME8GCSqGSIb3DQEJBDFCBEDfLgzN 3bjJmkFkuFwy57snQDNPrTibmojLBjZeeBKFptRBEDkwXLW7iXykyDwTZezx6PlEhwFJORp0 JxPa6kNvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAVTkyKqK5PQxn TvFVRfj505XMWqs9Q9g+Q+4kNwnFV6fLsdrR3avd0B6Babac5GLumsYR52UvU/hNJbAAI9WW Sny/jidpK3alvVoND7U80Oy7zmOU0Un5sGb91qbV0pfGDMJQb38ucPCNCp79HMJZ1lrxvGES EvqT/XlnEjtvm0TTdR9+mL/j8UQWdj8A2uPX1isL0vZh7oElZr+qCYQQML+TrmLWkJu0/kVO dEKdZz5VgcYAYE85r7DsK5LJ0+n7FfNnkiW7nZBxBPq3JEPXdlzLYVVYp155Fj8KTkqEuKSl j8J88a6076Xllf5diqkjP0Evnf4cGeu/U9vaR7KpEQDtj3d4N5h4+oA3Kpz1wwar10jYCGAO +CLXW+Cb2n6OHZ5r10e7fOfth5FZqqhmChfXq5HZ1koldg+v6ao0yqnTzr/q5PGaapmXuvWi U8Ae/yk2ns/UlRPPt01MIjdAvVdmc83Oj5las0KZTyGOa3b6jwYQJxquzuy32R8F3m3GIiE6 LZJk7g9iOAYV5tNf5mAgfATWn0X4/ct5WKIL7A9wxLZ+G2lSFrsSGISePlUTtparn3X4KexY IZR1hW2x8FsdIWHrJnM4UexG8cpEgIPlKNobAbYVbzRcPV0VXFDy2Dp8sO1y0pPvIUmtxVfS rao2RCCcZ/2crMACsw1KsqIAAAAAAAA= --------------ms030702080204030000000100-- From owner-freebsd-arm@freebsd.org Sat Feb 4 16:38:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE785CD0A42 for ; Sat, 4 Feb 2017 16:38:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A77101C9D for ; Sat, 4 Feb 2017 16:38:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id c7so32327121itd.1 for ; Sat, 04 Feb 2017 08:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ng2B6Y/Edl9HUVO874THBxKcPWV9muGVdIj4hapT7zI=; b=rIIsVM0LMa9oBal+t/8OBhD0VrLgnQOsadV1O8bVT33w91ORVv+PJVvgoV+WUh+6li uL3JMgmVSsHJzCuV7LJyAmyqpXi6rTeWxH8iKHeKpZQM43Eyr8gU5A96gqr9FrcfZHFk Q0Vy5K8iKUBZoeW48Es5arnSbyGY1FZp5VaDBjaQm4Y1JDkT4mJQt2lbChm1RpYQW7WV ewD8S5kewLGMDT8EJXyuPaJk9OMixQ1nfg6E4J2nxxzLFp2zIA9nNvZba5RLwgXcfQAI g/r+YhI524si0w14iSW6jAnTzssNEBM/kbsVjgzlA3L0bG0vrMLwLH0o4KX2y005jynr Ko2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ng2B6Y/Edl9HUVO874THBxKcPWV9muGVdIj4hapT7zI=; b=ZxEuNTU9gPU30rccthYRCy+hdGCsylgkZ1noAJ+qfgNV+96rzRFwaSTSmb3x17ZjCO PAHKocLrjRkq3P/ZikWZvaw2Te0+LSe2l7cNUK6Fe/xXUXkO6a8hhz3iS3kufH1IeUn8 K9YIAYi2+6D5QHEnPPUuN5CAhhcdpwIBmaeB67yhALZyOZcO44gzforEz9KtwZIpo8ir WPeCOsi2FpBpH9hruHVu/9JkLJMIKUx8ifzndPvmMhF+jlGm9/AJ1nlBN8jVgiiuFsWB HELu7cLKHpXK+Fi+JVDpCisT/iBx6nSaMVBxM4uOwGtfHK4RmPxt5WDtakXcHi3mwiiA vlzg== X-Gm-Message-State: AIkVDXIBaJgUc2XVNcyxvjY2b5jXXrrUXSKecp5equBp4dgxv2fXHvOAzhxqm8/kjmdxT92yxwMGQ7S9rs92mw== X-Received: by 10.36.90.194 with SMTP id v185mr1720389ita.85.1486226322876; Sat, 04 Feb 2017 08:38:42 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sat, 4 Feb 2017 08:38:42 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> From: Warner Losh Date: Sat, 4 Feb 2017 09:38:42 -0700 X-Google-Sender-Auth: PpjSh3UZckojiWe4R4yLQLX898s Message-ID: Subject: Re: NanoBSD config script for RPI2 To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 16:38:43 -0000 On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger wrote: > It fails here during image create.... > > Populating `/pics/CrossBuild/embedded/rpi2/_.s2' > Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete > + [ -n s1 ] > + eval 's1=fat16b' > + s1=fat16b > + out=/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > + mkimg -a 3 -s mbr -p 'fat16b:=/pics/CrossBuild/embedded/rpi2/_.s1' -p > 'freebsd > :=/pics/CrossBuild/embedded/rpi2/_.s2' -p > 'freebsd:=/pics/CrossBuild/embedded/rp > i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP > mkimg: invalid option -- a > mkimg: error: unknown option > > usage: mkimg > options: > --formats - list image formats > --schemes - list partition schemes > --version - show version information > > -b - file containing boot code > -c - capacity (in bytes) of the disk > -f > -o - file to write image into > -p > -s > -v - increase verbosity > -y - [developers] enable unit test > -H - number of heads to simulate > -P - physical sector size > -S - logical sector size > -T - number of tracks to simulate > > formats: > qcow - QEMU Copy-On-Write, version 1 > qcow2 - QEMU Copy-On-Write, version 2 > raw - Raw Disk > vhd - Virtual Hard Disk > vhdf - Fixed Virtual Hard Disk > vmdk - Virtual Machine Disk > > schemes: > apm - Apple Partition Map > bsd - BSD disk label > ebr - Extended Boot Record > gpt - GUID Partition Table > mbr - Master Boot Record > pc98 - PC-9800 disk partitions > vtoc8 - SMI VTOC8 disk labels > > Is the "-a" flag attempting to set the active partition? It appears > there's no option to do that in mkimg... Install a newer mkimg: Revision 307550 - (view) (download) (annotate) - [select for diffs] Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp File length: 3730 byte(s) Diff to previous 307544 Add a new flag to mkimg (-a num) to specify the active partition for those partitioning schemes that have this concept. Implement it as an override for mbr's setting 0x80 in the flags for the first partition when we have boot code. Differential Revision: https://reviews.freebsd.org/D4403 Though maybe I should try to add it to the bootstrap tools so I can use a new one after the build. Warner > On 2/3/2017 14:21, Warner Losh wrote: >> I've used tools/tools/nanobsd/embedded/rpi2.cfg in the past to create >> images for my rpi2. It has been a while, but I don't think anything >> should have broken it... >> >> Warner >> >> On Fri, Feb 3, 2017 at 11:19 AM, Karl Denninger wrote: >>> Anyone got a working one? Having some trouble getting usable output >>> from it... >>> >>> For reference I have sources in /pics/CrossBuild and the "mk" script to >>> crossbuild which *does* work; after doing an "install" (into nfsroot) I >>> can then rsync that to a running unit and the update is successful. I'd >>> like to be able to build off the same source tree since it's already >>> there and distinct from my x86 stuff. >>> >>> >>> -- >>> Karl Denninger >>> karl@denninger.net >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Sat Feb 4 18:57:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1235DCD059C for ; Sat, 4 Feb 2017 18:57:19 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id DA2FDE4A for ; Sat, 4 Feb 2017 18:57:18 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 2DF2062942 for ; Sat, 4 Feb 2017 12:57:12 -0600 (CST) Subject: Re: NanoBSD config script for RPI2 References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: Date: Sat, 4 Feb 2017 12:56:51 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060804020907090207020902" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 18:57:19 -0000 This is a cryptographically signed message in MIME format. --------------ms060804020907090207020902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/4/2017 10:38, Warner Losh wrote: > On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger wro= te: >> It fails here during image create.... >> >> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >> + [ -n s1 ] >> + eval 's1=3Dfat16b' >> + s1=3Dfat16b >> + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >> + mkimg -a 3 -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s1'= -p >> 'freebsd >> :=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p >> 'freebsd:=3D/pics/CrossBuild/embedded/rp >> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >> mkimg: invalid option -- a >> mkimg: error: unknown option >> >> usage: mkimg >> options: >> --formats - list image formats >> --schemes - list partition schemes >> --version - show version information >> >> -b - file containing boot code >> -c - capacity (in bytes) of the disk >> -f >> -o - file to write image into >> -p >> -s >> -v - increase verbosity >> -y - [developers] enable unit test >> -H - number of heads to simulate >> -P - physical sector size >> -S - logical sector size >> -T - number of tracks to simulate >> >> formats: >> qcow - QEMU Copy-On-Write, version 1 >> qcow2 - QEMU Copy-On-Write, version 2 >> raw - Raw Disk >> vhd - Virtual Hard Disk >> vhdf - Fixed Virtual Hard Disk >> vmdk - Virtual Machine Disk >> >> schemes: >> apm - Apple Partition Map >> bsd - BSD disk label >> ebr - Extended Boot Record >> gpt - GUID Partition Table >> mbr - Master Boot Record >> pc98 - PC-9800 disk partitions >> vtoc8 - SMI VTOC8 disk labels >> >> Is the "-a" flag attempting to set the active partition? It appears >> there's no option to do that in mkimg... > Install a newer mkimg: > > Revision 307550 - (view) (download) (annotate) - [select for diffs] > Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp > File length: 3730 byte(s) > Diff to previous 307544 > > Add a new flag to mkimg (-a num) to specify the active partition for > those partitioning schemes that have this concept. Implement it as an > override for mbr's setting 0x80 in the flags for the first partition > when we have boot code. > > Differential Revision: https://reviews.freebsd.org/D4403 > > Though maybe I should try to add it to the bootstrap tools so I can > use a new one after the build. > > Warner > root@NewFS:/disk/karl # uname -v FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP root@NewFS:/disk/karl # which mkimg /usr/bin/mkimg root@NewFS:/disk/karl # pkg install mkimg Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. pkg: No packages available to install matching 'mkimg' have been found in the repositories root@NewFS:/disk/karl # So.... it's part of base and there is no obvious package (a check for ports in */*mkimg* fails too); my system is current as of Jan 23.... (As an aside I think if I remove the -a it may work on the Pi, since the Pi will try to boot the first partition which happens to be DOS -- I think. I'll try it.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060804020907090207020902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDQxODU2NTFaME8GCSqGSIb3DQEJBDFCBEBKgq6c dLEN74uJatPFMYZU/Vj7DSfriB0wgVYWo7ICY8hFNBuPsHW7k9Wd6mq6M+hEly+tY17bW7sL j7Vq1ohBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAWRXuLHZZUi5H Wsv6cWZeuYy+wzh+IoV2qXz1OU4zsp+wzTYAN+/dKqMebn5th6z85sc2HQpenEBoRZFwVrqg +J0jU7/kaD46pVEaE8G4s59GtWu8gy0v3OlUyBnfFglfKJLMg8NnNqGERy+pj21bzOQmIUyu j9CLKuHFt/mSJDFN9ZaAZx8fH8gL48+YH1cshLSnWfkRQLONEPjS1LzESBHGy8mQ2QuIb+vi UYm4WNCaQCV7EZxZhEDmOpJpTuEwIET7wM4DxcRBfujb4hxjryUDKCxsAac5EarxPRl71b0p VfIqTh8cNORXqfj8V+rzuO7+z16iEQ0bS6VmQPQUG3EIRqt+wlXw3HwSOO+2G+sdz9/IQOip OUSG731CO5gvKO/NnWI6eqqYN7VgbgAobtlUydE4tyU0ciEi5C6zrAr3jOO+fv5wSZf5ewrm NQn06THMNBr8HhvXOASKfmopBwHrCCeXmx4qbSyLaowEzZeb+WgX/ACbBdVWq+XwJMeUEPMy 07HMIgFXW/qaDyHVsT8QyAmnUZR8gEMfdS+Shel7JDCOBNoxlbe0Ia/8mQ7HP4o5DEagh2cq GSqazpwzhlPD7BMswFB2hKAfL8byESX80dejYOGkse1UWdTASuz75LfwLe4YDekO0WuOD15C xO4HsYL7b6EmovP0p+yxRDQAAAAAAAA= --------------ms060804020907090207020902-- From owner-freebsd-arm@freebsd.org Sat Feb 4 19:39:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F674CD1118 for ; Sat, 4 Feb 2017 19:39:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 4D86A183 for ; Sat, 4 Feb 2017 19:39:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 799321183FA for ; Sat, 4 Feb 2017 13:39:34 -0600 (CST) Subject: Re: NanoBSD config script for RPI2 To: freebsd-arm@freebsd.org References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> From: Karl Denninger Message-ID: Date: Sat, 4 Feb 2017 13:39:13 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060607030508020705070902" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 19:39:35 -0000 This is a cryptographically signed message in MIME format. --------------ms060607030508020705070902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/4/2017 12:56, Karl Denninger wrote: > On 2/4/2017 10:38, Warner Losh wrote: >> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger wr= ote: >>> It fails here during image create.... >>> >>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>> + [ -n s1 ] >>> + eval 's1=3Dfat16b' >>> + s1=3Dfat16b >>> + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mkimg -a 3 -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s1= ' -p >>> 'freebsd >>> :=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p >>> 'freebsd:=3D/pics/CrossBuild/embedded/rp >>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> mkimg: invalid option -- a >>> mkimg: error: unknown option >>> >>> usage: mkimg >>> options: >>> --formats - list image formats >>> --schemes - list partition schemes >>> --version - show version information >>> >>> -b - file containing boot code >>> -c - capacity (in bytes) of the disk >>> -f >>> -o - file to write image into >>> -p >>> -s >>> -v - increase verbosity >>> -y - [developers] enable unit test >>> -H - number of heads to simulate >>> -P - physical sector size >>> -S - logical sector size >>> -T - number of tracks to simulate >>> >>> formats: >>> qcow - QEMU Copy-On-Write, version 1 >>> qcow2 - QEMU Copy-On-Write, version 2 >>> raw - Raw Disk >>> vhd - Virtual Hard Disk >>> vhdf - Fixed Virtual Hard Disk >>> vmdk - Virtual Machine Disk >>> >>> schemes: >>> apm - Apple Partition Map >>> bsd - BSD disk label >>> ebr - Extended Boot Record >>> gpt - GUID Partition Table >>> mbr - Master Boot Record >>> pc98 - PC-9800 disk partitions >>> vtoc8 - SMI VTOC8 disk labels >>> >>> Is the "-a" flag attempting to set the active partition? It appears >>> there's no option to do that in mkimg... >> Install a newer mkimg: >> >> Revision 307550 - (view) (download) (annotate) - [select for diffs] >> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >> File length: 3730 byte(s) >> Diff to previous 307544 >> >> Add a new flag to mkimg (-a num) to specify the active partition for >> those partitioning schemes that have this concept. Implement it as an >> override for mbr's setting 0x80 in the flags for the first partition >> when we have boot code. >> >> Differential Revision: https://reviews.freebsd.org/D4403 >> >> Though maybe I should try to add it to the bootstrap tools so I can >> use a new one after the build. >> >> Warner >> > root@NewFS:/disk/karl # uname -v > FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 > karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP > root@NewFS:/disk/karl # which mkimg > /usr/bin/mkimg > root@NewFS:/disk/karl # pkg install mkimg > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > pkg: No packages available to install matching 'mkimg' have been found > in the repositories > root@NewFS:/disk/karl # > > So.... it's part of base and there is no obvious package (a check for > ports in */*mkimg* fails too); my system is current as of Jan 23.... > > (As an aside I think if I remove the -a it may work on the Pi, since th= e > Pi will try to boot the first partition which happens to be DOS -- I > think. I'll try it.) > There's another (potentially large) problem: If you need to add packages to the distribution, and the target of the build is not the same as the machine you're building on then the pkg add command in the handbook fails= =2E root@NewFS:/pics/CrossBuild/embedded/rpi2 # more _.cust.install_packages + install_packages + mkdir -p /pics/CrossBuild/embedded/rpi2/_.w/packages + cp /pics/CrossBuild/src/tools/tools/nanobsd/packages/dhcpd-5.8.20151202.txz /pics/CrossBuild/src/tools/tools/nanobsd/packages/net-snmp-5.7.3_11.txz /pics/CrossBuild/src/tools/tools/nanobsd/packages/ntimed-0.0.2015.01.30.t= xz /pics/CrossBuild/embedded/rpi2/_.w/packages + chroot /pics/CrossBuild/embedded/rpi2/_.w sh -c 'cd packages; pkg_add -v *;cd ..;' chroot: sh: Exec format error You chroot into there and the image you're attempting to "pkg_add" with it an arm executable, which of course my nice Amd64 processor cannot grok..... Fixing that might get kinda messy (are the databases even compatible across architectures?) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060607030508020705070902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDQxOTM5MTNaME8GCSqGSIb3DQEJBDFCBEAGKrao +sEMMFbjDzbZmdjcxBZa+GVs9e5CaAQTpn3vU0LaE0PtzzqNCGfly4Bue5iCb2a7vF6mmfwI LoN6wyIFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAQJe50DmxP5gj RsjLzVCa4rNHCWc/bpMwJfx/bQw/FeIcwPJdcnlS3Go9ui3EsTm/F3d9Wu4R5AGuddgHTWPt W2909QyT+6NCiC2ihm3s60b9QzSgVKqn5nEAurgwUlxYZNlMAMtBsIwJpiT+I6NxBO7QTCxS cDhih8AgU0wDrGvskBhGEVyn575iqlV6+HW5U7jJ3id7USm+pZlSSFJ7lE0ZJLrhyNHZ6sdm pBzp1YRyfiIrFl6Hk2Ac3UNZFtVxKZ7En4ROizdkttxNRk/4GYQRm1Pj/KYoZO5+faRB7EEg 70iGkqfwvkm0PJd/00SOHvjE2zmPKf2SqDk+bgYe5YwH0BoZR6NvPfGAb64NatoL6A4yvJuy +lbXUd1kIthag0JK3sGXSAe0NTf7srvAuNROpcn3fM2LEhKFGIfgSB/jTZrlHFYKqJ2YfZJv m4a+3tZFlIYKPBzkyVTNZnfm1PoPSfEw8bRL4BmYywEb1KPx2yhYiNPTRUNUb7vgoKM6tdIu nTbtP/N7614ieNoQzhWfAwlsn1AZR43bjB7vqPUIZX/oYwP28YqrXE4sClOiOO7/YXeQZhYF SkaSHwcCA6ISKOzo1OWJQs9jWviV/JflEuo549d8YVeOyZtrp51SXNfMffDWhmT52ChiXjS1 6AiEcLDU/tWQ4Y7gLs+N9lYAAAAAAAA= --------------ms060607030508020705070902-- From owner-freebsd-arm@freebsd.org Sat Feb 4 21:02:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3627CCE9AA for ; Sat, 4 Feb 2017 21:02:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 940E0123F for ; Sat, 4 Feb 2017 21:02:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13016 invoked from network); 4 Feb 2017 21:03:54 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Feb 2017 21:03:54 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.30.0) with SMTP; Sat, 04 Feb 2017 16:02:04 -0500 (EST) Received: (qmail 20343 invoked from network); 4 Feb 2017 21:02:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Feb 2017 21:02:04 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 94131EC7E21; Sat, 4 Feb 2017 13:02:03 -0800 (PST) From: Mark Millard Message-Id: <1892E365-966E-4DFA-8DE0-9BAD584754A1@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: NanoBSD config script for RPI2 Date: Sat, 4 Feb 2017 13:02:02 -0800 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Karl Denninger References: <69c5a012-c1e7-c887-cd3b-ffcf78d8175e@denninger.net> <506d5c30-93f7-048e-2cde-d76bfaf76a8f@denninger.net> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 21:02:11 -0000 On 2017-Feb-4, at 10:56 AM, Karl Denninger = wrote: > On 2/4/2017 10:38, Warner Losh wrote: >> On Sat, Feb 4, 2017 at 5:55 AM, Karl Denninger wrote: >>> It fails here during image create.... >>>=20 >>> Populating `/pics/CrossBuild/embedded/rpi2/_.s2' >>> Image `/pics/CrossBuild/embedded/rpi2/_.s2' complete >>> + [ -n s1 ] >>> + eval 's1=3Dfat16b' >>> + s1=3Dfat16b >>> + out=3D/pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> + mkimg -a 3 -s mbr -p 'fat16b:=3D/pics/CrossBuild/embedded/rpi2/_.s1'= -p >>> 'freebsd >>> :=3D/pics/CrossBuild/embedded/rpi2/_.s2' -p >>> 'freebsd:=3D/pics/CrossBuild/embedded/rp >>> i2/_.s3' -o /pics/CrossBuild/embedded/images/_.disk.image.HD-MCP >>> mkimg: invalid option -- a >>> mkimg: error: unknown option >>>=20 >>> usage: mkimg >>> options: >>> --formats - list image formats >>> --schemes - list partition schemes >>> --version - show version information >>>=20 >>> -b - file containing boot code >>> -c - capacity (in bytes) of the disk >>> -f >>> -o - file to write image into >>> -p >>> -s >>> -v - increase verbosity >>> -y - [developers] enable unit test >>> -H - number of heads to simulate >>> -P - physical sector size >>> -S - logical sector size >>> -T - number of tracks to simulate >>>=20 >>> formats: >>> qcow - QEMU Copy-On-Write, version 1 >>> qcow2 - QEMU Copy-On-Write, version 2 >>> raw - Raw Disk >>> vhd - Virtual Hard Disk >>> vhdf - Fixed Virtual Hard Disk >>> vmdk - Virtual Machine Disk >>>=20 >>> schemes: >>> apm - Apple Partition Map >>> bsd - BSD disk label >>> ebr - Extended Boot Record >>> gpt - GUID Partition Table >>> mbr - Master Boot Record >>> pc98 - PC-9800 disk partitions >>> vtoc8 - SMI VTOC8 disk labels >>>=20 >>> Is the "-a" flag attempting to set the active partition? It appears >>> there's no option to do that in mkimg... >> Install a newer mkimg: >>=20 >> Revision 307550 - (view) (download) (annotate) - [select for diffs] https://svnweb.freebsd.org/base/?pathrev=3D312669 = shows that -r3125699 is from head. Looking around: stable/11 has not been updated for its mkimg. only head has -a added at this point. >> Modified Tue Oct 18 05:43:12 2016 UTC (3 months, 2 weeks ago) by imp >> File length: 3730 byte(s) >> Diff to previous 307544 >>=20 >> Add a new flag to mkimg (-a num) to specify the active partition for >> those partitioning schemes that have this concept. Implement it as an >> override for mbr's setting 0x80 in the flags for the first partition >> when we have boot code. >>=20 >> Differential Revision: https://reviews.freebsd.org/D4403 >>=20 >> Though maybe I should try to add it to the bootstrap tools so I can >> use a new one after the build. >>=20 >> Warner >>=20 > root@NewFS:/disk/karl # uname -v > FreeBSD 11.0-STABLE #15 r312669M: Mon Jan 23 14:01:03 CST 2017 =20 https://svnweb.freebsd.org/base/?pathrev=3D312669 = shows that -r3125699 is from head, not from stable/11 . If you have a mix of head and stable/11 materials with mkimg from stable/11 then -a will not be present for mkimg. > karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP > root@NewFS:/disk/karl # which mkimg > /usr/bin/mkimg > root@NewFS:/disk/karl # pkg install mkimg > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > pkg: No packages available to install matching 'mkimg' have been found > in the repositories > root@NewFS:/disk/karl # >=20 > So.... it's part of base and there is no obvious package (a check for > ports in */*mkimg* fails too); my system is current as of Jan 23.... >=20 > (As an aside I think if I remove the -a it may work on the Pi, since = the > Pi will try to boot the first partition which happens to be DOS -- I > think. I'll try it.) >=20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ =3D=3D=3D Mark Millard markmi at dsl-only.net