From owner-freebsd-arm@freebsd.org Mon Oct 2 06:25:37 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 2FE6AE37875 for ; Mon, 2 Oct 2017 06:25:37 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (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 08A2A80EF3 for ; Mon, 2 Oct 2017 06:25:36 +0000 (UTC) (envelope-from noname.esst@yahoo.com) X-YMail-OSG: HX_3W9wVM1k6Wx5lreNFAHjqnrm7R42fe7s5xZJXP1nBuXY5DMAiO4U2quB4UbM nsDLsaUOltJ6S8bg5MaHd8j2rQI30XC2eRBAr0bepYOSd.uJalF7nSqxSbFyK6UK1RHF35pYBfka A0glf6UMwAZ3Zj_0SzC3ygeeUn0o6mbC4fEBh6FxqO2zpLSGXMe1SGRA9pvlk9S0mgeemezNU0Dc 4bWrEl_VbOsFX1ncHM3P3en0OpJ4tNYu9L87fcpNkNxKRo4M9nmvvtokMtZNaEL4OXLOP_B0dV0P v0SiNzYlrvO_cThhXEro4E4_4._RNy50q1Tr2EFRIvvOt7XwwmNmaHdyipB4yAtyTImrFLkHKHZX BMv7NIy6KFpDkYfBx6gPRPHreHKLq0A5A6B6aGZqIbwH.A4HiWc6mLuoJ3pVzhOr9cucJ1ty5RYB NfdgvtEUh7t8C1pEWjNACjtOxEbz2b0CwaQZo0VCREKOUmsq3jMqz80lTRg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 Oct 2017 06:25:30 +0000 Date: Mon, 2 Oct 2017 06:25:28 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: Warner Losh Cc: Emmanuel Vadot , Nomad Esst via freebsd-arm Message-ID: <1994395790.1688580.1506925528882@mail.yahoo.com> In-Reply-To: References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> <1825224273.10951257.1506590142784@mail.yahoo.com> Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t MIME-Version: 1.0 X-Mailer: WebService/1.1.10653 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 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: Mon, 02 Oct 2017 06:25:37 -0000 Hello Emmanuel Thanks for your previous answers. I was trying to update the u-boot, but I = couldn't do the job. As you said "You could try updating u-boot to use the u-boot-master port (whichcurrentl= y track the 2017.07 version of U-Boot)." Please tell me how can I do this job? How can I update u-boot. Thanks in advance. On Thursday, September 28, 2017 1:05 PM, Warner Losh w= rote: =20 =20 On Thu, Sep 28, 2017 at 3:15 AM, Nomad Esst via freebsd-arm wrote: Thank you EmmanuelI'm trying to install u-boot-master according to the inst= ruction mentioned in Fresh ports:=C2=A0 #cd /usr/ports/sysutils/u-boot- master/ && make install clean But I don't have this directory! I tried to install it using pkg install: #pkg install sysutils/u-boot-master But I get this error: Updating FreeBSD repository catalogue...FreeBSD repository is up to date.Al= l repositories are up to date.pkg: No packages available to install matchin= g 'sysutils/u-boot-master' have been found in the repositories Please help me solve this.=C2=A0 Thanks in advance=C2=A0 u-boot-master isn't a port that you install. It's just the place that you u= pdate when you want to change the u-boot version. You'd have to change it t= o point to the upstream version of u-boot rather than our repo, though, and= that might start to get tricky.... Warner=C2=A0 =C2=A0 =C2=A0 On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot wrote: =C2=A0On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) Nomad Esst via freebsd-arm wrote: > Hello allI have created an image using Crochet build tool for my BPi M3 b= oard. I have burnt it on it's on-board 4GB EMMC. When I try to boot the boa= rd, I get the following error: > > U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not res= pond to voltage select!Could not determine boot source > resetting ... > What should I do? > Thanks in advance. =C2=A0Our U-Boot is probably not recent enough to support the eMMC. A83T support is not really great even in Linux or U-Boot. =C2=A0You could try updating u-boot to use the u-boot-master port (which curently track the 2017.07 version of U-Boot). -- Emmanuel Vadot ______________________________ _________________ 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" =20 From owner-freebsd-arm@freebsd.org Mon Oct 2 13:47:52 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 A26FBE3FF4D for ; Mon, 2 Oct 2017 13:47:52 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 70B256934F for ; Mon, 2 Oct 2017 13:47:51 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id z0ymdJ7zDhqwcz0yod669n; Mon, 02 Oct 2017 13:41:55 +0000 Received: from [192.168.1.100] (presario [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id v92DgoWH082677 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 2 Oct 2017 09:42:51 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host presario [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org To: freebsd-arm@freebsd.org From: Thomas Laus Subject: BeagleBone Crochet Build Problem Message-ID: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> Date: Mon, 2 Oct 2017 09:42:50 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfArPxxzLxZsT6cbtdEZwBxypx2up68WnyFE//3bCiOw1hieN0WzhFHfZplXaB4qYCOwhgf0P8m5Ldxj7RaNV7Pq/zpBQ2e+ZX2Dg/ZgCEKQDCIwuJ4RI 2iy7LzDWZKhavC6yRqyaWMcKQsLTeRuy1CWVg31rXnhmuKRrgpYCLz/Y 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, 02 Oct 2017 13:47:52 -0000 I updated my build server today to r323984 and performed a 'git pull' on the Crochet files for my BeagleBone Black. The build process stopped because of a missing file: removed pre-existing mount directory; creating new one. Installing U-Boot from: /usr/local/share/u-boot/u-boot-beaglebone :327:10: fatal error: '/usr/src/sys/boot/fdt/dts/beaglebone.dts' file not found #include "/usr/src/sys/boot/fdt/dts/beaglebone.dts" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Error: Expected /dts-v1/; version string Error: Failed to find root node /. Failed to parse tree. Failed to mmap file: Invalid argument I looked in the directory that was referenced in the error and confirmed the missing file. I also upgraded all of my packages today on my build server before starting the Crochet build for Beaglebone. My U-Boot Beaglebone is at version 2017.07.00.1 which (from portsnap) appears to be the most recent. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-arm@freebsd.org Mon Oct 2 14:20:54 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 15199E40768 for ; Mon, 2 Oct 2017 14:20:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 EE02A6A1B1 for ; Mon, 2 Oct 2017 14:20:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e88494cb-a77c-11e7-a937-4f970e858fdb 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.ore.mailhop.org (Halon) with ESMTPSA id e88494cb-a77c-11e7-a937-4f970e858fdb; Mon, 02 Oct 2017 14:20:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v92EKop7003515; Mon, 2 Oct 2017 08:20:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506954050.22078.55.camel@freebsd.org> Subject: Re: BeagleBone Crochet Build Problem From: Ian Lepore To: lausts@acm.org, freebsd-arm@freebsd.org Date: Mon, 02 Oct 2017 08:20:50 -0600 In-Reply-To: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> 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: Mon, 02 Oct 2017 14:20:54 -0000 On Mon, 2017-10-02 at 09:42 -0400, Thomas Laus wrote: > I updated my build server today to r323984 and performed a 'git pull' > on > the Crochet files for my BeagleBone Black.  The build process stopped > because of a missing file: > > removed pre-existing mount directory; creating new one. > Installing U-Boot from: /usr/local/share/u-boot/u-boot-beaglebone > :327:10: fatal error: > '/usr/src/sys/boot/fdt/dts/beaglebone.dts' file >       not found > #include "/usr/src/sys/boot/fdt/dts/beaglebone.dts" >          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. > Error: Expected /dts-v1/; version string > Error: Failed to find root node /. > Failed to parse tree. > Failed to mmap file: Invalid argument > > I looked in the directory that was referenced in the error and > confirmed > the missing file.  I also upgraded all of my packages today on my > build > server before starting the Crochet build for Beaglebone.  My U-Boot > Beaglebone is at version 2017.07.00.1 which (from portsnap) appears > to > be the most recent. > > Tom > I'm not a crochet user, so I can't address that directly, but the basic problem is that crochet shouldn't be trying to build the dtb file from the dts source at all anymore.  The dtb files needed for various beaglebone systems are all built now by sys/modules/dtb/am335x.  This happened when we switched to using vendor-supplied dts files some time ago.  The filenames also changed at that time, but the latest uboot packages should be looking for the new names. -- Ian From owner-freebsd-arm@freebsd.org Mon Oct 2 16:11: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 92A69E0D6C7 for ; Mon, 2 Oct 2017 16:11:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 1ADCA6D563; Mon, 2 Oct 2017 16:11:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id b127so6614077lfe.9; Mon, 02 Oct 2017 09:11:42 -0700 (PDT) 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=BdmL75X1HtQp1bOnPrCeVTmiwE/ZD0X/FWA1adeh4rA=; b=b+jVPx31Zvh69xdsUjJAHPZRvw7IjXvbKklGu/KrGbaQR2fzUldebj0UX+vHe1hf6V 3S7haoNFgmXxMJqEKGUL8Fi+vZcXEyIYGoJTwfKAbrGzBxtFvrhGgOy80utxmUZuQvXM 06UsFm93wjDAZe4vCx5Aouc0fNbPQlvRTKnjxRKh2nGb22RNx8LARe0P1n4+6H1sXYyn CXbkqoi217/jjsuVIt8kJphsfIuCRmjs6gtlhMOr7QznXHYL6NhgG/XH1smq5HyPW//5 wD7w2qaYOSYqIRo5vZrbDozBs8J0dvJEMoQBDgkvrJ0zN3lWFqjAH4fOY2vGuQ2u3Fmv De4w== 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=BdmL75X1HtQp1bOnPrCeVTmiwE/ZD0X/FWA1adeh4rA=; b=jIZu+ugHIeOggIdtfQNAiSA9ngG734oFp7HLEAdZiUgBdeA3edPzzIWRA2s2AygHFv PuEjhPFypm8CRBtglFA2OD/Cvi3swmpJw8Kii2y3RFe2P6a3WLh7655RwxLR+AN4C8J9 xJvIsmfEqo70KYEPEKEytMqmS8JKYj2500mQ9hRI3+3WQmuVJTqKgvtVR+QZjVLpv/de yFhQe8UKg3/308u9UGh6WZ6FilQJehqpFpq6yZLSJ2Py62HPCvbqBxb2WIUbwtg1JjOs kE2OtXa8ZWIRzXp9WZATh0uaMThe7kItp03Pl3PEpzcsfx9OpiB53fjERFVX0mLOsZPP fslQ== X-Gm-Message-State: AHPjjUhv7tGDwMP3yTVgpR5xhkckTEk3U+dtMbBCkvn5mS2HsI/3LABK iKdbe0lA1UrPMCVa/FSAVwK7KisGDBX6j3AVNRprqg== X-Google-Smtp-Source: AOwi7QArd8bDYG1yzejmAuVhOhBJghxUMAEN/5emjJ9+oFfxuV8glThQxCbR9qTcEctRD0RLiAU/qpUgyXmT8abYEtU= X-Received: by 10.46.29.5 with SMTP id d5mr6966065ljd.97.1506960699964; Mon, 02 Oct 2017 09:11:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Mon, 2 Oct 2017 09:11:39 -0700 (PDT) In-Reply-To: <1506954050.22078.55.camel@freebsd.org> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> From: Russell Haley Date: Mon, 2 Oct 2017 09:11:39 -0700 Message-ID: Subject: Re: BeagleBone Crochet Build Problem To: Ian Lepore Cc: lausts@acm.org, freebsd-arm 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, 02 Oct 2017 16:11:42 -0000 On Mon, Oct 2, 2017 at 7:20 AM, Ian Lepore wrote: > On Mon, 2017-10-02 at 09:42 -0400, Thomas Laus wrote: >> I updated my build server today to r323984 and performed a 'git pull' >> on >> the Crochet files for my BeagleBone Black. The build process stopped >> because of a missing file: >> >> removed pre-existing mount directory; creating new one. >> Installing U-Boot from: /usr/local/share/u-boot/u-boot-beaglebone >> :327:10: fatal error: >> '/usr/src/sys/boot/fdt/dts/beaglebone.dts' file >> not found >> #include "/usr/src/sys/boot/fdt/dts/beaglebone.dts" >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 1 error generated. >> Error: Expected /dts-v1/; version string >> Error: Failed to find root node /. >> Failed to parse tree. >> Failed to mmap file: Invalid argument >> >> I looked in the directory that was referenced in the error and >> confirmed >> the missing file. I also upgraded all of my packages today on my >> build >> server before starting the Crochet build for Beaglebone. My U-Boot >> Beaglebone is at version 2017.07.00.1 which (from portsnap) appears >> to >> be the most recent. >> >> Tom >> > > I'm not a crochet user, so I can't address that directly, but the basic > problem is that crochet shouldn't be trying to build the dtb file from > the dts source at all anymore. The dtb files needed for various > beaglebone systems are all built now by sys/modules/dtb/am335x. This > happened when we switched to using vendor-supplied dts files some time > ago. The filenames also changed at that time, but the latest uboot > packages should be looking for the new names. https://github.com/freebsd/crochet/search?utf8=%E2%9C%93&q=%22%2Fusr%2Fsrc%2Fsys%2Fboot%2Ffdt%2Fdts%2F&type= The offending line? An interesting commit: https://github.com/freebsd/crochet/commit/cf14b342e312ba649dffa0ac4921118da8a1d214 Looks like someone is moving some of the kernel config files over to GENERIC. Is using GENERIC on arm something that is being encouraged by those 'in the know'? Russ > -- Ian > _______________________________________________ > 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 Mon Oct 2 16:17: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 EC922E0D971 for ; Mon, 2 Oct 2017 16:17:39 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 763AE6D959 for ; Mon, 2 Oct 2017 16:17:39 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id c82so2806993lfc.6 for ; Mon, 02 Oct 2017 09:17:39 -0700 (PDT) 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=9qlqAFqbZ9Qs40cqQ+MmgeRyUW3ZYWae0auuZ69b97s=; b=J0YopIRwL9MFA9cgBn+8w5I3YTrbCwqIjscQXirDoBwxYYQe7z0+hOnu3fu4kp5jJk eV4uj6ctQgMI/YUvldV+VlPQU40Qooa6nBMClvdek+58pjnu4Awu4z8/rECRtGs2zC3t aaKr3rC+0MiPeK3WtXxr5g6YmxTrnG7y5rFPTzn4HdjPPHRtwCEMsskzVgL53MQE4BDK 0IR2b/I2E6Db2tnRX7MbZ4B99bTW1smVgIVxGZH5VKF4P5detov7ippZ2kfvVuFck98m nSdaXEC7lcMpSgPzi4acac+niXMb4o+O60sc6WJm1b1O/DPwaeIHYeM+Nuv9e7O+uRM0 6HMA== 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=9qlqAFqbZ9Qs40cqQ+MmgeRyUW3ZYWae0auuZ69b97s=; b=SLpIIt4O715O7wB8B1pYKPuCRMgc72CuQJZtf7DeggdY/7Mt6Ib1/IEO20Tf0DNbFf n7sIvC/Bfk6sjar5FWJ8FZfrx2mDnaHYYfvySiBpNSeROvKYs9xJVUFvE4QkGpYQcOL3 7dbx4PQ7/2Sk94fK9U4jcU/99QUUy9cLgzy9KR5Iw50Ccnm2EBxLkYboWVeOgwdOiXap IOET+hQK+jcjjZTRdDZ43mlvuLiSBoHy2w3BAPnJCdHJPA7yUNwyefoph70ayHmvV5Lp z+2lVK9HqD0r8n7lGQH8MQwmb3AiPjDFKOaMiQFMfWfrG7n/r2rJKLN2G1nLKGyFl+G4 PoQg== X-Gm-Message-State: AMCzsaXggrLHIOdxwHWRclKqpkXkv9b6v54/ZJUAlybELtoLJgxCXGEY iESt+sj1VQ6+MIScbkpPHW4dEGYfuBLdLvVGBWw= X-Google-Smtp-Source: AOwi7QCF1za2Xx4WZfcqX97alz1mXtB9rcvcG9wL57I+znWnIUXDvDpTEosZivXTAAUpzI+IbYZKHKFa3Nql+Osb2lU= X-Received: by 10.25.81.85 with SMTP id f82mr4157968lfb.70.1506961057532; Mon, 02 Oct 2017 09:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Mon, 2 Oct 2017 09:17:36 -0700 (PDT) From: Russell Haley Date: Mon, 2 Oct 2017 09:17:36 -0700 Message-ID: Subject: Crochet not in ports? To: freebsd-arm 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, 02 Oct 2017 16:17:40 -0000 I did a quick search of freshports and didn't see Crochet listed. It is however, maintained on the FreeBSD github repo. Does that make it an 'official' package? Has anyone thought about putting a port together for it? Russ From owner-freebsd-arm@freebsd.org Mon Oct 2 16:24: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 3828EE0DCF5 for ; Mon, 2 Oct 2017 16:24:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FE706DEC3; Mon, 2 Oct 2017 16:24:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 065e5633; Mon, 2 Oct 2017 18:23:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=FCYAEBBZ39U/LsZIyfWuT/s2454=; b=IEyu2YgMU6IAc71uDbcaRqaF+8oO 6pLF5kf7GBpzq8YXCy7XzPHPIOHpOWI9maIp1aWE39Kohy0vxBjf/OlkngaJZjSz ZS1v3Z8aumjjki3KKdV4qGhXKwFf7uHLtLPTrk2jPcWR4w0hefQwCDbcCxfrP+Ra G3tVcVwLi2srFE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=EJudDThS6UWR7JDdnm/68vxq7c9Cr1Il//9uyU2ZpGOhxk55suhzjLTG Ems5ZsrevnbuzLhqtw2uxwn9q5U8WLAbGE4sluzMUby9U0xJsPOQI/T6eE47peMF ucfaKuD3I5vz4BRP/hhf1YnQeZ9/PZ5qAuPE3LDRDQdMZnwKxh0= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e3f6f371 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 2 Oct 2017 18:23:59 +0200 (CEST) Date: Mon, 2 Oct 2017 18:23:55 +0200 From: Emmanuel Vadot To: Ian Lepore Cc: lausts@acm.org, freebsd-arm@freebsd.org Subject: Re: BeagleBone Crochet Build Problem Message-Id: <20171002182355.d6f9a252fcfe48ce2ce2b808@bidouilliste.com> In-Reply-To: <1506954050.22078.55.camel@freebsd.org> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 02 Oct 2017 16:24:10 -0000 On Mon, 02 Oct 2017 08:20:50 -0600 Ian Lepore wrote: > On Mon, 2017-10-02 at 09:42 -0400, Thomas Laus wrote: > > I updated my build server today to r323984 and performed a 'git pull' > > on > > the Crochet files for my BeagleBone Black.=A0=A0The build process stopp= ed > > because of a missing file: > >=20 > > removed pre-existing mount directory; creating new one. > > Installing U-Boot from: /usr/local/share/u-boot/u-boot-beaglebone > > :327:10: fatal error: > > '/usr/src/sys/boot/fdt/dts/beaglebone.dts' file > > =A0=A0=A0=A0=A0=A0not found > > #include "/usr/src/sys/boot/fdt/dts/beaglebone.dts" > > =A0=A0=A0=A0=A0=A0=A0=A0=A0^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 1 error generated. > > Error: Expected /dts-v1/; version string > > Error: Failed to find root node /. > > Failed to parse tree. > > Failed to mmap file: Invalid argument > >=20 > > I looked in the directory that was referenced in the error and > > confirmed > > the missing file.=A0=A0I also upgraded all of my packages today on my > > build > > server before starting the Crochet build for Beaglebone.=A0=A0My U-Boot > > Beaglebone is at version 2017.07.00.1 which (from portsnap) appears > > to > > be the most recent. > >=20 > > Tom > >=20 >=20 > I'm not a crochet user, so I can't address that directly, but the basic > problem is that crochet shouldn't be trying to build the dtb file from > the dts source at all anymore. =A0The dtb files needed for various > beaglebone systems are all built now by sys/modules/dtb/am335x. =A0This > happened when we switched to using vendor-supplied dts files some time > ago. =A0The filenames also changed at that time, but the latest uboot > packages should be looking for the new names. >=20 > -- Ian Yes, also the modules install links for compatibility with older u-boot that still have our custom dtb name in it. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Oct 2 16:51: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 6AF42E0E70A for ; Mon, 2 Oct 2017 16:51:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (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 1855C6EE7D for ; Mon, 2 Oct 2017 16:51:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 24EAB5C2289 for ; Mon, 2 Oct 2017 16:46:14 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.127.23]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 951295C2454 for ; Mon, 2 Oct 2017 16:46:13 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.55.158]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Mon, 02 Oct 2017 16:46:14 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Grain-Descriptive: 00546921365556a0_1506962773995_3664556356 X-MC-Loop-Signature: 1506962773995:3199701644 X-MC-Ingress-Time: 1506962773995 X-MHO-User: 30d54b90-a791-11e7-a893-25625093991c 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 30d54b90-a791-11e7-a893-25625093991c; Mon, 02 Oct 2017 16:46:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v92Gk6WX003772; Mon, 2 Oct 2017 10:46:06 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506962766.22078.69.camel@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) From: Ian Lepore To: Russell Haley Cc: freebsd-arm Date: Mon, 02 Oct 2017 10:46:06 -0600 In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> 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: 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: Mon, 02 Oct 2017 16:51:55 -0000 On Mon, 2017-10-02 at 09:11 -0700, Russell Haley wrote: > [...] >=20 > Looks like someone is moving some of the kernel config files over to > GENERIC. Is using GENERIC on arm something that is being encouraged by > those 'in the know'? >=20 > Russ >=20 I keep asking (on irc mostly) and not getting any answer to: Why are we working towards a GENERIC kernel for arm? =A0Who benefits? =A0What do they get that they don't have now? There seems to be this general impression that a generic kernel is a good thing, or even somehow a required thing. =A0Nobody explains why. I know some anti-answers to the above questions. A GENERIC arm kernel does not reduce the number of different arm images we have to distribute; that still comes out to roughly one- per-board or system or related family of systems, because they still need hardware-specific u-boot. A GENERIC kernel gives worse performance than a per-soc kernel for virtually every soc since we have to compile for the lowest common denominator (things like using software divide on systems that have hardware divide instructions). The x86-world advice of creating your custom kernel config by doing "include GENERIC" then adding "nodevice" and "nooption" statements to turn off what you don't want is a non-starter with an arm GENERIC kernel. =A0You would need sooo many lines of nodevice to turn off soc= - specific stuff for other socs, and also since new socs and drivers are always being added, you'd be endlessly chasing a moving target. Given the above problem with "include GENERIC", and without a per- soc kernel config to start with, there is no practical way to create a future-proof custom kernel config. I'm not, at this point, claiming that these downsides are a reason to avoid working towards GENERIC, but since there are clearly some downsides, it seems like a situation where you want to weigh those against the benefits. =A0If only someone would mention some. -- Ian From owner-freebsd-arm@freebsd.org Mon Oct 2 17:11: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 1216CE0EE38 for ; Mon, 2 Oct 2017 17:11:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 C4D446F4E5 for ; Mon, 2 Oct 2017 17:11:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30027 invoked from network); 2 Oct 2017 17:11:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Oct 2017 17:11:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 02 Oct 2017 13:11:00 -0400 (EDT) Received: (qmail 3064 invoked from network); 2 Oct 2017 17:10:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Oct 2017 17:10:59 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 35A1FEC8BAF; Mon, 2 Oct 2017 10:10:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) From: Mark Millard In-Reply-To: <1506962766.22078.69.camel@freebsd.org> Date: Mon, 2 Oct 2017 10:10:58 -0700 Cc: Russell Haley , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) 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, 02 Oct 2017 17:11:08 -0000 [I'm not arguing against the points or questions: just noting a specific technique for CPU-targeting the built kernel code.] On 2017-Oct-2, at 9:46 AM, Ian Lepore wrote: > On Mon, 2017-10-02 at 09:11 -0700, Russell Haley wrote: >> [...] >> >> Looks like someone is moving some of the kernel config files over to >> GENERIC. Is using GENERIC on arm something that is being encouraged by >> those 'in the know'? >> >> Russ >> > > I keep asking (on irc mostly) and not getting any answer to: > > Why are we working towards a GENERIC kernel for arm? Who benefits? > What do they get that they don't have now? > > There seems to be this general impression that a generic kernel is a > good thing, or even somehow a required thing. Nobody explains why. > > I know some anti-answers to the above questions. > > A GENERIC arm kernel does not reduce the number of different arm > images we have to distribute; that still comes out to roughly one- > per-board or system or related family of systems, because they still > need hardware-specific u-boot. > > A GENERIC kernel gives worse performance than a per-soc kernel for > virtually every soc since we have to compile for the lowest common > denominator (things like using software divide on systems that have > hardware divide instructions). I use src.conf files for CPU targeting, for both native and cross building. For example (cross build): # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host TO_TYPE=aarch64 TOOLS_TO_TYPE=${TO_TYPE} # KERNCONF=GENERIC-NODBG TARGET=arm64 .if ${.MAKE.LEVEL} == 0 TARGET_ARCH=${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER= WITHOUT_SYSTEM_COMPILER= # WITH_LIBCPLUSPLUS= WITHOUT_BINUTILS_BOOTSTRAP= WITH_ELFTOOLCHAIN_BOOTSTRAP= WITH_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EXTRAS= WITH_LLD_BOOTSTRAP= WITH_LLD= WITH_LLD_IS_LD= WITH_LLDB= # WITH_BOOT= WITHOUT_LIB32= # 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-a53 XCXXFLAGS+= -mcpu=cortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. And for native I used the CFLAGS.clang notation: # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host TO_TYPE=aarch64 TOOLS_TO_TYPE=${TO_TYPE} # KERNCONF=GENERIC-NODBG TARGET=arm64 .if ${.MAKE.LEVEL} == 0 TARGET_ARCH=${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER= WITH_SYSTEM_COMPILER= # #CPUTYPE=soft WITH_LIBCPLUSPLUS= WITHOUT_BINUTILS_BOOTSTRAP= WITH_ELFTOOLCHAIN_BOOTSTRAP= #WITHOUT_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EXTRAS= WITH_LLD_BOOTSTRAP= WITH_LLD= WITH_LLD_IS_LD= WITH_LLDB= # WITH_BOOT= WITHOUT_LIB32= # WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= WITHOUT_GCC_IS_CC= WITHOUT_GNUCXX= # NO_WERROR= #WERROR= MALLOC_PRODUCTION= # WITH_REPRODUCIBLE_BUILD= WITH_DEBUG_FILES= # # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?= usage. CFLAGS.clang+= -mcpu=cortex-a53 CXXFLAGS.clang+= -mcpu=cortex-a53 CPPFLAGS.clang+= -mcpu=cortex-a53 > The x86-world advice of creating your custom kernel config by doing > "include GENERIC" then adding "nodevice" and "nooption" statements > to turn off what you don't want is a non-starter with an arm GENERIC > kernel. You would need sooo many lines of nodevice to turn off soc- > specific stuff for other socs, and also since new socs and drivers > are always being added, you'd be endlessly chasing a moving target. > > Given the above problem with "include GENERIC", and without a per- > soc kernel config to start with, there is no practical way to create > a future-proof custom kernel config. > > I'm not, at this point, claiming that these downsides are a reason to > avoid working towards GENERIC, but since there are clearly some > downsides, it seems like a situation where you want to weigh those > against the benefits. If only someone would mention some. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Oct 2 18:46:29 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 5F38CE24737 for ; Mon, 2 Oct 2017 18:46:29 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::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 D60E8732CF; Mon, 2 Oct 2017 18:46:28 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id l196so7099746lfl.1; Mon, 02 Oct 2017 11:46:28 -0700 (PDT) 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=nySPwasTyZmCnRUd7aV9MBmZn5PvLtm5gjqXZFtL1/4=; b=eTHki1C+u+EaFzDqxzNpEJYM8SO9dnw/PSSGvBdm3yS0BQGODadjdpcSYq5uT8lbAD KHylGolzgC51R26t+HEj6+4+Yeq709zh1oQcO9ZABhUJliSwSJ5HWqQxCZx5qu9znpaG w0fQK1t5gvaLijs3pUlbMgfsfIf78O8Q2zFL5YSvemc6fo/5P00Fc7u8UXtpqjNCeGXQ pNi+GTyWqX7/VjhfL/3OQoIz5nQ6fi9qYHo2ypulMSRP6CGAwN7i+u1ZbY9rKJkWFoAL ssxEcyeoivwJhf6MS6DBVFZ+VECtlXcka1XXmWiLzC87laacUq0IH8ARyvkdP1j6xvUB f5Hg== 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=nySPwasTyZmCnRUd7aV9MBmZn5PvLtm5gjqXZFtL1/4=; b=g2mvmA0QaribN3dky5z9xO8eTjjBLMzDsVw8mRqqtZrqjll/TlygQ5DnCXLGQgZAtl xvZ0sBhlvmxp2EHM4eHNAb2ZTciaSqHrRayhZWDYp90130vjodQo5DiY3su0SbJmlSTA 7oiMpmdUlVg9Fz1HYmILhmqnRKiPPE9KcgJVO95VZGPrKpsbXI6RI7+vhvToMe54/AeW kZ7YWbpYKlLYcnaIpvHvvYnnKtyFs3vgR/OfEKsqUZeUM6ZFXeTiDXLJNlUC73HBZSqh 1QqhqQfaqvatF0dbh233jGD7c54Qx41//bUQYr/769czPSHP8gU+RLslOJQJ7x7pfqZf Y0Ng== X-Gm-Message-State: AMCzsaWJfWR56uTu4FElwNANRs7gkwYxvY5vGdchpjCv8pbyIl+HxgX5 uduUk4ru31MX6UiIa80slkHP8fSWFETmhs+xgso= X-Google-Smtp-Source: AOwi7QB7cFgGh/g+2uGSols8AClvYP7vjkwFZ6QUCu17RCYvEsE58/3vAQFSRBsGM4p/QOMrujPXqNAVKpRqNS7shFQ= X-Received: by 10.25.26.18 with SMTP id a18mr4519887lfa.200.1506969987041; Mon, 02 Oct 2017 11:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Mon, 2 Oct 2017 11:46:26 -0700 (PDT) In-Reply-To: <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net> From: Russell Haley Date: Mon, 2 Oct 2017 11:46:26 -0700 Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: Mark Millard Cc: Ian Lepore , freebsd-arm 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, 02 Oct 2017 18:46:29 -0000 On Mon, Oct 2, 2017 at 10:10 AM, Mark Millard wrote: > [I'm not arguing against the points or questions: > just noting a specific technique for CPU-targeting > the built kernel code.] > > On 2017-Oct-2, at 9:46 AM, Ian Lepore wrote: > >> On Mon, 2017-10-02 at 09:11 -0700, Russell Haley wrote: >>> [...] >>> >>> Looks like someone is moving some of the kernel config files over to >>> GENERIC. Is using GENERIC on arm something that is being encouraged by >>> those 'in the know'? >>> >>> Russ >>> >> >> I keep asking (on irc mostly) and not getting any answer to: >> >> Why are we working towards a GENERIC kernel for arm? Who benefits? >> What do they get that they don't have now? >> >> There seems to be this general impression that a generic kernel is a >> good thing, or even somehow a required thing. Nobody explains why. >> >> I know some anti-answers to the above questions. >> >> A GENERIC arm kernel does not reduce the number of different arm >> images we have to distribute; that still comes out to roughly one- >> per-board or system or related family of systems, because they still >> need hardware-specific u-boot. >> >> A GENERIC kernel gives worse performance than a per-soc kernel for >> virtually every soc since we have to compile for the lowest common >> denominator (things like using software divide on systems that have >> hardware divide instructions). > > I use src.conf files for CPU targeting, for both native and cross > building. For example (cross build): > > # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host > TO_TYPE=aarch64 > TOOLS_TO_TYPE=${TO_TYPE} > # > KERNCONF=GENERIC-NODBG > TARGET=arm64 > .if ${.MAKE.LEVEL} == 0 > TARGET_ARCH=${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER= > WITHOUT_SYSTEM_COMPILER= > # > WITH_LIBCPLUSPLUS= > WITHOUT_BINUTILS_BOOTSTRAP= > WITH_ELFTOOLCHAIN_BOOTSTRAP= > WITH_CLANG_BOOTSTRAP= > WITH_CLANG= > WITH_CLANG_IS_CC= > WITH_CLANG_FULL= > WITH_CLANG_EXTRAS= > WITH_LLD_BOOTSTRAP= > WITH_LLD= > WITH_LLD_IS_LD= > WITH_LLDB= > # > WITH_BOOT= > WITHOUT_LIB32= > # > 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-a53 > XCXXFLAGS+= -mcpu=cortex-a53 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > > > And for native I used the CFLAGS.clang notation: > > # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host > TO_TYPE=aarch64 > TOOLS_TO_TYPE=${TO_TYPE} > # > KERNCONF=GENERIC-NODBG > TARGET=arm64 > .if ${.MAKE.LEVEL} == 0 > TARGET_ARCH=${TO_TYPE} > .export TARGET_ARCH > .endif > # > #WITH_CROSS_COMPILER= > WITH_SYSTEM_COMPILER= > # > #CPUTYPE=soft > WITH_LIBCPLUSPLUS= > WITHOUT_BINUTILS_BOOTSTRAP= > WITH_ELFTOOLCHAIN_BOOTSTRAP= > #WITHOUT_CLANG_BOOTSTRAP= > WITH_CLANG= > WITH_CLANG_IS_CC= > WITH_CLANG_FULL= > WITH_CLANG_EXTRAS= > WITH_LLD_BOOTSTRAP= > WITH_LLD= > WITH_LLD_IS_LD= > WITH_LLDB= > # > WITH_BOOT= > WITHOUT_LIB32= > # > WITHOUT_GCC_BOOTSTRAP= > WITHOUT_GCC= > WITHOUT_GCC_IS_CC= > WITHOUT_GNUCXX= > # > NO_WERROR= > #WERROR= > MALLOC_PRODUCTION= > # > WITH_REPRODUCIBLE_BUILD= > WITH_DEBUG_FILES= > # > # Use of the .clang 's here avoids > # interfering with other CFLAGS > # usage, such as ?= usage. > CFLAGS.clang+= -mcpu=cortex-a53 > CXXFLAGS.clang+= -mcpu=cortex-a53 > CPPFLAGS.clang+= -mcpu=cortex-a53 > > >> The x86-world advice of creating your custom kernel config by doing >> "include GENERIC" then adding "nodevice" and "nooption" statements >> to turn off what you don't want is a non-starter with an arm GENERIC >> kernel. You would need sooo many lines of nodevice to turn off soc- >> specific stuff for other socs, and also since new socs and drivers >> are always being added, you'd be endlessly chasing a moving target. >> >> Given the above problem with "include GENERIC", and without a per- >> soc kernel config to start with, there is no practical way to create >> a future-proof custom kernel config. >> >> I'm not, at this point, claiming that these downsides are a reason to >> avoid working towards GENERIC, but since there are clearly some >> downsides, it seems like a situation where you want to weigh those >> against the benefits. If only someone would mention some. > > > === > Mark Millard > markmi at dsl-only.net What advantage do does this confer to your testing? Russ From owner-freebsd-arm@freebsd.org Mon Oct 2 19:50:38 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 56E84E26096 for ; Mon, 2 Oct 2017 19:50:38 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 CC6907549F for ; Mon, 2 Oct 2017 19:50:37 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id p184so7024752lfe.12 for ; Mon, 02 Oct 2017 12:50:37 -0700 (PDT) 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=j8wlZQJd2hk3ryYKjseI4vRDZSDf4OBUecSXqylgErE=; b=vE50woFPsUjInvXeO/JqUyLjXYPE59REIk/85bykdbOTyvg8S9kaa5MHyacooYdyCY qS4TfqMUu1Vkx14WZQCzY4vr1bY1KJiPjkncZxjKbfS+Yah1yf/h25E+89qi4fPeGRa3 aAucmoHOm2rc2nWAq5thJW2G41Xq47umU/s+NA+SdkVD9B8MgK9woi0oc7o0ZfHc9idl ksDYj8JpAuGoMA2/IYdLRTddyewpFkJJKv7L/kNtdbd6q/PKkciE/LCkNXM2who0Qh8y 5mDxBM9OpVlrrwKfIt7BA3vZozJC75PJtsnsFqxuHF8LxhzbSdljbJkXbcJTGsk5K3// gc3Q== 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=j8wlZQJd2hk3ryYKjseI4vRDZSDf4OBUecSXqylgErE=; b=iMBfv+vkyb5/hxnLpttmgVabksuQoF9Bc5MNA/Du+GlcF9ool/rRVp9R6HKHKBTwTI gfuo3uNzK1gwT+xTeFjBZFChyQC5YxnM3IjCb5SHftf9UIyc3/Iye/SI00ln/sX/ZBV0 qA4I8541VfEjDwoqvrhcxce4ymh1alaSkeoRigr0dJMeY3NyyV99R2w+gMw30O71Dk/Z zbzaqEZv/a0V+eR4A7XTPCHCxASqlUXXI9CNYKXn5bJgaxIIt7ZYu8n38OklzAEO81qN wRCMx8e7lZaz3jcAafDAZM/Yg2C33DjolS8TQ1z1Etat7T+B42l98MVKWgjocKULpnvp BUXg== X-Gm-Message-State: AHPjjUhINMONwFu3FyhpDdqawSmgj7j0N6r6lriPRpEtrCYlU2TYCar2 H5erEZGWJRF58h3XzWNs6f3yXEjwAnvM22cmHXo= X-Google-Smtp-Source: AOwi7QAa90byj2AZbp7YH7jKyfbER1tW5gIsFhAKG/m1CezzMXisxClg+oboL/wkZlTOO1AZPTxG3mUCGXoqxMlGnAg= X-Received: by 10.25.202.12 with SMTP id a12mr4637020lfg.54.1506973836083; Mon, 02 Oct 2017 12:50:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Mon, 2 Oct 2017 12:50:35 -0700 (PDT) In-Reply-To: <1994395790.1688580.1506925528882@mail.yahoo.com> References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> <1825224273.10951257.1506590142784@mail.yahoo.com> <1994395790.1688580.1506925528882@mail.yahoo.com> From: Russell Haley Date: Mon, 2 Oct 2017 12:50:35 -0700 Message-ID: Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t To: Nomad Esst Cc: Warner Losh , Nomad Esst via 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: Mon, 02 Oct 2017 19:50:38 -0000 On Sun, Oct 1, 2017 at 11:25 PM, Nomad Esst via freebsd-arm wrote: > Hello Emmanuel > Thanks for your previous answers. I was trying to update the u-boot, but = I couldn't do the job. As you said > > "You could try updating u-boot to use the u-boot-master port (whichcurren= tly track the 2017.07 version of U-Boot)." > Please tell me how can I do this job? How can I update u-boot. > Thanks in advance. * First, I want to point out that if your u-boot is on the emmc, then emmc support in u-boot "works fine". The output (from u-boot!) is complaining about an MibCard with 2048 bytes of something, which would be your ram. That means u-boot SPL loaded and a default value for the hardware settings may be incorrect. So, if I were looking into this, I would pull ports from subversion and create a directory under my home directory. I would then go into the u-boot-bananapi2 port and examine the make file for details. I went ahead and looked at https://svnweb.freebsd.org/ports/head/sysutils/ (*note that svnweb pages the output. The page control is at the top of the screen and the u-boot ports are on the second page.) I opened the banana pi port and the makefile points to the u-boot-master makefile. In u-boot-master, the line that dictates the u-boot version pulled from Github is on line 67 UBOOT_VERSION?=3D 2017.07.00.1 Since we pull from Github.com, perhaps you can try a couple of things: - Remove the line altogether and build u-boot. That *should* just pull the head revision (good thing, bad thing? not sure). I am not sure how you will check what revision was pulled and built - Point it to a version that you know has the support you need If you were wanting to do a little more than update u-boot and hope, I would say you need to find the name of the board configuration directory and check the default settings. Das u-boot doesn't use DTS does it? It should be in the board specific source code if I had to guess. I looked briefly at the u-boot/board directory on Gituhub and I don't see any support for allwinner or bananna pi's but I don't know what I'm looking for. I can't run the config step here to look at the list of supported boards. If you run the configure script (or the make) and then look at boards.cfg (or something like that), it will tell you what support is available and point you to the right /board/ directory. You may also want to look at the linux-sunxi gitub repo as they have support for development boards that may not have made it back into u-boot head. Please if someone knows better, let me know cause I'm learning as I go! HTH, Russ > > > On Thursday, September 28, 2017 1:05 PM, Warner Losh = wrote: > > > > > On Thu, Sep 28, 2017 at 3:15 AM, Nomad Esst via freebsd-arm wrote: > > Thank you EmmanuelI'm trying to install u-boot-master according to the in= struction mentioned in Fresh ports: > > #cd /usr/ports/sysutils/u-boot- master/ && make install clean > > But I don't have this directory! I tried to install it using pkg install: > > #pkg install sysutils/u-boot-master > > But I get this error: > > Updating FreeBSD repository catalogue...FreeBSD repository is up to date.= All repositories are up to date.pkg: No packages available to install match= ing 'sysutils/u-boot-master' have been found in the repositories > Please help me solve this. > Thanks in advance > > u-boot-master isn't a port that you install. It's just the place that you= update when you want to change the u-boot version. You'd have to change it= to point to the upstream version of u-boot rather than our repo, though, a= nd that might start to get tricky.... > Warner > On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot wrote: > > > On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) > Nomad Esst via freebsd-arm wrote: > >> Hello allI have created an image using Crochet build tool for my BPi M3 = board. I have burnt it on it's on-board 4GB EMMC. When I try to boot the bo= ard, I get the following error: >> >> U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not re= spond to voltage select!Could not determine boot source >> resetting ... >> What should I do? >> Thanks in advance. > > Our U-Boot is probably not recent enough to support the eMMC. A83T > support is not really great even in Linux or U-Boot. > > You could try updating u-boot to use the u-boot-master port (which > curently track the 2017.07 version of U-Boot). > > -- > Emmanuel Vadot > > > > ______________________________ _________________ > 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" > > > > > _______________________________________________ > 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 Mon Oct 2 20:04:54 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 730C4E2691E; Mon, 2 Oct 2017 20:04:54 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C5126761B0; Mon, 2 Oct 2017 20:04:52 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id efa712e1; Mon, 2 Oct 2017 22:04:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=QUN/rx 4joh6VbbYfaslaRCYJiwA=; b=Rp1aNAknAf2ZkboBbIoWhOGoANN/RmOaH+IduM Q0w6/1hcljNoUqAKbotZa02SToRLgxTGYk+3/t7mveM/4n0fy62UM5rTAc/6MIXa S1oGwz/aChT9oDBPypr5fpyj5E8Tv/Iv45c6RXLEcB7HaN6tsleIdbYn1m4f4jEQ KAQHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= Uic8iOxfmoo/WH4/y3UMCAaHDut9XtIpxoI/iIPUG5tQiSaXsyzKvi44lLrvRGBy 2pVINKwgBFWim4CS38reywKYFyMrvyHidsT/tPBow2mr8tFx8zAzttVB+ksV3e35 ixkj5i4IEHsVJbJ5qeqwbm8IAq0y0J41nFT+mQvhth0= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id dbd6c57f; Mon, 2 Oct 2017 22:04:49 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 Oct 2017 22:04:49 +0200 From: Emmanuel Vadot To: Russell Haley Cc: Nomad Esst , Nomad Esst via freebsd-arm , owner-freebsd-arm@freebsd.org Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t Organization: Bidouilliste In-Reply-To: References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> <1825224273.10951257.1506590142784@mail.yahoo.com> <1994395790.1688580.1506925528882@mail.yahoo.com> Message-ID: <7430cca44b8e3e14660a74ef9a1c2189@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 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, 02 Oct 2017 20:04:54 -0000 On 2017-10-02 21:50, Russell Haley wrote: > On Sun, Oct 1, 2017 at 11:25 PM, Nomad Esst via freebsd-arm > wrote: >> Hello Emmanuel >> Thanks for your previous answers. I was trying to update the u-boot, >> but I couldn't do the job. As you said >> >> "You could try updating u-boot to use the u-boot-master port >> (whichcurrently track the 2017.07 version of U-Boot)." >> Please tell me how can I do this job? How can I update u-boot. >> Thanks in advance. > > * First, I want to point out that if your u-boot is on the emmc, then > emmc support in u-boot "works fine". The output (from u-boot!) is > complaining about an MibCard with 2048 bytes of something, which would > be your ram. That means u-boot SPL loaded and a default value for the > hardware settings may be incorrect. No this is just newlines have been striped out of the email. U-Boot report 2048 MiB of ram and then that Card didn't respond. > So, if I were looking into this, I would pull ports from subversion > and create a directory under my home directory. I would then go into > the u-boot-bananapi2 port and examine the make file for details. > > I went ahead and looked at > https://svnweb.freebsd.org/ports/head/sysutils/ (*note that svnweb > pages the output. The page control is at the top of the screen and the > u-boot ports are on the second page.) > > I opened the banana pi port and the makefile points to the > u-boot-master makefile. In u-boot-master, the line that dictates the > u-boot version pulled from Github is on line 67 > UBOOT_VERSION?= 2017.07.00.1 > > Since we pull from Github.com, perhaps you can try a couple of things: > - Remove the line altogether and build u-boot. That *should* just pull > the head revision (good thing, bad thing? not sure). I am not sure how > you will check what revision was pulled and built Bad idea, this will not have the FreeBSD needed patches. > - Point it to a version that you know has the support you need > > If you were wanting to do a little more than update u-boot and hope, I > would say you need to find the name of the board configuration > directory and check the default settings. Das u-boot doesn't use DTS > does it? It should be in the board specific source code if I had to > guess. It depends, sometimes it uses DTS sometimes it just embed them. For allwinner (sunxi) it doesn't use them. > I looked briefly at the u-boot/board directory on Gituhub and I don't > see any support for allwinner or bananna pi's but I don't know what > I'm looking for. I can't run the config step here to look at the list > of supported boards. If you run the configure script (or the make) > and then look at boards.cfg (or something like that), it will tell you > what support is available and point you to the right /board/ > directory. In U-Boot (and Linux mainline) it's called sunxi. > You may also want to look at the linux-sunxi gitub repo as they have > support for development boards that may not have made it back into > u-boot head. No, everything is in u-boot mainline, and if it's not running u-boot from linux-sunxi will not help as it's tracking old u-boot with patches from Allwinner company. > Please if someone knows better, let me know cause I'm learning as I go! > HTH, > > Russ > >> >> >> On Thursday, September 28, 2017 1:05 PM, Warner Losh >> wrote: >> >> >> >> >> On Thu, Sep 28, 2017 at 3:15 AM, Nomad Esst via freebsd-arm >> wrote: >> >> Thank you EmmanuelI'm trying to install u-boot-master according to the >> instruction mentioned in Fresh ports: >> >> #cd /usr/ports/sysutils/u-boot- master/ && make install clean >> >> But I don't have this directory! I tried to install it using pkg >> install: >> >> #pkg install sysutils/u-boot-master >> >> But I get this error: >> >> Updating FreeBSD repository catalogue...FreeBSD repository is up to >> date.All repositories are up to date.pkg: No packages available to >> install matching 'sysutils/u-boot-master' have been found in the >> repositories >> Please help me solve this. >> Thanks in advance >> >> u-boot-master isn't a port that you install. It's just the place that >> you update when you want to change the u-boot version. You'd have to >> change it to point to the upstream version of u-boot rather than our >> repo, though, and that might start to get tricky.... >> Warner >> On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot >> wrote: >> >> >> On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) >> Nomad Esst via freebsd-arm wrote: >> >>> Hello allI have created an image using Crochet build tool for my BPi >>> M3 board. I have burnt it on it's on-board 4GB EMMC. When I try to >>> boot the board, I get the following error: >>> >>> U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did not >>> respond to voltage select!Could not determine boot source >>> resetting ... >>> What should I do? >>> Thanks in advance. >> >> Our U-Boot is probably not recent enough to support the eMMC. A83T >> support is not really great even in Linux or U-Boot. >> >> You could try updating u-boot to use the u-boot-master port (which >> curently track the 2017.07 version of U-Boot). >> >> -- >> Emmanuel Vadot >> >> >> >> ______________________________ _________________ >> 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" >> >> >> >> >> _______________________________________________ >> 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" > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Oct 2 20:07:04 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 45ED6E26A05 for ; Mon, 2 Oct 2017 20:07:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC555762CC for ; Mon, 2 Oct 2017 20:07:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 21b08ada; Mon, 2 Oct 2017 22:06:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=FePTE0 +CbE2c1HStH/KWqSwid98=; b=UKvuUsXy6Qvs2VrjD+caqdEHmepVP7+lg/XA8Y BLuiOYRHeAFACzgsYSMrcPp+7egzxLxEjQ9DCvZKAkWWYWe6kdT+u6bQa8Fm3zzC TdjCkAUf2olZx9F9DuKu/i4/zXueUzXktIYH6wWaQN05GNi9rd+qKkaJMbJ6PVuG jj3X4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= d8S8ckIv9im9otwed+q62qJ4tWcdYSdQFlBnoj9MePAPdR0RAWSBljcAnfdFtxPz OoljXovPxg95rDAPgeeIyc44QsLQmgQHSmpA5f5m7anFpdvKNdGspU83XX2Wsojy bM/KGomGeA+YzIMcpth/gt3FRh+6vAwNCJ/7WoZjKnI= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id b88b3af1; Mon, 2 Oct 2017 22:06:59 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 02 Oct 2017 22:06:59 +0200 From: Emmanuel Vadot To: Nomad Esst Cc: Warner Losh , Nomad Esst via freebsd-arm Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t Organization: Bidouilliste In-Reply-To: <1994395790.1688580.1506925528882@mail.yahoo.com> References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> <1825224273.10951257.1506590142784@mail.yahoo.com> <1994395790.1688580.1506925528882@mail.yahoo.com> Message-ID: <95e3e8f6e237205ba76be308c9313533@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 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, 02 Oct 2017 20:07:04 -0000 On 2017-10-02 08:25, Nomad Esst wrote: > Hello Emmanuel > Thanks for your previous answers. I was trying to update the u-boot, > but I couldn't do the job. As you said > > "You could try updating u-boot to use the u-boot-master port (which > currently track the 2017.07 version of U-Boot)." > > Please tell me how can I do this job? How can I update u-boot. > > Thanks in advance. Just take some Allwinner ports makefile (like u-boot-bananapi) and change BOARD_CONFIG to match the config file in u-boot. > On Thursday, September 28, 2017 1:05 PM, Warner Losh > wrote: > > On Thu, Sep 28, 2017 at 3:15 AM, Nomad Esst via freebsd-arm > wrote: > >> Thank you EmmanuelI'm trying to install u-boot-master according to >> the instruction mentioned in Fresh ports: >> >> #cd /usr/ports/sysutils/u-boot- master/ && make install clean >> >> But I don't have this directory! I tried to install it using pkg >> install: >> >> #pkg install sysutils/u-boot-master >> >> But I get this error: >> >> Updating FreeBSD repository catalogue...FreeBSD repository is up to >> date.All repositories are up to date.pkg: No packages available to >> install matching 'sysutils/u-boot-master' have been found in the >> repositories >> Please help me solve this. >> Thanks in advance > > u-boot-master isn't a port that you install. It's just the place that > you update when you want to change the u-boot version. You'd have to > change it to point to the upstream version of u-boot rather than our > repo, though, and that might start to get tricky.... > > Warner > >> On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot >> wrote: >> >> On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) >> Nomad Esst via freebsd-arm wrote: >> >>> Hello allI have created an image using Crochet build tool for my >> BPi M3 board. I have burnt it on it's on-board 4GB EMMC. When I try >> to boot the board, I get the following error: >>> >>> U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did >> not respond to voltage select!Could not determine boot source >>> resetting ... >>> What should I do? >>> Thanks in advance. >> >> Our U-Boot is probably not recent enough to support the eMMC. A83T >> support is not really great even in Linux or U-Boot. >> >> You could try updating u-boot to use the u-boot-master port (which >> curently track the 2017.07 version of U-Boot). >> >> -- >> Emmanuel Vadot >> >> ______________________________ _________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/ mailman/listinfo/freebsd-arm [1] >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@ >> freebsd.org" > > > > Links: > ------ > [1] https://lists.freebsd.org/mailman/listinfo/freebsd-arm -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Oct 2 21:48: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 5525EE28714 for ; Mon, 2 Oct 2017 21:48:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-29.reflexion.net [208.70.210.29]) (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 118BA7CCAF for ; Mon, 2 Oct 2017 21:48:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23109 invoked from network); 2 Oct 2017 21:42:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Oct 2017 21:42:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 02 Oct 2017 17:42:00 -0400 (EDT) Received: (qmail 8426 invoked from network); 2 Oct 2017 21:41:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Oct 2017 21:41:59 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B003EC9390; Mon, 2 Oct 2017 14:41:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) From: Mark Millard In-Reply-To: Date: Mon, 2 Oct 2017 14:41:58 -0700 Cc: Ian Lepore , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net> To: Russell Haley X-Mailer: Apple Mail (2.3273) 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, 02 Oct 2017 21:48:42 -0000 On 2017-Oct-2, at 11:46 AM, Russell Haley wrote: > On Mon, Oct 2, 2017 at 10:10 AM, Mark Millard wrote: >> [I'm not arguing against the points or questions: >> just noting a specific technique for CPU-targeting >> the built kernel code.] >> >> On 2017-Oct-2, at 9:46 AM, Ian Lepore wrote: >> >>> . . . >>> A GENERIC kernel gives worse performance than a per-soc kernel for >>> virtually every soc since we have to compile for the lowest common >>> denominator (things like using software divide on systems that have >>> hardware divide instructions). >> >> I use src.conf files for CPU targeting, for both native and cross >> building. For example (cross build): >> >> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host >> TO_TYPE=aarch64 >> TOOLS_TO_TYPE=${TO_TYPE} >> # >> KERNCONF=GENERIC-NODBG >> TARGET=arm64 >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER= >> WITHOUT_SYSTEM_COMPILER= >> # >> WITH_LIBCPLUSPLUS= >> WITHOUT_BINUTILS_BOOTSTRAP= >> WITH_ELFTOOLCHAIN_BOOTSTRAP= >> WITH_CLANG_BOOTSTRAP= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_CLANG_EXTRAS= >> WITH_LLD_BOOTSTRAP= >> WITH_LLD= >> WITH_LLD_IS_LD= >> WITH_LLDB= >> # >> WITH_BOOT= >> WITHOUT_LIB32= >> # >> 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-a53 >> XCXXFLAGS+= -mcpu=cortex-a53 >> # There is no XCPPFLAGS but XCPP gets XCFLAGS content. >> >> >> And for native I used the CFLAGS.clang notation: >> >> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host >> TO_TYPE=aarch64 >> TOOLS_TO_TYPE=${TO_TYPE} >> # >> KERNCONF=GENERIC-NODBG >> TARGET=arm64 >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER= >> WITH_SYSTEM_COMPILER= >> # >> #CPUTYPE=soft >> WITH_LIBCPLUSPLUS= >> WITHOUT_BINUTILS_BOOTSTRAP= >> WITH_ELFTOOLCHAIN_BOOTSTRAP= >> #WITHOUT_CLANG_BOOTSTRAP= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_CLANG_EXTRAS= >> WITH_LLD_BOOTSTRAP= >> WITH_LLD= >> WITH_LLD_IS_LD= >> WITH_LLDB= >> # >> WITH_BOOT= >> WITHOUT_LIB32= >> # >> WITHOUT_GCC_BOOTSTRAP= >> WITHOUT_GCC= >> WITHOUT_GCC_IS_CC= >> WITHOUT_GNUCXX= >> # >> NO_WERROR= >> #WERROR= >> MALLOC_PRODUCTION= >> # >> WITH_REPRODUCIBLE_BUILD= >> WITH_DEBUG_FILES= >> # >> # Use of the .clang 's here avoids >> # interfering with other CFLAGS >> # usage, such as ?= usage. >> CFLAGS.clang+= -mcpu=cortex-a53 >> CXXFLAGS.clang+= -mcpu=cortex-a53 >> CPPFLAGS.clang+= -mcpu=cortex-a53 >> >> >> . . . >> >> === >> Mark Millard >> markmi at dsl-only.net > > What advantage do does this confer to your testing? My use is personal-interest use. I've no reason to bother disabling things from GENERIC: I include GENERIC and override to produce non-debug. (That is a head/ example, not stable/ or release/ or releng/ .) But I also have no reason to have the kernel's machine code portable across various subfamilies. On the lower power, lower performance types of hardware that I have access to I bias towards tailoring to the CPU type. (I do not have access to any BIG.little configurations were code common to the mix might be important. But to my knowledge FreeBSD does not support any BIG.little combinations anyway.) [There was an occasion where my use of -mcpu helped identify/confirm a point/presumption that need not hold. But I'm not the only one that does such tailoring.] I normally do not use the snapshots or releases. I do not bias the builds for old PowerMac's to match CPU details for what I have access to (beyond powerpc64 vs. powerpc that is already involved). As for why I wrote about it: the CPU type for kernel builds can be controlled outside the kernel-config files, at least within a family: For armv6 the GENERIC kernel configuration files already indicate the more generic armv7 classification. I just pick a more specific member of the family. aarch64 has a similar status. I would not try to step outside a family with the src.conf way of specifying CPUs. (Something that I probably should have mentioned in the original message.) Also: I'd guess that Ian builds kernels rather than using the "standard" ones. It was his text that I was replying to. He likely knew anyway but his note might leave a misimpression about alternatives for that specific issue. It is one thing to have GENERIC span some of the small, low power SOC's and boards. It is another to have only GENERIC for them. (But for my use GENERIC-based is fine so I do not have an example that would drive the FreeBSD choice on the issue.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Oct 3 02:10: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 472F1E2D568 for ; Tue, 3 Oct 2017 02:10:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-28.reflexion.net [208.70.210.28]) (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 EA02483FDA for ; Tue, 3 Oct 2017 02:10:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21083 invoked from network); 3 Oct 2017 02:10:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Oct 2017 02:10:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 02 Oct 2017 22:10:36 -0400 (EDT) Received: (qmail 2206 invoked from network); 3 Oct 2017 02:10:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Oct 2017 02:10:36 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 03010EC9411; Mon, 2 Oct 2017 19:10:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324207 - head/sys/arm64/arm64 Message-Id: Date: Mon, 2 Oct 2017 19:10:35 -0700 To: andrew@freebsd.org, svn-src-head@freebsd.org, freebsd-arm X-Mailer: Apple Mail (2.3273) 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, 03 Oct 2017 02:10:39 -0000 > Author: andrew > Date: Mon Oct 2 14:22:35 2017 > New Revision: 324207 > URL:=20 > https://svnweb.freebsd.org/changeset/base/324207 >=20 >=20 > Log: > Add a memory barrier to ensure the atomic write is visible to the = other > CPUs before waking them up. > =20 > Sponsored by: DARPA, AFRL >=20 > Modified: > head/sys/arm64/arm64/mp_machdep.c >=20 > Modified: head/sys/arm64/arm64/mp_machdep.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/arm64/arm64/mp_machdep.c Mon Oct 2 14:19:31 2017 = (r324206) > +++ head/sys/arm64/arm64/mp_machdep.c Mon Oct 2 14:22:35 2017 = (r324207) > @@ -236,7 +236,10 @@ release_aps(void *dummy __unused) > =20 > atomic_store_rel_int(&aps_ready, 1); > /* Wake up the other CPUs */ > - __asm __volatile("sev"); > + __asm __volatile( > + "dsb ishst \n" > + "sev \n" > + ::: "memory"); > =20 > printf("Release APs\n"); There is another sev instruction without a prior memory barrier: Index: /usr/src/sys/arm64/arm64/identcpu.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm64/arm64/identcpu.c (revision 323676) +++ /usr/src/sys/arm64/arm64/identcpu.c (working copy) @@ -1109,6 +1109,9 @@ =20 /* Wake up the other CPUs */ atomic_store_rel_int(&ident_lock, 0); - __asm __volatile("sev" ::: "memory"); + __asm __volatile( + "dsb ish \n" + "sev \n" + ::: "memory"); } } (No claim that the dsb form is optimal. Arm documentation says that they recommend every sev be preceded by a dsb and I picked ish to experiment with.) See comments and extra attachment in bugzilla 222234 (which you have fixed with your change). [Specifically your change should make non-debug kernels boot Pine64+ 2GB's again. (I had used just "dsb ish" get get such to boot.)] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Oct 3 06:44: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 E6287E32B74 for ; Tue, 3 Oct 2017 06:44:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 699FD67104 for ; Tue, 3 Oct 2017 06:44:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id l196so8510629lfl.1 for ; Mon, 02 Oct 2017 23:44:42 -0700 (PDT) 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=RduBCKXtdmroG2bQiLrIBd6ijx9CJkd6/pHZroWqI5c=; b=EQnhoW/MZmf1rNy7tdJea8peIJhoUt5EWMje42vZk5TcJ93w6j3c7DLJySyXT9RD3q 3TkivshW5qEmKu/uYMh+TJs8rgBHE1Zivpoc9ge1YjFPsdL69T/m9xb6R7zFC+ltsT1A nPK44i34ArB3mo4641XKxEBWuTAvEmQxJLq1Fx8NfygqZ1aVrxTNEat8ZGD549mnVUGQ kDT/AR3Kf5uQ6LwXt08kYIsHKRpBpMfc5r5wcQX64Y5dFLVJfYHff2TnKHixgDEtUf1i NcDWDhvhCd97khy7L0nKe9lZubTmrZPWyiBRdV27rWJEAdb0EzaTDarr5/hfFb2Ibdun ZEMQ== 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=RduBCKXtdmroG2bQiLrIBd6ijx9CJkd6/pHZroWqI5c=; b=SJ2jnPd2on3PEpRcT1nj5GDZ23qa8h9/Wacb4VeEKBXGXui9kNTsd6yZNoTU9JqUgm qFrxF5eNXb7ewadPrcfa/hDFyIuUeBfdtIXTC3eIasOw0MPPsfjFKjlQLirTJzZCNlBX SEUNYlvp5+Jbmlom7kbTcSnNuJ6cagYZSdToaBtmDcI38zGthW16GCj13JBEldU/Tzvk qJZmQV1J3YfiU1ifRwwlf4a1/2kfmPITGjfsQG12Em9tiLM0e9INQffTKZ4MlUaXzoLu /s78Qn4ovmQ91jMORIr0O6nyvjyFuDn7uKafrFtsnO+KPd2+7vemXfYiX3L/T2AZ86kB D0tA== X-Gm-Message-State: AHPjjUjjCacyDw3XIToMZe52gj4spO/j/j1a/6I+j8CEyi1Tb3E0HmoL 2RL4JZ9p9+guT4AwTI7aBae5G7PG+/5YIMif3BY= X-Google-Smtp-Source: AOwi7QB+iA7sFrh3uRXSR17D0/170AdrArTjTA0j+k3jmL4ReitY0LR50HjbZfbwH+fRQUe7wW9MwXJMP6dd3dOw97Q= X-Received: by 10.25.100.18 with SMTP id y18mr4821908lfb.257.1507013080251; Mon, 02 Oct 2017 23:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Mon, 2 Oct 2017 23:44:39 -0700 (PDT) In-Reply-To: <95e3e8f6e237205ba76be308c9313533@megadrive.org> References: <312104517.10213240.1506511560284.ref@mail.yahoo.com> <312104517.10213240.1506511560284@mail.yahoo.com> <20170927161819.6e36cd53a76f9e75b782a3b3@bidouilliste.com> <1825224273.10951257.1506590142784@mail.yahoo.com> <1994395790.1688580.1506925528882@mail.yahoo.com> <95e3e8f6e237205ba76be308c9313533@megadrive.org> From: Russell Haley Date: Mon, 2 Oct 2017 23:44:39 -0700 Message-ID: Subject: Re: FreeBSD 11 on Banana-Pi M3 A83t To: Emmanuel Vadot Cc: Nomad Esst , Nomad Esst via freebsd-arm 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: Tue, 03 Oct 2017 06:44:43 -0000 On Mon, Oct 2, 2017 at 1:06 PM, Emmanuel Vadot wrote: > On 2017-10-02 08:25, Nomad Esst wrote: >> >> Hello Emmanuel >> Thanks for your previous answers. I was trying to update the u-boot, >> but I couldn't do the job. As you said >> >> "You could try updating u-boot to use the u-boot-master port (which >> currently track the 2017.07 version of U-Boot)." >> >> Please tell me how can I do this job? How can I update u-boot. >> >> Thanks in advance. > > > Just take some Allwinner ports makefile (like u-boot-bananapi) and change > BOARD_CONFIG to match the config file in u-boot. So after a TON of digging that seemed unnecessary, I found that our u-boot has support for that board. Mainline u-boot has had some form of support since Jan 2016. If you change the Makefile in u-boot-bananapim2 to have BOARD_CONFIG= Sinovoip_BPI_M3_defconfig and then run make it should build the right support. HTH, Russ >> On Thursday, September 28, 2017 1:05 PM, Warner Losh >> wrote: >> >> On Thu, Sep 28, 2017 at 3:15 AM, Nomad Esst via freebsd-arm >> wrote: >> >>> Thank you EmmanuelI'm trying to install u-boot-master according to >>> the instruction mentioned in Fresh ports: >>> >>> #cd /usr/ports/sysutils/u-boot- master/ && make install clean >>> >>> But I don't have this directory! I tried to install it using pkg >>> install: >>> >>> #pkg install sysutils/u-boot-master >>> >>> But I get this error: >>> >>> Updating FreeBSD repository catalogue...FreeBSD repository is up to >>> date.All repositories are up to date.pkg: No packages available to >>> install matching 'sysutils/u-boot-master' have been found in the >>> repositories >>> Please help me solve this. >>> Thanks in advance >> >> >> u-boot-master isn't a port that you install. It's just the place that >> you update when you want to change the u-boot version. You'd have to >> change it to point to the upstream version of u-boot rather than our >> repo, though, and that might start to get tricky.... >> >> Warner >> >>> On Wednesday, September 27, 2017 5:48 PM, Emmanuel Vadot >>> wrote: >>> >>> On Wed, 27 Sep 2017 11:26:00 +0000 (UTC) >>> Nomad Esst via freebsd-arm wrote: >>> >>>> Hello allI have created an image using Crochet build tool for my >>> >>> BPi M3 board. I have burnt it on it's on-board 4GB EMMC. When I try >>> to boot the board, I get the following error: >>>> >>>> >>>> U-Boot SPL 2016.05 (Aug 13 2017 - 05:07:01)DRAM: 2048 MiBCard did >>> >>> not respond to voltage select!Could not determine boot source >>>> >>>> resetting ... >>>> What should I do? >>>> Thanks in advance. >>> >>> >>> Our U-Boot is probably not recent enough to support the eMMC. A83T >>> support is not really great even in Linux or U-Boot. >>> >>> You could try updating u-boot to use the u-boot-master port (which >>> curently track the 2017.07 version of U-Boot). >>> >>> -- >>> Emmanuel Vadot >>> >>> ______________________________ _________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/ mailman/listinfo/freebsd-arm [1] >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@ >>> freebsd.org" >> >> >> >> >> Links: >> ------ >> [1] https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > -- > Emmanuel Vadot > _______________________________________________ > 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 Oct 3 09:26:04 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 DC88DE36BD3 for ; Tue, 3 Oct 2017 09:26:04 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41EED6C65C for ; Tue, 3 Oct 2017 09:26:03 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.72.205]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MbPPQ-1dik163RC8-00Iiui; Tue, 03 Oct 2017 11:26:00 +0200 Date: Tue, 3 Oct 2017 11:25:54 +0200 From: "O. Hartmann" To: Russell Haley Cc: freebsd-arm Subject: Re: Crochet not in ports? Message-ID: <20171003112554.3ceb18b1@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/V9K1gTY0i1Lwone9WIgwjvW"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:ZRzxEkLda0pKA53RR6bOl7740+TRisdlncfC8sErNlBJqUqeU8t 1DSc3t6foDHD3qbPaSyPdMx+K9cHKcweS+Jdp6tYQfG9Cb/DA1u7I+QcGgjH04kYnP+cIUr VVIWfLcITCZGlipZmVWXQm3nYBBAHQTxKe3ozWnti93A4HmrMCiPRSPW7yh12/8pXxi2vFf 7lccS4OMIQtwzmGVOO2Gw== X-UI-Out-Filterresults: notjunk:1;V01:K0:45vJGlnCc9U=:BOj4/oRvZvWgMaPK/IY5xr 7XlvvTMc9+F/IhTWeNr76Frdr6FzQRs4NZgVDf4DpfvkmRA82f1zTP7TquGF21ae+wHhPJFoO bFEP+P7EyiaVcc25QWjvXrD6qFcOkwHXyMGTKrayMBM+umfCr4Z/jENTvsMCWrXaR5M8ub97Y DOelzRqzE2LjamZ9u09i2ckn7OAlhKr8q5AnWzE/bbauc95poN9BDIIDr75lSFeRyaQ7uANAP BdBqRAX9H8PS04MwVlH+MdVZD3Tyng94vte9U5+Gu1+7SS+GO1S5haaSs3nmizvNcvIZixteU av8G2EZGuXi45quHoliljn5Pq6SJpL6kKXZQ0aTKnW4nbMHjsIjybADYv8apBBVE2rZABFywV dagf70XjGMVYuEXx5IZhTkRIKociM42FZNVAyLYr3cEfs8zrn47Q71cs3/FNxCh0S9vFLGE+5 8gg3XQZ72SF0Wk3WXZOZTDiHf8yg2Hv/RZTgSQW2AQNZcoynfTDWcvoKfxykpnQ4jpHx9aY0r 0w0SayfCu6bqI7iABkYE+EDTnp6Uql8ahzBrqo/aGUpOM5961xAFTRNPxvVImqTXR8Hydg/d3 VNbeP3QJowhpD7tEGx9EMQq7SeGqJ4lHuD3y9kLnyeWmrlHCueplmeFXUfRvuTWb4rOGhqljb aIQOQeor7y1TxbJW+cfzeW84yoynKLFMJfdxHIRj60j/QGXrPspLG2T4iKFVuuLumuVoa9Df6 lKVCpBe67XjcrXIa5cTpso2SjfwTxxd9fJU4eKCDL/SeePKYDUBFlh2OnuYsrWpxBi159ifmf 4yjSIcrUFEmpsSKCv3Boa+mViqIqw== 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, 03 Oct 2017 09:26:05 -0000 --Sig_/V9K1gTY0i1Lwone9WIgwjvW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mon, 2 Oct 2017 09:17:36 -0700 Russell Haley schrieb: > I did a quick search of freshports and didn't see Crochet listed. It > is however, maintained on the FreeBSD github repo. Does that make it > an 'official' package? Has anyone thought about putting a port > together for it? >=20 > Russ I'd also appreciate having a port of Crochet. Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/V9K1gTY0i1Lwone9WIgwjvW Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdNXogAKCRDS528fyFhY lL6wAf42MYr2pdFZMqKQT5Lm9/lCRWpRLrH1Qvdledj9ggYyKDyFLMpSK7SXUhLS BOzSLcnbBAdcnLiTeLCYSVB3HyXuAf4sm+/iIBlBc/L/QrR7tGazmI+ZFhwEkxFe s1/AckDtO3t5y11cd83bwKWt5KkWG3eqyWmjh2+HQlnPoJDsOitS =GAJE -----END PGP SIGNATURE----- --Sig_/V9K1gTY0i1Lwone9WIgwjvW-- From owner-freebsd-arm@freebsd.org Tue Oct 3 11:27: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 21EC9E39513 for ; Tue, 3 Oct 2017 11:27:50 +0000 (UTC) (envelope-from hrabanek@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 AA8656FE1A for ; Tue, 3 Oct 2017 11:27:49 +0000 (UTC) (envelope-from hrabanek@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id i124so16151167wmf.3 for ; Tue, 03 Oct 2017 04:27:49 -0700 (PDT) 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; bh=WzGQd3f/3zgyGHeYWnRwwm/QRPjiBx5TsbLYlZNB378=; b=jQoRP0mwAin1jKL/Ge+IrGgiZf44WGsOvvXmytajmvwaHDYjRtkg5DkisiFK/uuCtC 3ZcRb+0fTNfOJvyRJ7ljBQvsA1k5ZkRUkrHQmkPVIGDZjFWfUyXmreJqDteNb6DSwMzR /4QqB+bJ+qjP3DUC3BmzUDqdI+gfL3MbZmo93Oo6sfaq3W5527Bt9Ff6hGAl8e31lY0U Aundm08ey1F/r/ZMA01D7LPA4Qv/4nq290wVdNd7n9SArHsp9cpFM/dZyHD7WzwKncT4 KSiFzL/qvzkT9Gvuj3CdOX72TMTQ1QMzQ+ra2zbEPN8qk2uuxIfrMeJbMHnTT8OnoZDv Icow== 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; bh=WzGQd3f/3zgyGHeYWnRwwm/QRPjiBx5TsbLYlZNB378=; b=h3/Ld3QTlwlXhJnr0iylSM9NLfiUclXjQsjwkGSiAKxrjcoIY6h+INS/4XggCga/Dk k1j4MQHa6Fis57297dEZoTPCHIVbz0xkk2Mx4aZbIMi8jxsvd0O2UcDrdYY/0sYOWnBM 4GEUI6dUu58DezXmLWtmv9HpMKQqP9OmYxXo6PexC4lk7p9udUuc1il/dnhqcOnJ6iUh ICRV7Vic6L4sw0irxYJBIc8a2QszMXRw2SJHcfk1aGJtUTiXZsMCpi+BXbitoINWrPhP D8o9aKlPVUwQwXxA4R6GNeVpNZ7XtFcUkemQJkCCuGLpxWOjH0ZlgCh6q5vZp8BskbNW KUqQ== X-Gm-Message-State: AHPjjUhPv+ZZGvmB9elWqoLgNT1fz9y4sV6MiQSHFetDXOVLLVmorRAs H8VSZ5d7DeoS+xnfhRXjx2MT7Fjl0SD1ljTSA75T/g== X-Google-Smtp-Source: AOwi7QDbcsgaOxZ/GEfLv/u7ObVfeaNErTBGIsmvyCl9mGiZC4EMGadhjM+pwVn1PM9NBBiI6a5beNZArq4MgmDU4YE= X-Received: by 10.80.221.197 with SMTP id x5mr22981142edk.166.1507030068228; Tue, 03 Oct 2017 04:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.183.98 with HTTP; Tue, 3 Oct 2017 04:27:47 -0700 (PDT) In-Reply-To: <20170921082259.aa46e554e653ce7bf2d403b2@bidouilliste.com> References: <20170921082259.aa46e554e653ce7bf2d403b2@bidouilliste.com> From: Michael Hrabanek Date: Tue, 3 Oct 2017 13:27:47 +0200 Message-ID: Subject: Re: Allwinner H3 (NanoPi Neo): Getting PORTL (on /dev/gpioc1) to work To: Emmanuel Vadot , 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, 03 Oct 2017 11:27:50 -0000 Hello, any updates? If you'll need any testing done I'd be happy to help Cheers, Michael On Thu, Sep 21, 2017 at 8:22 AM, Emmanuel Vadot wrote: > On Tue, 19 Sep 2017 09:45:22 +0200 > Michael Hrabanek wrote: > > > Hi everybody, > > I'm running 12.0-CURRENT (rev 323710) using GENERIC kernel on NanoPi Neo > > (allwinner H3). I can use and control all gpio pins on /dev/gpioc0 > without > > any issue, but if I try to configure any pin on /dev/gpioc1 (there are > only > > PORTL pins there), nothing happens (pin configuration stays the same, > > gpioctl returns 0 and no error in log). > > > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv > > pin 00: 0 PL0, caps: > > pin 01: 0 PL1, caps: > > pin 02: 0 PL2<>, caps: > > pin 03: 0 PL3<>, caps: > > pin 04: 0 PL4<>, caps: > > pin 05: 0 PL5<>, caps: > > pin 06: 0 PL6<>, caps: > > pin 07: 0 PL7<>, caps: > > pin 08: 0 PL8<>, caps: > > pin 09: 0 PL9<>, caps: > > pin 10: 0 PL10<>, caps: > > pin 11: 0 PL11<>, caps: > > > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -c 10 OUT > > > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv > > <...> > > pin 10: 0 PL10<>, caps: > > pin 11: 0 PL11<>, caps: > > > > Did anyone managed to get pins on PORTL working? (btw there are two LEDs > on > > nanopi neo, the blue one on PA10, which I can control normally and the > > green (pwr) one, wired to PL10, which only slightly dims (ie. pin is not > > configured as output)). > > Any idea what's wrong? Is there an issue with FDT config? (I'm using > > default one from src nanopi-neo.dtb) Or some bug in kernel? I'm not > afraid > > of some kernel hacking, but I'd welcome some pointers where to look > first. > > Any suggestions would be greatly appreciated, > > Michael > > Hello, > > Thanks for reporting, I totally forgot that I needed to do a r_ccu > driver for H3. > The PORTL on H3 lives on another gpio controller, for which it's clock > lives in another clock controller and we miss the driver for the latest. > It also raise a problem on our gpio driver as it shouldn't attach and > create the node while the clocks are missing. > I'll invastigate after EuroBSDCon. > > Cheers, > > -- > Emmanuel Vadot > From owner-freebsd-arm@freebsd.org Tue Oct 3 11: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 37D3BE398FF for ; Tue, 3 Oct 2017 11:39:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BC468705A0 for ; Tue, 3 Oct 2017 11:39:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id dcb46ec4; Tue, 3 Oct 2017 13:39:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=JG5XaUpdaY+Ubu3BTSkCtvIzirI=; b=IFz1oPA6snFG1miXywbvVu6k1KPj dmjSqntDPk/WOSO0utIn/mk5ayum01oSvs7iOknZQ92dkKDqww7OgyoHhe5jUl4s Y8brlm8ACMixPUj5/xHWtHsg0uzmRrJ4J4xqB87P9MuNav+k8hWPwwAPP8/fh+yq cIyQLyqE25v5Qec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=iUPtsRlhn5B8GeoiAN1jZygKNdKcVSf8QjdSokKUnljREab9hnsbYRIN tqfgGcC1ygbTyncr4kxcVNxh0uPCTlVd7wnR6hxwOiTa+hF7uWeehhhWlNM/ksB8 i81iA8c26lCg7eSAqego9FcyAhh77n7LUWX3AKirOtOT6FpttgM= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 505002ca TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 3 Oct 2017 13:39:03 +0200 (CEST) Date: Tue, 3 Oct 2017 13:39:01 +0200 From: Emmanuel Vadot To: Michael Hrabanek Cc: freebsd-arm@freebsd.org Subject: Re: Allwinner H3 (NanoPi Neo): Getting PORTL (on /dev/gpioc1) to work Message-Id: <20171003133901.1de20ce9637720671eee3d33@bidouilliste.com> In-Reply-To: References: <20170921082259.aa46e554e653ce7bf2d403b2@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Tue, 03 Oct 2017 11:39:07 -0000 On Tue, 3 Oct 2017 13:27:47 +0200 Michael Hrabanek wrote: > Hello, > any updates? If you'll need any testing done I'd be happy to help > > Cheers, > Michael I've fixed our gpio driver to not attach if we cannot enable one of the needed clocks. Now I need to code the clock driver for H3, it seems that there is no docs so it will take some time. > On Thu, Sep 21, 2017 at 8:22 AM, Emmanuel Vadot > wrote: > > > On Tue, 19 Sep 2017 09:45:22 +0200 > > Michael Hrabanek wrote: > > > > > Hi everybody, > > > I'm running 12.0-CURRENT (rev 323710) using GENERIC kernel on NanoPi Neo > > > (allwinner H3). I can use and control all gpio pins on /dev/gpioc0 > > without > > > any issue, but if I try to configure any pin on /dev/gpioc1 (there are > > only > > > PORTL pins there), nothing happens (pin configuration stays the same, > > > gpioctl returns 0 and no error in log). > > > > > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv > > > pin 00: 0 PL0, caps: > > > pin 01: 0 PL1, caps: > > > pin 02: 0 PL2<>, caps: > > > pin 03: 0 PL3<>, caps: > > > pin 04: 0 PL4<>, caps: > > > pin 05: 0 PL5<>, caps: > > > pin 06: 0 PL6<>, caps: > > > pin 07: 0 PL7<>, caps: > > > pin 08: 0 PL8<>, caps: > > > pin 09: 0 PL9<>, caps: > > > pin 10: 0 PL10<>, caps: > > > pin 11: 0 PL11<>, caps: > > > > > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -c 10 OUT > > > > > > root@nanopi-neo:~ # gpioctl -f /dev/gpioc1 -lv > > > <...> > > > pin 10: 0 PL10<>, caps: > > > pin 11: 0 PL11<>, caps: > > > > > > Did anyone managed to get pins on PORTL working? (btw there are two LEDs > > on > > > nanopi neo, the blue one on PA10, which I can control normally and the > > > green (pwr) one, wired to PL10, which only slightly dims (ie. pin is not > > > configured as output)). > > > Any idea what's wrong? Is there an issue with FDT config? (I'm using > > > default one from src nanopi-neo.dtb) Or some bug in kernel? I'm not > > afraid > > > of some kernel hacking, but I'd welcome some pointers where to look > > first. > > > Any suggestions would be greatly appreciated, > > > Michael > > > > Hello, > > > > Thanks for reporting, I totally forgot that I needed to do a r_ccu > > driver for H3. > > The PORTL on H3 lives on another gpio controller, for which it's clock > > lives in another clock controller and we miss the driver for the latest. > > It also raise a problem on our gpio driver as it shouldn't attach and > > create the node while the clocks are missing. > > I'll invastigate after EuroBSDCon. > > > > Cheers, > > > > -- > > Emmanuel Vadot > > -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Oct 3 17:00:56 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 1139FE42852 for ; Tue, 3 Oct 2017 17:00:56 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFA6481503; Tue, 3 Oct 2017 17:00:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 57ACCF02; Tue, 3 Oct 2017 12:00:54 -0500 (CDT) Date: Tue, 3 Oct 2017 12:00:53 -0500 From: Mark Linimon To: Ian Lepore Cc: Russell Haley , freebsd-arm Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-ID: <20171003170053.GB2918@lonesome.com> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1506962766.22078.69.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 03 Oct 2017 17:00:56 -0000 On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: > Why are we working towards a GENERIC kernel for arm? My intuition would be: - easier to tell new FreeBSD users how to start - less work for Release Engineering to make targets OTOH I'm not doing the work so I don't get to set the direction :-) My _opinion_ is that we still seem to have a steeper curve for our new users than is necessary. I intend to think about that more this fall. mcl From owner-freebsd-arm@freebsd.org Tue Oct 3 20:03: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 650EEE230F4 for ; Tue, 3 Oct 2017 20:03:32 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta03.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3071B269D for ; Tue, 3 Oct 2017 20:03:31 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id zTPydjCFRZEW5zTQ0ddM6K; Tue, 03 Oct 2017 20:03:53 +0000 Received: from [192.168.1.100] (presario [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id v93K3Lra087029 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 3 Oct 2017 16:03:21 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host presario [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: freebsd-arm@freebsd.org References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> From: Thomas Laus Message-ID: <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> Date: Tue, 3 Oct 2017 16:03:21 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171003170053.GB2918@lonesome.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfO1+XuKuWodBuI916lOuBOMYciydI32QJI+LCHli17JMTVwRe4h3RPWCW1ufmyCFuIO9r4gSvX1E9xihUT3y1pYKz4lRt+aEhdWq+uMzhMCfAXP9DUXf z2PgE3o3R3mTa71r68TJmyUHMHN6K45mO7hJ4GBlXahvaGhBRx/i48Uw 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, 03 Oct 2017 20:03:32 -0000 On 10/03/17 13:00, Mark Linimon wrote: > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: >> Why are we working towards a GENERIC kernel for arm? > > My intuition would be: > > - easier to tell new FreeBSD users how to start > - less work for Release Engineering to make targets > > OTOH I'm not doing the work so I don't get to set the > direction :-) > > My _opinion_ is that we still seem to have a steeper > curve for our new users than is necessary. I intend to > think about that more this fall. > That is probably 'wishful thinking' for the very distant future. Most of the common ARM SOC's have very different capabilities between each other. Each also requires a unique U-Boot partition that gets read before the FreeBSD kernel is loaded. I strongly favor the current approach that has a custom kernel configuration file and U-Boot for each SOC. All of the common ARM systems have a limited amount of real estate to store FreeBSD kernel and base system because it all must fit on a SD memory card. Having a GENERIC kernel that covers all SOC variants would consume flash space that will never be used. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-arm@freebsd.org Tue Oct 3 20:55: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 4D9C7E24605 for ; Tue, 3 Oct 2017 20:55:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 1A504636B1 for ; Tue, 3 Oct 2017 20:55:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x241.google.com with SMTP id e9so5490456iod.5 for ; Tue, 03 Oct 2017 13:55:08 -0700 (PDT) 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=CoVl6DCGUbuSxkWWO0wCkY7AqPBCCBUItCkXA0iSXJo=; b=icOe8naE9c+uDgVjg2stzgfupdU/O1x2P6m4KimHuR/qDjRhrOuJw6b8ck0YuCZRhs Cg6KjCkDmZoMMPnize/4+Xw5vE1rKH1MAaQwd8tNkS9TAVaCYPfMXQXEw8x1LjaQzisB ZjtivmDVMUXDBZX8iANv+0/nxYm7KROPjHvvWZgzm+4NhHyMX5AWsM1fR6+tmIvAnd+J /I2Po+xXoDcBaOfV9HNG3tbPoB3vT2TIfEYi+6ii5pR12H2s4shcx0onGp4R3OXVHoMk LZ/n7w2F1I4xMFcvl0LMiIFzhhnoySEPJ+Z/C6vwl7+thnO9tAqmaaa1bGfiqo9ebA1r mcQg== 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=CoVl6DCGUbuSxkWWO0wCkY7AqPBCCBUItCkXA0iSXJo=; b=S4qY3hO78kyKNUR+XrBEwFc6+d+Na5S8hRKIBwDVEP4an1S6gj9uCC1/ZFHyVhCqR0 QJtaZRwIViQZe0uZDUWoxjhSJfi8pWXMdQI+kemGxCNWJaY+KT20eoTgM81P0QOj0bN4 FfUOcNMpzxaO3xK91ba+AmzGiN2TyGTUgz6aVhPWQI576U54vRWdu/sJZmg32pzICSLd RgLcSkHtfvtyQzQTxnwe7YM//GBW0hgsvobnbYZquhaFlxmjho63TYznQ5JQEqP0N0A3 iHff5JP4cBvM9SdYBtZwaXe+yXl5L6ftyevvj5KpGmbLYfqv8WqdDOPaX8Q7SDF/hcqP D5oA== X-Gm-Message-State: AMCzsaXycY8D490JWfTfONXSUorx2pzor3Euhl2w3leK2df/XkBZuogW ps5vvD6Bof7z8x485fNYPBKrHwCH2M/Ws428JYrQDg== X-Google-Smtp-Source: AOwi7QBWnX7x41MTP5rCk/ttPaoIJYiiK1otcKErMbKciSQyW/YOsqYRpu1oFr+ald9lAUEOwupNo9KtggxUvkBjCsY= X-Received: by 10.107.7.161 with SMTP id g33mr29063795ioi.169.1507064108304; Tue, 03 Oct 2017 13:55:08 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 3 Oct 2017 13:55:07 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::4102] In-Reply-To: <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> From: Warner Losh Date: Tue, 3 Oct 2017 14:55:07 -0600 X-Google-Sender-Auth: K7i800GlfAg7UZ31uaH1GrRqPFU Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: lausts@acm.org 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: Tue, 03 Oct 2017 20:55:09 -0000 On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: > On 10/03/17 13:00, Mark Linimon wrote: > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: > >> Why are we working towards a GENERIC kernel for arm? > > > > My intuition would be: > > > > - easier to tell new FreeBSD users how to start > > - less work for Release Engineering to make targets > > > > OTOH I'm not doing the work so I don't get to set the > > direction :-) > > > > My _opinion_ is that we still seem to have a steeper > > curve for our new users than is necessary. I intend to > > think about that more this fall. > > > That is probably 'wishful thinking' for the very distant future. Most > of the common ARM SOC's have very different capabilities between each > other. Each also requires a unique U-Boot partition that gets read > before the FreeBSD kernel is loaded. > While this is true, how to create them can be described generically. You put these bits in this physical location, or on that partition and away you go. The pre-boot environment is indeed different, but it's highly desirable to have everything after that identical. It ensures uniformity in a highly fragmented segment of our user base. Different kernels, even generated from the same sources, run the risk of being subtly different from each other, leading to less coverage between the boards. We've had issues related to this in the past from time to time. I'm working on a program I'm calling "spin" which will take a description of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) and it will create a bootable image knowing nothing more. If it also has to know which of a bazillion kernels to use, that makes things more complicated. We want more uniformity, not less. Much of the differences we have today are arbitrary (and often wrong). > I strongly favor the current approach that has a custom kernel > configuration file and U-Boot for each SOC. All of the common ARM > systems have a limited amount of real estate to store FreeBSD kernel and > base system because it all must fit on a SD memory card. Having a > GENERIC kernel that covers all SOC variants would consume flash space > that will never be used. Nobody is saying that you can't do this. Just that GENERIC will be the union of all these kernel and be what you get by default. Since nobody has quantified the differences, I'm having trouble getting worked up over the somewhat trivial difference in size (especially compared to most SD cards today). Warner From owner-freebsd-arm@freebsd.org Tue Oct 3 21:07:20 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 51487E24A62 for ; Tue, 3 Oct 2017 21:07:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-28.reflexion.net [208.70.210.28]) (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 0219863E2C for ; Tue, 3 Oct 2017 21:07:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26754 invoked from network); 3 Oct 2017 21:07:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Oct 2017 21:07:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 03 Oct 2017 17:07:18 -0400 (EDT) Received: (qmail 24947 invoked from network); 3 Oct 2017 21:07:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Oct 2017 21:07:17 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1BF74EC8AE5; Tue, 3 Oct 2017 14:07:17 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-Id: Date: Tue, 3 Oct 2017 14:07:16 -0700 To: lausts@acm.org, freebsd-arm X-Mailer: Apple Mail (2.3273) 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, 03 Oct 2017 21:07:20 -0000 Thomas Laus lausts at acm.org wrote on Tue Oct 3 20:03:32 UTC 2017 : > I strongly favor the current approach that has a custom kernel > configuration file and U-Boot for each SOC. (End of quotes from your text. Later ones are from elsewhere.) I do not expect that is the current approach in head any more. Using ALLWINNER as an example: = https://svnweb.freebsd.org/base/head/sys/arm/conf/?sortby=3Drev&sortdir=3D= down#dirlist shows that there is only one ALLWINNER* configuration file: ALLWINNER_UP 320777 2 months andrew Remove the MULTIDELAY = option from arm. It's now enabled when PLATFORM is enabled=E2=80=A6 for uniprocessor ALLWINNER's. ALLWINNER was removed by -r320327 : > Revision 320327 - Directory Listing=20 > Modified Sun Jun 25 11:31:39 2017 UTC (3 months, 1 week ago) by manu > Remove ALLWINNER kernel config file, all release image for SMP = Allwinner > board uses GENERIC and it's not updated for newer SoC. Adding to GENERIC has included removing non-GENERIC in recent times. ALLWINNER might not have been updated for some time before it was removed for all I know. The last update prior to the removal was: > Revision 308405 - (view) (download) (annotate) - [select for diffs]=20 > Modified Mon Nov 7 10:26:44 2016 UTC (10 months, 3 weeks ago) by = andrew=20 > File length: 2994 byte(s)=20 > Diff to previous 305505 > Start to deorbit the kernel configs in GENERIC by marking them with > NO_UNIVERSE. This stops them from being built with the universe, > tinderbox, and related targets. >=20 > Sponsored by: ABT Systems Ltd One of the differences with GENERIC vs. lots of individual kernel configurations set up for full activities is the number of builds in universe, tinderbox, and the like: GENERIC is one build. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Oct 3 22:05:36 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 43B59E25E84 for ; Tue, 3 Oct 2017 22:05:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16: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 2BAE365FC1 for ; Tue, 3 Oct 2017 22:05:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v93M5ZZV050507 for ; Tue, 3 Oct 2017 22:05:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 222511] RPI3 will not boot 2017-09-20 aarch64 FreeBSD 12.0-CURRENT image Date: Tue, 03 Oct 2017 22:05:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: linimon@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 03 Oct 2017 22:05:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222511 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Assignee|freebsd-arm@FreeBSD.org |linimon@FreeBSD.org Resolution|--- |Overcome By Events --- Comment #3 from Mark Linimon --- Release images do indeed have witness disabled. But during the development of the -CURRENT branch -- currently 12 -- it is intentionally left on for debugging purposes. The idea is that anyone using that branch will accept all the disadvantages of being at the 'bleeding edge of development (or, build their own kernel/world, to taste.) Since the initial regression has been fixed I'm going to mark this one as Resolved. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Oct 3 22:10: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 8133DE25F54 for ; Tue, 3 Oct 2017 22:10:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 622F4660ED for ; Tue, 3 Oct 2017 22:10:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a38d33d4-a887-11e7-a937-4f970e858fdb 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.ore.mailhop.org (Halon) with ESMTPSA id a38d33d4-a887-11e7-a937-4f970e858fdb; Tue, 03 Oct 2017 22:10:18 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v93MA9sW002044; Tue, 3 Oct 2017 16:10:09 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507068609.86205.81.camel@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) From: Ian Lepore To: Warner Losh , lausts@acm.org Cc: "freebsd-arm@freebsd.org" Date: Tue, 03 Oct 2017 16:10:09 -0600 In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> 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: Tue, 03 Oct 2017 22:10:13 -0000 On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: > > > > > On 10/03/17 13:00, Mark Linimon wrote: > > > > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: > > > > > > > > Why are we working towards a GENERIC kernel for arm? > > > My intuition would be: > > > > > >  - easier to tell new FreeBSD users how to start > > >  - less work for Release Engineering to make targets > > > > > > OTOH I'm not doing the work so I don't get to set the > > > direction :-) > > > > > > My _opinion_ is that we still seem to have a steeper > > > curve for our new users than is necessary.  I intend to > > > think about that more this fall. > > > > > That is probably 'wishful thinking' for the very distant future.  Most > > of the common ARM SOC's have very different capabilities between each > > other.  Each also requires a unique U-Boot partition that gets read > > before the FreeBSD kernel is loaded. > > > While this is true, how to create them can be described generically. You > put these bits in this physical location, or on that partition and away you > go. The pre-boot environment is indeed different, but it's highly desirable > to have everything after that identical. It ensures uniformity in a highly > fragmented segment of our user base. Different kernels, even generated from > the same sources, run the risk of being subtly different from each other, > leading to less coverage between the boards. We've had issues related to > this in the past from time to time. > > I'm working on a program I'm calling "spin" which will take a description > of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) > and it will create a bootable image knowing nothing more. If it also has to > know which of a bazillion kernels to use, that makes things more > complicated. > > We want more uniformity, not less. Much of the differences we have today > are arbitrary (and often wrong). > > > > > > I strongly favor the current approach that has a custom kernel > > configuration file and U-Boot for each SOC.  All of the common ARM > > systems have a limited amount of real estate to store FreeBSD kernel and > > base system because it all must fit on a SD memory card.  Having a > > GENERIC kernel that covers all SOC variants would consume flash space > > that will never be used. > > Nobody is saying that you can't do this. Just that GENERIC will be the > union of all these kernel and be what you get by default. Since nobody has > quantified the differences, I'm having trouble getting worked up over the > somewhat trivial difference in size (especially compared to most SD cards > today). > > Warner Well, I guess I'll stop pretending there's any chance this freight train can be stopped.  I find the advantages mentioned so far dubious at best, specious at worst, except for the single item "packaged base".  I don't know much about how that stuff is structured, but I can see how having lots of different kernels might be difficult for packaging. But we absolutely have to solve the problem of making it easy for people to create custom kernel configs.  "Include GENERIC and add some nodevice/nooption lines" is just not going to work.  Right now I use "include IMX6" and then some nodevice/nooption lines, and that works fine. So if IMX6 goes away as a standalone buildable config, there needs to be some other thing like it that can be included.  The idea that keeps nudging me is that our GENERIC should look like:   include std.armv6   include std.armdebug   include std.a10   include std.a20   include std.bcm2835   include std.imx6   ... Now anybody can create a custom config by including std.armv6, std.armdebug if they want it, and their soc's std file.  (The std.armdebug is also for re@, so that it's easy for them to adjust when making releases.) The problem is that I'm so backed up with other obbligations and problem reports not getting dealt with and of course $work, so I never find any time to give a scheme like this a try. -- Ian From owner-freebsd-arm@freebsd.org Tue Oct 3 22:56:01 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 6509AE27880 for ; Tue, 3 Oct 2017 22:56:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::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 1AC4F67EC7 for ; Tue, 3 Oct 2017 22:56:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x242.google.com with SMTP id c195so13453930itb.1 for ; Tue, 03 Oct 2017 15:56:01 -0700 (PDT) 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=g8ozVbr01Q11wxrpuznqZ/1GaAku+r9b8t56nkMjw2s=; b=NZ38CftGYvkt36xhdpUE0Q8fAashCCIXEcpNS/dB9zYx1hI/6MiFSH6Gkz9zsRm4EY 0KVWyZPS2aomQtXNk0hbQFsRY8yaDJ32irAFA5Jco3S8tR9QE5n2Jq4w9lY5VSoZsBlY jaWcFLrj89Sdg5ymUX/eMLQu8mvTrCbg+6cQgq/mskEL8ECxJBsjEBiIfgRoqnXcpg2a e3xVVIdc7zXB3B3/MWoTb75s5TbZSOF0cS73ytWuYKKOwX6GGX9gY0E9a9dRlzD8nJMj 7J48GPQGjnfMzJ1YA98EjZuK/1C2lm03Djgdis6OXXIK5J6rguC45CnnG1OEPHNvvffU jAZA== 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=g8ozVbr01Q11wxrpuznqZ/1GaAku+r9b8t56nkMjw2s=; b=txYDxVOH+1ZQv/RLpn7RsThbLzTOEitqDbkj33sx9G4Baa1Eo1lhxOYvE+Q0Aovg5r 9swrv6sYS2UsueSPxZWc9xqEiLQsdAZBSRAs7UPZZd2n/GleAJrNLAyBVrwDRLAMjkDe 67Lqmen6FHwnD2o+NxdLeWL+gh35i0usIkdnNodxCccelG9eiwSKe7gAswRT5O1dHBzN 4hUqdKGNIlgJUI3/W7jUVrCyb0dEW7jIbFPvg0NG4tGNDxH+nzDiIj5rHDGsQdoSW7+A Cob2hj6ZwuKaEw9dE6BiSawwbvDvFO/sqIemofoRR5vk7hnMP0/xcmiVT9s6NMKKQCxZ 9AMw== X-Gm-Message-State: AMCzsaX/5viTCvRhkEUtGW8YIGZTvaBPuj9H9U1fxFAKugnx1Y3aRVSk WQcSMcgBDF2evYSRuP3GO7q7EzZNcNMXofGOIaqktQ== X-Google-Smtp-Source: AOwi7QCYCAmHpSgpbLpri26S+G9M36unvBxMppXvxvWXOGWg6RxPOJq3zakUxiqvZYaOWVxsVeMXWwM+ih/qi8uAzsU= X-Received: by 10.36.203.3 with SMTP id u3mr20500651itg.136.1507071360399; Tue, 03 Oct 2017 15:56:00 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 3 Oct 2017 15:55:59 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::4102] In-Reply-To: <1507068609.86205.81.camel@freebsd.org> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <1507068609.86205.81.camel@freebsd.org> From: Warner Losh Date: Tue, 3 Oct 2017 16:55:59 -0600 X-Google-Sender-Auth: DPH1-0U4CC-4Y1mB2SImphhIW0E Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: Ian Lepore Cc: lausts@acm.org, "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, 03 Oct 2017 22:56:01 -0000 On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore wrote: > On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: > > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: > > > > > > > > On 10/03/17 13:00, Mark Linimon wrote: > > > > > > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: > > > > > > > > > > Why are we working towards a GENERIC kernel for arm? > > > > My intuition would be: > > > > > > > > - easier to tell new FreeBSD users how to start > > > > - less work for Release Engineering to make targets > > > > > > > > OTOH I'm not doing the work so I don't get to set the > > > > direction :-) > > > > > > > > My _opinion_ is that we still seem to have a steeper > > > > curve for our new users than is necessary. I intend to > > > > think about that more this fall. > > > > > > > That is probably 'wishful thinking' for the very distant future. Most > > > of the common ARM SOC's have very different capabilities between each > > > other. Each also requires a unique U-Boot partition that gets read > > > before the FreeBSD kernel is loaded. > > > > > While this is true, how to create them can be described generically. You > > put these bits in this physical location, or on that partition and away > you > > go. The pre-boot environment is indeed different, but it's highly > desirable > > to have everything after that identical. It ensures uniformity in a > highly > > fragmented segment of our user base. Different kernels, even generated > from > > the same sources, run the risk of being subtly different from each other, > > leading to less coverage between the boards. We've had issues related to > > this in the past from time to time. > > > > I'm working on a program I'm calling "spin" which will take a description > > of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) > > and it will create a bootable image knowing nothing more. If it also has > to > > know which of a bazillion kernels to use, that makes things more > > complicated. > > > > We want more uniformity, not less. Much of the differences we have today > > are arbitrary (and often wrong). > > > > > > > > > > I strongly favor the current approach that has a custom kernel > > > configuration file and U-Boot for each SOC. All of the common ARM > > > systems have a limited amount of real estate to store FreeBSD kernel > and > > > base system because it all must fit on a SD memory card. Having a > > > GENERIC kernel that covers all SOC variants would consume flash space > > > that will never be used. > > > > Nobody is saying that you can't do this. Just that GENERIC will be the > > union of all these kernel and be what you get by default. Since nobody > has > > quantified the differences, I'm having trouble getting worked up over the > > somewhat trivial difference in size (especially compared to most SD cards > > today). > > > > Warner > > Well, I guess I'll stop pretending there's any chance this freight > train can be stopped. I find the advantages mentioned so far dubious > at best, specious at worst, except for the single item "packaged base". > I don't know much about how that stuff is structured, but I can see > how having lots of different kernels might be difficult for packaging. > > But we absolutely have to solve the problem of making it easy for > people to create custom kernel configs. "Include GENERIC and add some > nodevice/nooption lines" is just not going to work. Right now I use > "include IMX6" and then some nodevice/nooption lines, and that works > fine. > > So if IMX6 goes away as a standalone buildable config, there needs to > be some other thing like it that can be included. The idea that keeps > nudging me is that our GENERIC should look like: > > include std.armv6 > include std.armdebug > include std.a10 > include std.a20 > include std.bcm2835 > include std.imx6 > ... > > Now anybody can create a custom config by including std.armv6, > std.armdebug if they want it, and their soc's std file. (The > std.armdebug is also for re@, so that it's easy for them to adjust when > making releases.) > > The problem is that I'm so backed up with other obbligations and > problem reports not getting dealt with and of course $work, so I never > find any time to give a scheme like this a try. > I welcome others to try to do this. You'll find it is a bit like peeling an onion. You don't have orthogonal classes so much as a venn diagram. I want to support ALL SoCs for the bcm2835 family? Or I just want to support one specific one. Allwinner makes this especially noticeable since it has a large family of things. And then do you slice the supported devices up via busses (only include those devices on PCI bus) vs device type (only include network devices). But then you get people wanting to have just wireless devices, or just USB wireless devices. You quickly discover a combinatoric explosion if you want to do this generically. I'll see if I can find some time take a shot at doing it just at the SoC level, but doing it generically gets really ugly really quickly.... Solving that specific problem doesn't look too awful. Warner From owner-freebsd-arm@freebsd.org Wed Oct 4 04:50:44 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 A1A62E2DDF3 for ; Wed, 4 Oct 2017 04:50:44 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 24DDA712C4; Wed, 4 Oct 2017 04:50:44 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id d10so9692161lfg.11; Tue, 03 Oct 2017 21:50:44 -0700 (PDT) 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=9DlygzgOGvbmjIUlzn2S/zzHKcqPWy3djH5cpAner7Q=; b=lyN05eqTNUTFPywcQKMSBVXVZOoFJ6PaCtyc4Q+atfoKnZhk/5Plvga8Udjwx6bzXI DqxjraPNROtLgH/VGcDGEqGomhIw6eJB2QvauZKhLcIz/GzJC4ScM1+fjWqKeXf7+aZ/ MXQLZMFu/IFxAXHMJWK/AQZqsXlvkB/gshX/kcht51fG7dE3ZAzUBle64xP4yqDZxwfU RA5ezhKKHDdgVuCiqcTNoQPh+ScWZDCZGlgl7e96oUo5NMiqIZqeOxqmycWETZFV6yA9 CZxQTWdOL9exFyr2ORj2MRg2EP4a2GNjTnZTyHkvYkyPJwmn/VBkxVCbE0ScR1N/BMRr zwbg== 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=9DlygzgOGvbmjIUlzn2S/zzHKcqPWy3djH5cpAner7Q=; b=lA5tfyYtr4mI8WS+PjRWRRhr2lRpAo2uxUV3TpCvviQFVzxBT+oGmSIAxwos1k80K/ EwXKveyxhOsu7u51h++y7lSZ+wP0IZhE5wzD2BMGhP5ugrgvK9B8dwHb2qm8FQzKSOAQ QxJ2ZHUjjqE4hHZTgb8aLIVN0ZPLgijNWg9jPCJi9o9aPzIxRZ09iBuzv2irR3XMcXSr iMR/sZPAeleQkJ/UjbMs1gb7zEpGHlUC5p93WfUHxEatQmCNjSOPN3RvlbLJBlOV6Lta MaCz/ZY05liY+uhNCQIlXtyXHTRL0/FatKwcWT/wHJu+iyJsXOF1yRGF7xWClnNLwaap HQFQ== X-Gm-Message-State: AMCzsaUQuXF4E6HpWZgVK1DXolDvnWO9ZcVChEJIO8ndN3UioZsHIVR1 3Kv1GctgIVoXkH3H3dhoddvPZwNjUVcapFvVb4s= X-Google-Smtp-Source: AOwi7QCE8GDta31wz//6ybQsV1sDMJ5T8rop3rCICCSbxXGMEi4DaZ1XVW2YZeYP6yMbbIw93fVuA9senNZ0BUyXNq4= X-Received: by 10.25.234.66 with SMTP id i63mr3671152lfh.188.1507092642384; Tue, 03 Oct 2017 21:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Tue, 3 Oct 2017 21:50:41 -0700 (PDT) In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <1507068609.86205.81.camel@freebsd.org> From: Russell Haley Date: Tue, 3 Oct 2017 21:50:41 -0700 Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: Warner Losh Cc: Ian Lepore , "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: Wed, 04 Oct 2017 04:50:44 -0000 On Tue, Oct 3, 2017 at 3:55 PM, Warner Losh wrote: > On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore wrote: > >> On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: >> > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: >> > >> > > >> > > On 10/03/17 13:00, Mark Linimon wrote: >> > > > >> > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: >> > > > > >> > > > > Why are we working towards a GENERIC kernel for arm? >> > > > My intuition would be: >> > > > >> > > > - easier to tell new FreeBSD users how to start >> > > > - less work for Release Engineering to make targets >> > > > >> > > > OTOH I'm not doing the work so I don't get to set the >> > > > direction :-) >> > > > >> > > > My _opinion_ is that we still seem to have a steeper >> > > > curve for our new users than is necessary. I intend to >> > > > think about that more this fall. >> > > > >> > > That is probably 'wishful thinking' for the very distant future. Most >> > > of the common ARM SOC's have very different capabilities between each >> > > other. Each also requires a unique U-Boot partition that gets read >> > > before the FreeBSD kernel is loaded. >> > > >> > While this is true, how to create them can be described generically. You >> > put these bits in this physical location, or on that partition and away >> you >> > go. The pre-boot environment is indeed different, but it's highly >> desirable >> > to have everything after that identical. It ensures uniformity in a >> highly >> > fragmented segment of our user base. Different kernels, even generated >> from >> > the same sources, run the risk of being subtly different from each other, >> > leading to less coverage between the boards. We've had issues related to >> > this in the past from time to time. >> > >> > I'm working on a program I'm calling "spin" which will take a description >> > of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) >> > and it will create a bootable image knowing nothing more. If it also has >> to >> > know which of a bazillion kernels to use, that makes things more >> > complicated. >> > >> > We want more uniformity, not less. Much of the differences we have today >> > are arbitrary (and often wrong). >> > >> > >> > > >> > > I strongly favor the current approach that has a custom kernel >> > > configuration file and U-Boot for each SOC. All of the common ARM >> > > systems have a limited amount of real estate to store FreeBSD kernel >> and >> > > base system because it all must fit on a SD memory card. Having a >> > > GENERIC kernel that covers all SOC variants would consume flash space >> > > that will never be used. >> > >> > Nobody is saying that you can't do this. Just that GENERIC will be the >> > union of all these kernel and be what you get by default. Since nobody >> has >> > quantified the differences, I'm having trouble getting worked up over the >> > somewhat trivial difference in size (especially compared to most SD cards >> > today). >> > >> > Warner >> >> Well, I guess I'll stop pretending there's any chance this freight >> train can be stopped. I find the advantages mentioned so far dubious >> at best, specious at worst, except for the single item "packaged base". >> I don't know much about how that stuff is structured, but I can see >> how having lots of different kernels might be difficult for packaging. >> >> But we absolutely have to solve the problem of making it easy for >> people to create custom kernel configs. "Include GENERIC and add some >> nodevice/nooption lines" is just not going to work. Right now I use >> "include IMX6" and then some nodevice/nooption lines, and that works >> fine. >> >> So if IMX6 goes away as a standalone buildable config, there needs to >> be some other thing like it that can be included. The idea that keeps >> nudging me is that our GENERIC should look like: >> >> include std.armv6 >> include std.armdebug >> include std.a10 >> include std.a20 >> include std.bcm2835 >> include std.imx6 >> ... >> >> Now anybody can create a custom config by including std.armv6, >> std.armdebug if they want it, and their soc's std file. (The >> std.armdebug is also for re@, so that it's easy for them to adjust when >> making releases.) >> >> The problem is that I'm so backed up with other obbligations and >> problem reports not getting dealt with and of course $work, so I never >> find any time to give a scheme like this a try. >> > > I welcome others to try to do this. You'll find it is a bit like peeling an > onion. You don't have orthogonal classes so much as a venn diagram. I want > to support ALL SoCs for the bcm2835 family? Or I just want to support one > specific one. Allwinner makes this especially noticeable since it has a > large family of things. And then do you slice the supported devices up via > busses (only include those devices on PCI bus) vs device type (only include > network devices). But then you get people wanting to have just wireless > devices, or just USB wireless devices. You quickly discover a combinatoric > explosion if you want to do this generically. > > I'll see if I can find some time take a shot at doing it just at the SoC > level, but doing it generically gets really ugly really quickly.... Solving > that specific problem doesn't look too awful. > > Warner My ignorance on this subject allows me to ask an obtuse question: Is there no way to do something more dynamic and maintainable with kldload and ubldr using scripts? As Warner has pointed out, there are more arm variants, more manufacturers/SOM makers and more board variants every year. Stuffing everything in and then "un-including" everything doesn't sound maintainable. Even Ians suggestion may get cumbersome in a short time. What if we actually do get good support for Qualcom chips? Think of how many phone makers are there? Russ From owner-freebsd-arm@freebsd.org Wed Oct 4 05:12: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 195A2E2E3FD for ; Wed, 4 Oct 2017 05:12:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 D7DFB7199E for ; Wed, 4 Oct 2017 05:12:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id g18so14116675itg.5 for ; Tue, 03 Oct 2017 22:12:07 -0700 (PDT) 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=UgXkjUoBkjmYFklD0ZqhqGPz3b91XedMBtnDiZkiI08=; b=h1qjeHq76359U575P9gHYglJSD/zFSzUQ3S56N1BKRLvV2AC4i4GnllK6uw4Cu+2sS updmOVEjXtqzZq+5FyZPmPSPz+oGXfkNVewXnJ9HNcxQs5s9q6ga3lGmo+zhaz4pkhcI RBTX8uFFXYCdvQ45fGhPLXfeLgld8AWL3fIBPwvUWOguNGj/qIN9LJBU3qBLIItVCMig q/g20hxStsKfyDiJOdbHDhJgxt6C1OZaUSWdmmpokL47RwC4ZvA+EZxoaifN1ClEZNou VCFDfh8eL9i0PU5kNV0hdrZpHARPKI1zjrCFLVyvZll2bSqWWZb+Mla7bwR8JZ9l4ZgT VuSg== 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=UgXkjUoBkjmYFklD0ZqhqGPz3b91XedMBtnDiZkiI08=; b=hCV7Tofa8ezmenmkO4ZQ1eBb0KPjgIgjjLchdKKS1mJm6RM+zRv17Gj+2hkKXlYKXU lGwA8FJoOOzhG6QmZfp5qbW/IgGu249Jw2LzrLBiCLQbn2LPYlRkxLOWhMrdvXOJWjXE U6tw5aT6cGn7eupEYpWMFzTTzrEq3ZGPpQ6teGNTH8+547D/eQwJiH7reV2/kLxxeSXa gVk5eznZl0oA0z2NoqFut6pi6WyIIwSEn4EzgrHeOBeWqDCQJXsztGr+cZsbWoejdkuG +Va68afNjNiyMdnUN4U2exfdi2QZiwoxA+/CgTxPRYOWrpglnchVP1SngR1JJlSlp2c4 /+hA== X-Gm-Message-State: AMCzsaWbPpRgYRIUDrrHDWke4vBQR68CLU3qWtV1XcflYNWWJvRWbY2L ijohxcWtwggkLXQr+160AplCpJgT/g/7HhES3UXgag== X-Google-Smtp-Source: AOwi7QCLrgn065f/RfYjrVY/y09a3hvBXq2bp6j9J0wkWVFYCUmSUeqhtLwyINgGYS0kXOlR/juDfLdOxUfsS1/Qogs= X-Received: by 10.36.201.4 with SMTP id h4mr9842903itg.26.1507093927115; Tue, 03 Oct 2017 22:12:07 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Tue, 3 Oct 2017 22:12:06 -0700 (PDT) X-Originating-IP: [208.185.168.99] Received: by 10.79.2.194 with HTTP; Tue, 3 Oct 2017 22:12:06 -0700 (PDT) In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <1507068609.86205.81.camel@freebsd.org> From: Warner Losh Date: Tue, 3 Oct 2017 23:12:06 -0600 X-Google-Sender-Auth: wPDi2T5Bh3TMxv-lKDSvdHsT-VE Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: Russell Haley Cc: Ian Lepore , 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: Wed, 04 Oct 2017 05:12:08 -0000 On Oct 3, 2017 9:50 PM, "Russell Haley" wrote: On Tue, Oct 3, 2017 at 3:55 PM, Warner Losh wrote: > On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore wrote: > >> On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: >> > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: >> > >> > > >> > > On 10/03/17 13:00, Mark Linimon wrote: >> > > > >> > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: >> > > > > >> > > > > Why are we working towards a GENERIC kernel for arm? >> > > > My intuition would be: >> > > > >> > > > - easier to tell new FreeBSD users how to start >> > > > - less work for Release Engineering to make targets >> > > > >> > > > OTOH I'm not doing the work so I don't get to set the >> > > > direction :-) >> > > > >> > > > My _opinion_ is that we still seem to have a steeper >> > > > curve for our new users than is necessary. I intend to >> > > > think about that more this fall. >> > > > >> > > That is probably 'wishful thinking' for the very distant future. Most >> > > of the common ARM SOC's have very different capabilities between each >> > > other. Each also requires a unique U-Boot partition that gets read >> > > before the FreeBSD kernel is loaded. >> > > >> > While this is true, how to create them can be described generically. You >> > put these bits in this physical location, or on that partition and away >> you >> > go. The pre-boot environment is indeed different, but it's highly >> desirable >> > to have everything after that identical. It ensures uniformity in a >> highly >> > fragmented segment of our user base. Different kernels, even generated >> from >> > the same sources, run the risk of being subtly different from each other, >> > leading to less coverage between the boards. We've had issues related to >> > this in the past from time to time. >> > >> > I'm working on a program I'm calling "spin" which will take a description >> > of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) >> > and it will create a bootable image knowing nothing more. If it also has >> to >> > know which of a bazillion kernels to use, that makes things more >> > complicated. >> > >> > We want more uniformity, not less. Much of the differences we have today >> > are arbitrary (and often wrong). >> > >> > >> > > >> > > I strongly favor the current approach that has a custom kernel >> > > configuration file and U-Boot for each SOC. All of the common ARM >> > > systems have a limited amount of real estate to store FreeBSD kernel >> and >> > > base system because it all must fit on a SD memory card. Having a >> > > GENERIC kernel that covers all SOC variants would consume flash space >> > > that will never be used. >> > >> > Nobody is saying that you can't do this. Just that GENERIC will be the >> > union of all these kernel and be what you get by default. Since nobody >> has >> > quantified the differences, I'm having trouble getting worked up over the >> > somewhat trivial difference in size (especially compared to most SD cards >> > today). >> > >> > Warner >> >> Well, I guess I'll stop pretending there's any chance this freight >> train can be stopped. I find the advantages mentioned so far dubious >> at best, specious at worst, except for the single item "packaged base". >> I don't know much about how that stuff is structured, but I can see >> how having lots of different kernels might be difficult for packaging. >> >> But we absolutely have to solve the problem of making it easy for >> people to create custom kernel configs. "Include GENERIC and add some >> nodevice/nooption lines" is just not going to work. Right now I use >> "include IMX6" and then some nodevice/nooption lines, and that works >> fine. >> >> So if IMX6 goes away as a standalone buildable config, there needs to >> be some other thing like it that can be included. The idea that keeps >> nudging me is that our GENERIC should look like: >> >> include std.armv6 >> include std.armdebug >> include std.a10 >> include std.a20 >> include std.bcm2835 >> include std.imx6 >> ... >> >> Now anybody can create a custom config by including std.armv6, >> std.armdebug if they want it, and their soc's std file. (The >> std.armdebug is also for re@, so that it's easy for them to adjust when >> making releases.) >> >> The problem is that I'm so backed up with other obbligations and >> problem reports not getting dealt with and of course $work, so I never >> find any time to give a scheme like this a try. >> > > I welcome others to try to do this. You'll find it is a bit like peeling an > onion. You don't have orthogonal classes so much as a venn diagram. I want > to support ALL SoCs for the bcm2835 family? Or I just want to support one > specific one. Allwinner makes this especially noticeable since it has a > large family of things. And then do you slice the supported devices up via > busses (only include those devices on PCI bus) vs device type (only include > network devices). But then you get people wanting to have just wireless > devices, or just USB wireless devices. You quickly discover a combinatoric > explosion if you want to do this generically. > > I'll see if I can find some time take a shot at doing it just at the SoC > level, but doing it generically gets really ugly really quickly.... Solving > that specific problem doesn't look too awful. > > Warner My ignorance on this subject allows me to ask an obtuse question: Is there no way to do something more dynamic and maintainable with kldload and ubldr using scripts? As Warner has pointed out, there are more arm variants, more manufacturers/SOM makers and more board variants every year. Stuffing everything in and then "un-including" everything doesn't sound maintainable. Even Ians suggestion may get cumbersome in a short time. What if we actually do get good support for Qualcom chips? Think of how many phone makers are there? Someone would need to tag all the Fdt Drivers with PNP info first. Warner From owner-freebsd-arm@freebsd.org Wed Oct 4 05:52:56 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 82F7AE2F265 for ; Wed, 4 Oct 2017 05:52:56 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 082A272B8A; Wed, 4 Oct 2017 05:52:55 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id l23so5235765lfk.10; Tue, 03 Oct 2017 22:52:55 -0700 (PDT) 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=1pdMNpWem0JQ+7ZICQgUQ+HMfaHQEknFr+e+RAJhAfU=; b=ncgxEqYwqgOk2idDbw2a+Ci32naOrHUxD66az/qo92d4V+x84AaqXZsoDKtwyPglW9 U15hRQtG5x11AH7eqZF/r+uAPjHn/bpO68SDwd9Kyw/UYKkTZmv5FRgMG69DOuQMTztC 1Zb88MCxMKGAg0xmXOUjopYhJpRm+Zxp5p/Zl95qoJkmNi+73dkPnk/9sxm3b+ccp0vF yats+AmwmzdgqPe+LH6v+gGIuj757L37aPu+uNFE3JEMCf1AfswbqLqTkSogl13yOvQ6 PYterlpc8h/Ev5Gy6vdVxuKpc5ENNWYaO/GFa7sWSCEjphK9Qp6WWky7yl8nLFW6a59P lDtw== 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=1pdMNpWem0JQ+7ZICQgUQ+HMfaHQEknFr+e+RAJhAfU=; b=rkwAYumzHNc8pH7D0JHGXQ7fUCs0VfuDrSKnD06QDrr5yKmDE51LhDpcXgnj2EOeTO C2GYTvUWatspaOeSYWXVvFe/t5Pr75KjNr7U8sTep2hpzOVdQ09C2XxFwq7wlpe+QN3t rwTznMCZs6OYQribCSxktzpW+pvs7LIuWjSpDy5vSIE+Cw3IPc520G0pOPEfZ6k2FCWl /32Lcb8cj6zHfBP+eUFJ5eIOOME3+b2ikQzKGhXybSmZiRq5Cz8DR5Uu7PhYdtIMl8h1 QE6X1uCAP6IIvmliR7fU1M7gfamdZQY61AZi1oLTsDxVcWCboDb5cNvd/K6QEsyGMVvF cWgA== X-Gm-Message-State: AMCzsaUIxSMc5AgZnR/JTQrn33zX+i+nQ3Vl45fGKoAe98uDte5YpYMl 30PMwE/nEtj+ZkMES6G2ZHiK9DKcaE4+BsW541k= X-Google-Smtp-Source: AOwi7QBF1XDuRqT8n/kIFKeoSdqn+hRvWZ31SEKvrnoncWate464mC02UhulK7QTJrKaBKaSTx+HAPYCSkso3llHnLE= X-Received: by 10.46.21.25 with SMTP id s25mr9267043ljd.71.1507096372833; Tue, 03 Oct 2017 22:52:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.14.2 with HTTP; Tue, 3 Oct 2017 22:52:52 -0700 (PDT) In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <1507068609.86205.81.camel@freebsd.org> From: Russell Haley Date: Tue, 3 Oct 2017 22:52:52 -0700 Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: Warner Losh Cc: Ian Lepore , freebsd-arm 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: Wed, 04 Oct 2017 05:52:56 -0000 On Tue, Oct 3, 2017 at 10:12 PM, Warner Losh wrote: > > > On Oct 3, 2017 9:50 PM, "Russell Haley" wrote: > > On Tue, Oct 3, 2017 at 3:55 PM, Warner Losh wrote: >> On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore wrote: >> >>> On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: >>> > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: >>> > >>> > > >>> > > On 10/03/17 13:00, Mark Linimon wrote: >>> > > > >>> > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: >>> > > > > >>> > > > > Why are we working towards a GENERIC kernel for arm? >>> > > > My intuition would be: >>> > > > >>> > > > - easier to tell new FreeBSD users how to start >>> > > > - less work for Release Engineering to make targets >>> > > > >>> > > > OTOH I'm not doing the work so I don't get to set the >>> > > > direction :-) >>> > > > >>> > > > My _opinion_ is that we still seem to have a steeper >>> > > > curve for our new users than is necessary. I intend to >>> > > > think about that more this fall. >>> > > > >>> > > That is probably 'wishful thinking' for the very distant future. >>> > > Most >>> > > of the common ARM SOC's have very different capabilities between each >>> > > other. Each also requires a unique U-Boot partition that gets read >>> > > before the FreeBSD kernel is loaded. >>> > > >>> > While this is true, how to create them can be described generically. >>> > You >>> > put these bits in this physical location, or on that partition and away >>> you >>> > go. The pre-boot environment is indeed different, but it's highly >>> desirable >>> > to have everything after that identical. It ensures uniformity in a >>> highly >>> > fragmented segment of our user base. Different kernels, even generated >>> from >>> > the same sources, run the risk of being subtly different from each >>> > other, >>> > leading to less coverage between the boards. We've had issues related >>> > to >>> > this in the past from time to time. >>> > >>> > I'm working on a program I'm calling "spin" which will take a >>> > description >>> > of what to use (eg, u-boot for the banana ramma board plus FreeBSD >>> > 12.3R) >>> > and it will create a bootable image knowing nothing more. If it also >>> > has >>> to >>> > know which of a bazillion kernels to use, that makes things more >>> > complicated. >>> > >>> > We want more uniformity, not less. Much of the differences we have >>> > today >>> > are arbitrary (and often wrong). >>> > >>> > >>> > > >>> > > I strongly favor the current approach that has a custom kernel >>> > > configuration file and U-Boot for each SOC. All of the common ARM >>> > > systems have a limited amount of real estate to store FreeBSD kernel >>> and >>> > > base system because it all must fit on a SD memory card. Having a >>> > > GENERIC kernel that covers all SOC variants would consume flash space >>> > > that will never be used. >>> > >>> > Nobody is saying that you can't do this. Just that GENERIC will be the >>> > union of all these kernel and be what you get by default. Since nobody >>> has >>> > quantified the differences, I'm having trouble getting worked up over >>> > the >>> > somewhat trivial difference in size (especially compared to most SD >>> > cards >>> > today). >>> > >>> > Warner >>> >>> Well, I guess I'll stop pretending there's any chance this freight >>> train can be stopped. I find the advantages mentioned so far dubious >>> at best, specious at worst, except for the single item "packaged base". >>> I don't know much about how that stuff is structured, but I can see >>> how having lots of different kernels might be difficult for packaging. >>> >>> But we absolutely have to solve the problem of making it easy for >>> people to create custom kernel configs. "Include GENERIC and add some >>> nodevice/nooption lines" is just not going to work. Right now I use >>> "include IMX6" and then some nodevice/nooption lines, and that works >>> fine. >>> >>> So if IMX6 goes away as a standalone buildable config, there needs to >>> be some other thing like it that can be included. The idea that keeps >>> nudging me is that our GENERIC should look like: >>> >>> include std.armv6 >>> include std.armdebug >>> include std.a10 >>> include std.a20 >>> include std.bcm2835 >>> include std.imx6 >>> ... >>> >>> Now anybody can create a custom config by including std.armv6, >>> std.armdebug if they want it, and their soc's std file. (The >>> std.armdebug is also for re@, so that it's easy for them to adjust when >>> making releases.) >>> >>> The problem is that I'm so backed up with other obbligations and >>> problem reports not getting dealt with and of course $work, so I never >>> find any time to give a scheme like this a try. >>> >> >> I welcome others to try to do this. You'll find it is a bit like peeling >> an >> onion. You don't have orthogonal classes so much as a venn diagram. I want >> to support ALL SoCs for the bcm2835 family? Or I just want to support one >> specific one. Allwinner makes this especially noticeable since it has a >> large family of things. And then do you slice the supported devices up via >> busses (only include those devices on PCI bus) vs device type (only >> include >> network devices). But then you get people wanting to have just wireless >> devices, or just USB wireless devices. You quickly discover a combinatoric >> explosion if you want to do this generically. >> >> I'll see if I can find some time take a shot at doing it just at the SoC >> level, but doing it generically gets really ugly really quickly.... >> Solving >> that specific problem doesn't look too awful. >> >> Warner > > My ignorance on this subject allows me to ask an obtuse question: Is > there no way to do something more dynamic and maintainable with > kldload and ubldr using scripts? As Warner has pointed out, there are > more arm variants, more manufacturers/SOM makers and more board > variants every year. Stuffing everything in and then "un-including" > everything doesn't sound maintainable. Even Ians suggestion may get > cumbersome in a short time. What if we actually do get good support > for Qualcom chips? Think of how many phone makers are there? > > > Someone would need to tag all the Fdt > > Drivers with PNP info first. > > Warner Can you point me to an example of the PNP tags or where to get more info? Would that mean modifying the DTS files (which I believe are now replicated from GNU libraries)? Russ From owner-freebsd-arm@freebsd.org Wed Oct 4 14:17:53 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 29F7DE3A858 for ; Wed, 4 Oct 2017 14:17:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::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 DB94863B97 for ; Wed, 4 Oct 2017 14:17:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x242.google.com with SMTP id m16so778876iod.5 for ; Wed, 04 Oct 2017 07:17:52 -0700 (PDT) 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=NkkcXG6FovgNIsWLE7JrblusAh8J7SUZeWND8Hktu9s=; b=czAEV8pzRagGRsh+D+EtfK9FLA2MjjO2rQgAvr+FJ9sKM7v972jLkvvCJ9KwuVOIXu x/Z+IEBe5+RGozSDiEMdA2NK+8x4aWsdcQREAtd5gnkdCDRGGdKygg/beOlORIOv7okZ 7NibK0UjAAscJ8KOxsayFq/vf7dDRpg1CNOUc3Bf6lf1xquDFJKctneQ/bXmzx4b5Jjo Qo5qj8GuyyUCHao4J9DV+3PdrPnd3zDufkyf0+rLvYdM2tcSo8ulAEQXLQIBlmPi/uzM 5+e2Bp/ZdsJ59ZK7O8n5wzxq5Z0kzuZXKX49brC6tTV/EqnWzINcf8dLwWdcZEmEjy1g gCFw== 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=NkkcXG6FovgNIsWLE7JrblusAh8J7SUZeWND8Hktu9s=; b=s2Xhd+NWPpLBVTm8/sW9NcWKDrNUP7MpdtKTD6VY/QgU25QfcSUIQfC1Y09Bplc4CV BXwfHOyAgww6yGAuRfjiYD/iqGihyoSF657/F+AnKhOHLNbXrM3tB0hQI90TxhQ/Ji/v q42DTcZ75vSGvC2rdxoZcL21dhyFcfglVmCT8FWMU7CgONWZQvo76aVaZhY46XYL6HvJ CWLk8o0SIH6Z8DqGOvUQHXcncjnk9QGQOjENwhdc2NoJQ1hni1XLn1AMsqZMaspIC5NE aLX6ucTUF5ZQ/eFU0DqzGq83bphmwVAHZ0tctvrN3eljT84gKuKXuJbUgw/OJ11Pwwkq Ljsg== X-Gm-Message-State: AMCzsaWfT0o22iDxQXlVGijb0cKVE4p2IOemfeTMmt04e/NQqLRIt8Kw mIcROfJWydpIN7d9LKoiXYDOyORu0iKHEsAzE1XiCA== X-Google-Smtp-Source: AOwi7QCeGqD/KA2DetJ7fKMTiW72DqO79aM58fvoDCsuWkIGKaveklDPEFrFAe1KDABr5m9JGOKA+UvYuEnG3880a2Y= X-Received: by 10.107.68.6 with SMTP id r6mr3808554ioa.282.1507126666323; Wed, 04 Oct 2017 07:17:46 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 4 Oct 2017 07:17:45 -0700 (PDT) X-Originating-IP: [192.173.66.162] In-Reply-To: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <1507068609.86205.81.camel@freebsd.org> From: Warner Losh Date: Wed, 4 Oct 2017 08:17:45 -0600 X-Google-Sender-Auth: 1OHr4eN-8bVVH6ZT8b07nAoFI8w Message-ID: Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) To: Russell Haley Cc: Ian Lepore , 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: Wed, 04 Oct 2017 14:17:53 -0000 On Tue, Oct 3, 2017 at 11:52 PM, Russell Haley wrote: > On Tue, Oct 3, 2017 at 10:12 PM, Warner Losh wrote: > > > > > > On Oct 3, 2017 9:50 PM, "Russell Haley" wrote: > > > > On Tue, Oct 3, 2017 at 3:55 PM, Warner Losh wrote: > >> On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore wrote: > >> > >>> On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: > >>> > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus wrote: > >>> > > >>> > > > >>> > > On 10/03/17 13:00, Mark Linimon wrote: > >>> > > > > >>> > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: > >>> > > > > > >>> > > > > Why are we working towards a GENERIC kernel for arm? > >>> > > > My intuition would be: > >>> > > > > >>> > > > - easier to tell new FreeBSD users how to start > >>> > > > - less work for Release Engineering to make targets > >>> > > > > >>> > > > OTOH I'm not doing the work so I don't get to set the > >>> > > > direction :-) > >>> > > > > >>> > > > My _opinion_ is that we still seem to have a steeper > >>> > > > curve for our new users than is necessary. I intend to > >>> > > > think about that more this fall. > >>> > > > > >>> > > That is probably 'wishful thinking' for the very distant future. > >>> > > Most > >>> > > of the common ARM SOC's have very different capabilities between > each > >>> > > other. Each also requires a unique U-Boot partition that gets read > >>> > > before the FreeBSD kernel is loaded. > >>> > > > >>> > While this is true, how to create them can be described generically. > >>> > You > >>> > put these bits in this physical location, or on that partition and > away > >>> you > >>> > go. The pre-boot environment is indeed different, but it's highly > >>> desirable > >>> > to have everything after that identical. It ensures uniformity in a > >>> highly > >>> > fragmented segment of our user base. Different kernels, even > generated > >>> from > >>> > the same sources, run the risk of being subtly different from each > >>> > other, > >>> > leading to less coverage between the boards. We've had issues related > >>> > to > >>> > this in the past from time to time. > >>> > > >>> > I'm working on a program I'm calling "spin" which will take a > >>> > description > >>> > of what to use (eg, u-boot for the banana ramma board plus FreeBSD > >>> > 12.3R) > >>> > and it will create a bootable image knowing nothing more. If it also > >>> > has > >>> to > >>> > know which of a bazillion kernels to use, that makes things more > >>> > complicated. > >>> > > >>> > We want more uniformity, not less. Much of the differences we have > >>> > today > >>> > are arbitrary (and often wrong). > >>> > > >>> > > >>> > > > >>> > > I strongly favor the current approach that has a custom kernel > >>> > > configuration file and U-Boot for each SOC. All of the common ARM > >>> > > systems have a limited amount of real estate to store FreeBSD > kernel > >>> and > >>> > > base system because it all must fit on a SD memory card. Having a > >>> > > GENERIC kernel that covers all SOC variants would consume flash > space > >>> > > that will never be used. > >>> > > >>> > Nobody is saying that you can't do this. Just that GENERIC will be > the > >>> > union of all these kernel and be what you get by default. Since > nobody > >>> has > >>> > quantified the differences, I'm having trouble getting worked up over > >>> > the > >>> > somewhat trivial difference in size (especially compared to most SD > >>> > cards > >>> > today). > >>> > > >>> > Warner > >>> > >>> Well, I guess I'll stop pretending there's any chance this freight > >>> train can be stopped. I find the advantages mentioned so far dubious > >>> at best, specious at worst, except for the single item "packaged base". > >>> I don't know much about how that stuff is structured, but I can see > >>> how having lots of different kernels might be difficult for packaging. > >>> > >>> But we absolutely have to solve the problem of making it easy for > >>> people to create custom kernel configs. "Include GENERIC and add some > >>> nodevice/nooption lines" is just not going to work. Right now I use > >>> "include IMX6" and then some nodevice/nooption lines, and that works > >>> fine. > >>> > >>> So if IMX6 goes away as a standalone buildable config, there needs to > >>> be some other thing like it that can be included. The idea that keeps > >>> nudging me is that our GENERIC should look like: > >>> > >>> include std.armv6 > >>> include std.armdebug > >>> include std.a10 > >>> include std.a20 > >>> include std.bcm2835 > >>> include std.imx6 > >>> ... > >>> > >>> Now anybody can create a custom config by including std.armv6, > >>> std.armdebug if they want it, and their soc's std file. (The > >>> std.armdebug is also for re@, so that it's easy for them to adjust > when > >>> making releases.) > >>> > >>> The problem is that I'm so backed up with other obbligations and > >>> problem reports not getting dealt with and of course $work, so I never > >>> find any time to give a scheme like this a try. > >>> > >> > >> I welcome others to try to do this. You'll find it is a bit like peeling > >> an > >> onion. You don't have orthogonal classes so much as a venn diagram. I > want > >> to support ALL SoCs for the bcm2835 family? Or I just want to support > one > >> specific one. Allwinner makes this especially noticeable since it has a > >> large family of things. And then do you slice the supported devices up > via > >> busses (only include those devices on PCI bus) vs device type (only > >> include > >> network devices). But then you get people wanting to have just wireless > >> devices, or just USB wireless devices. You quickly discover a > combinatoric > >> explosion if you want to do this generically. > >> > >> I'll see if I can find some time take a shot at doing it just at the SoC > >> level, but doing it generically gets really ugly really quickly.... > >> Solving > >> that specific problem doesn't look too awful. > >> > >> Warner > > > > My ignorance on this subject allows me to ask an obtuse question: Is > > there no way to do something more dynamic and maintainable with > > kldload and ubldr using scripts? As Warner has pointed out, there are > > more arm variants, more manufacturers/SOM makers and more board > > variants every year. Stuffing everything in and then "un-including" > > everything doesn't sound maintainable. Even Ians suggestion may get > > cumbersome in a short time. What if we actually do get good support > > for Qualcom chips? Think of how many phone makers are there? > > > > > > Someone would need to tag all the Fdt > > > > Drivers with PNP info first. > > > > Warner > Can you point me to an example of the PNP tags or where to get more > info? Would that mean modifying the DTS files (which I believe are now > replicated from GNU libraries)? > Sure. Look for SIMPLEBUS_PNP_INFO. Usually, you can point it at the compat table. See sys/arm/ti/aintc.c: ... /* List of compatible strings for FDT tree */ static struct ofw_compat_data compat_data[] = { {"ti,am33xx-intc", 1}, {"ti,omap2-intc", 1}, {NULL, 0}, }; ... SIMPLEBUS_PNP_INFO(compat_data); Without that data, you can't have a minimal kernel that then loads the minimum modules. There's some things that can't be kld-loaded, though. The biggest one that's likely to be a hassle is console drivers. They have to exist before the kld modules are linked into the kernel. Warner From owner-freebsd-arm@freebsd.org Thu Oct 5 23:10: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 49319E44E93 for ; Thu, 5 Oct 2017 23:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 11B6765923 for ; Thu, 5 Oct 2017 23:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id p138so3293044itp.2 for ; Thu, 05 Oct 2017 16:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=9nt2/LHmJs8ivi7VzvRYKiQPEChTCAOlA4XJfJh9mH4=; b=nSwg+cxp7AqOctSUbNenx5Nivzj/8aTP5JGtmg9NDGzIE/N84DpE/U4Zoowh9fhiRf QxgPGhOrnQ2gffi951o9TbFqOfp330n3XPouZCmJwkaDVT5pn3bwYI7Do3Px4JVbMaf5 XrBPaFSzz0hLOlA9fbjwoRg1OKlMQ29yCMSL4zgo+VEkaCcfKdGKmb13a8ZYeUAah8P2 mcDHPxxUQKP9DHAPDxnBD+0wWe05IXz5IUG5XoXU0xsfkpBA1lLPNGwiRQYPhGm8UN+G AxCODf+uyCSK4yGypLitj8w7ODu+nbOgLENdpv1TBNeO3tpS1VQIzKgnTy7YO2Uy/nI7 eZZA== 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:from:date:message-id:subject :to; bh=9nt2/LHmJs8ivi7VzvRYKiQPEChTCAOlA4XJfJh9mH4=; b=G4Ifw5DIjzKcyWMT+m2pBZuurLFJNei1O6vraqrvi+NlJB+4k2dGxJDlAyB5RuXQ6i 3/YIIDCtPWWtvKGaK54wieggTMcgxMICYga78tTn+5q2Blk12FFHIlJheXdm3bA2BYM/ 1YqTBVpFVd+p8Qg0dJk1v7tPEdW8Lqz+dRYxiQJomuFfs2cldpYKBKs1GN+Nz3zYVOl4 kspsgchH2hs0KUy6KkM2ipdor4HcQL0/qTmyejW2B0m/6GP5DrOOxl7Gek4U+tEjg5+X IzQ7FEJ8az3ampRXBB3mwRJiM2851SwBWI1A+OkIXn5lhzh3SCLIJ5FJls81gKRxWLWr Jfew== X-Gm-Message-State: AMCzsaWz+bkZ1+qZQ+hO7GoPHmyWJ0qgV802zt+f6r0WgxBvK1iCbwC9 fiz91IawPG0HCMBMLooN+RLnOOwrePjtTWKqJgGsPw== X-Google-Smtp-Source: AOwi7QC361MMHc0LRUy5oOBCno3sen8QJEa7+zd1Cvby5x7KLmXQqhRnvxRzFjIRG1aKG7Vhsif51Ber1HDXUiQSHck= X-Received: by 10.36.201.4 with SMTP id h4mr231571itg.26.1507245016155; Thu, 05 Oct 2017 16:10:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Thu, 5 Oct 2017 16:10:15 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::5304] From: Warner Losh Date: Thu, 5 Oct 2017 16:10:15 -0700 X-Google-Sender-Auth: khhM-yOfQshCiTDkm6AjC742M6g Message-ID: Subject: Heads up: armv7 To: "freebsd-arch@freebsd.org" , "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: Thu, 05 Oct 2017 23:10:17 -0000 I've pushed in the armv7 support into the tree. Please let me know if there's any problems. It works for me, but I'm sure there's code paths i've not fully explored that will need some explanation. I've added an entry to UPDATING. If there's unanticipated bumps, then I'll update it with workarounds. I've bumped the FreeBSD_version to 1200050. Please let me know if you have problems. Warner From owner-freebsd-arm@freebsd.org Fri Oct 6 02:24: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 6045DE24282 for ; Fri, 6 Oct 2017 02:24:06 +0000 (UTC) (envelope-from monty11ez@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 E3C7F6ADE5 for ; Fri, 6 Oct 2017 02:24:05 +0000 (UTC) (envelope-from monty11ez@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id i124so5268141wmf.3 for ; Thu, 05 Oct 2017 19:24:05 -0700 (PDT) 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=hxJdae2uvXndTk89PtE68EvXsd26IZa2y5H2mVDDtMk=; b=edA8JNfi/pRNOgSN4YO2m6tSFcXljbQDlP3+CeXCl4IkB+gMo08v0dyEf1NwafZehO knS0zbALn0cL9FJmKRMT50/QYr8LZmDjlD6Cv/Qx7ceCcEmV/fU+N6SSsdCOv0HmikQP I9CGap4H7uXghly+qfZiv4Mqr/PN4DPiwHmuak8mB4OHxkE/42ZYHUcYNzIt7UVXjU7v tIgYBKbEqMdnhQCh29hjTAABnDxhlFbQC2qym6LGoUPo6QNRHN/poYhR7mia080Z4qpC z+X1ChKR+yois7zDQVsViVfgf+QfMIm6IXY8KzXOn0vkS2XR0IYKCeaW2XOyYGqFgh3D mYtg== 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=hxJdae2uvXndTk89PtE68EvXsd26IZa2y5H2mVDDtMk=; b=WuAZuYGgFS/M5ZyCOv2/wSItnHHhidj6ymuKsv/+L7mNvCr50Qu8pbznU49zhnTT4n FqnxV8QNGcjRQfeTvqdtexdzcnACHWT6zTzlxtekEy6lzVKZ0/qfavjpJpiL+SWjuyIA oSpInPT+JjyITP7LdVowkAxijkC2O2Xm0dgwfIGLA1rLvNvAOFyi8Ay5qBCOQJgdfI5P N707FD1Y+mUATNmZm5gg38MUe1k587hPUItLQoChK23Zhtq8OAwcy84O4raKnBVwOWXB isJB2Bz4xTs8wjQKxbgO+it13xj2C0uXesJ0szd1H+C3uNhT9+dwf6nLN5uA/13RxpcM MPnw== X-Gm-Message-State: AMCzsaWWnWdsUojNWLdCOyExKrZwQMQL6uVGXDNdx8Mq8fp1E4v+EaGG 9z/whTbKY/seU+i3uEeS8QW3KFynImEohWvflAIspg== X-Google-Smtp-Source: AOwi7QBFOoCGEoQB9vuxocTZ5WD2E5iYaB/vw4WVKrSc9p46XRnhLJyR8Q9x1m2W1Iw8YYfM+pJ3a/hwwT00GOpNXLA= X-Received: by 10.80.179.49 with SMTP id q46mr1243800edd.211.1507256643992; Thu, 05 Oct 2017 19:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.228.10 with HTTP; Thu, 5 Oct 2017 19:24:03 -0700 (PDT) From: Monty Chaney-Geib Date: Thu, 5 Oct 2017 22:24:03 -0400 Message-ID: Subject: RPi3 Kernel Fails to Build 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: Fri, 06 Oct 2017 02:24:06 -0000 I'm getting an error trying to build the kernel on hardware. What do you guys recommend I do? There is the error: MAKE="make" sh /usr/src/sys/conf/newvers.sh GENERIC cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror vers.c ctfconvert -L VERSION -g vers.o linking kernel.full unknown emulation: aarch64elf line 19: : expected, but got ( PROVIDE (etext = .); ^ *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src From owner-freebsd-arm@freebsd.org Fri Oct 6 16:25: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 827FCE3B011 for ; Fri, 6 Oct 2017 16:25:58 +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 3850164F5E for ; Fri, 6 Oct 2017 16:25:58 +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 v96Fwt3Z040202 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Oct 2017 08:58:56 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v96Fwtsv040201; Fri, 6 Oct 2017 08:58:55 -0700 (PDT) (envelope-from fbsd) Date: Fri, 6 Oct 2017 08:58:54 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: pmap fault during buildworld on rpi2 Message-ID: <20171006155854.GA40189@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, 06 Oct 2017 16:25:58 -0000 For about one month now, buildworld has been crashing with a pmap error. Rebooting an older kernel always seems to solve the problem, but on rebooting the newly-compiled system the pmap fault happens again on the next buildworld. There seems to be no such problem during other compilations. A top window freezes with cc and ld as the dominant processes. The last kernel I have which works is r322520. Since nobody else seems to be reporting this behavior it's tempting to think the problem is local. Can anyone suggest where I might look? Console, top and log are at: http://www.zefox.net/~fbsd/rpi2/crashes/crash_10_6_17/ Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Oct 6 23:13:23 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 56453E43E18 for ; Fri, 6 Oct 2017 23:13:23 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 E09E473781 for ; Fri, 6 Oct 2017 23:13:22 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id q132so10783327wmd.2 for ; Fri, 06 Oct 2017 16:13:22 -0700 (PDT) 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=TwpjY9ivpW7O78RHB5gLJlJA9psJDZfXA4JlRmeztq4=; b=VuNcK4s1y7PwrbMN/qSKy+ZYWla4Cl2iCrvSPWio130Hi6JdlRbYFQplWlJvMEW4jc 11pzlUnMMAqe9OjA8zX4dXt80QFT9Z46mtN8QvMqlv7stkCZ6/1obzDUQFcdt/GXWeSY VmnEMuE8kgnOcmEO2Kjfhvk+4S2P3EqsbPMkUsXT43yHdxOVb2Y4U7q/bu5v1aPwkR4q ddiHPLsJTTSt8EoE2geIyfzdUZ9gZGmcthN40d+O/WfXCI4KUd+HHGH7r9U65jMZtGC2 5XOpiTksJHRauqq02VsnTuJxOsK9MXAzcUOn1FW2aZqra8mrfyjjC2jOamYaPjH0rN8o mf3w== 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=TwpjY9ivpW7O78RHB5gLJlJA9psJDZfXA4JlRmeztq4=; b=lG7K9cXCaA6b1i/i8E6oV+Gx2NFD3/uN3P2sZ0dYntA5B2eGa/Y9vbxOGJd/SIuusW v5pUoqJm4ofJve+NbhZvQun7wgwiu3m3MdchbWqoTJ3nOQddNVZ77hgkTQW2hjie+MvF 8wt+vehgWoLJNAXQBvw+fXf8i0ZTkmIsUS7WuAEOE2CpwQJXw6bfryrhzaIJvZ544rpM cHLNDbM2Mj8+RoT/Jb9lpcTvy3oeXylYrUHK/ryL93DK5H1rWdventDuyVbEEu/CROLb IOWkGO6iWQiXzoQVzkeCe4WnBjuT9hBQNbxtFhSKhkV6XmjSgz47MKpCgx6gquYEp7dn yqhQ== X-Gm-Message-State: AMCzsaW07GyrfSPWzRn+G6Cnfu3h5253Qma9DHhR4tAT0rJBH/U9KvXI Dz5aDQeelCU+k3tF1xSp8UycU95rtKFClWejZZE4uA== X-Google-Smtp-Source: AOwi7QCl5sx/8j6E/WmLJOODMxXotxmPQTiXwmjC0qzI/0w1f01ViabY3dFOvM7Ts/YW64YJuHteMRqx8e6RYvjPfaE= X-Received: by 10.28.111.206 with SMTP id c75mr2042909wmi.123.1507331600327; Fri, 06 Oct 2017 16:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.143.20 with HTTP; Fri, 6 Oct 2017 16:13:19 -0700 (PDT) In-Reply-To: <20171006155854.GA40189@www.zefox.net> References: <20171006155854.GA40189@www.zefox.net> From: Svatopluk Kraus Date: Sat, 7 Oct 2017 01:13:19 +0200 Message-ID: Subject: Re: pmap fault during buildworld on rpi2 To: bob prohaska 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, 06 Oct 2017 23:13:23 -0000 I have already suggested the following: https://lists.freebsd.org/pipermail/freebsd-arm/2017-September/016697.html Nevertheless, I'm not sure that I understand the way how it happens. Does it crash on rebooting or during buildworld? Are you saying that all kernels after r322520 crash during buildworld with pmap panic? Svata On Fri, Oct 6, 2017 at 5:58 PM, bob prohaska wrote: > For about one month now, buildworld has been crashing with > a pmap error. Rebooting an older kernel always seems to solve > the problem, but on rebooting the newly-compiled system the > pmap fault happens again on the next buildworld. > > There seems to be no such problem during other compilations. > > A top window freezes with cc and ld as the dominant processes. > > The last kernel I have which works is r322520. > > Since nobody else seems to be reporting this behavior > it's tempting to think the problem is local. Can anyone > suggest where I might look? Console, top and log are at: > http://www.zefox.net/~fbsd/rpi2/crashes/crash_10_6_17/ > > Thanks for reading, > > bob prohaska > > _______________________________________________ > 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 Sat Oct 7 02:46:31 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 CBC5EE2A51E for ; Sat, 7 Oct 2017 02:46:31 +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 889E97E410 for ; Sat, 7 Oct 2017 02:46:31 +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 v972kcUS041801 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Oct 2017 19:46:39 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v972kchw041800; Fri, 6 Oct 2017 19:46:38 -0700 (PDT) (envelope-from fbsd) Date: Fri, 6 Oct 2017 19:46:38 -0700 From: bob prohaska To: Svatopluk Kraus Cc: "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: pmap fault during buildworld on rpi2 Message-ID: <20171007024638.GA41063@www.zefox.net> References: <20171006155854.GA40189@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Sat, 07 Oct 2017 02:46:31 -0000 On Sat, Oct 07, 2017 at 01:13:19AM +0200, Svatopluk Kraus wrote: > I have already suggested the following: > https://lists.freebsd.org/pipermail/freebsd-arm/2017-September/016697.html > I read your message and didn't understand it well enough to follow the advice. > Nevertheless, I'm not sure that I understand the way how it happens. > Does it crash on rebooting or during buildworld? During buildworld. > Are you saying that > all kernels after r322520 crash during buildworld with pmap panic? > Correct, to a good approximation. The approximation is that on one occasion, very shortly after r322520, a kernel managed to complete a buildworld without a panic. That makes one success out of about five tries. Mark Millard reported what seemed like a similar panic about a year ago, but it went away by itself. When the successful build following r322520 happened I expected the same thing to happen. It didn't. bob prohaska > > On Fri, Oct 6, 2017 at 5:58 PM, bob prohaska wrote: > > For about one month now, buildworld has been crashing with > > a pmap error. Rebooting an older kernel always seems to solve > > the problem, but on rebooting the newly-compiled system the > > pmap fault happens again on the next buildworld. > > > > There seems to be no such problem during other compilations. > > > > A top window freezes with cc and ld as the dominant processes. > > > > The last kernel I have which works is r322520. > > > > Since nobody else seems to be reporting this behavior > > it's tempting to think the problem is local. Can anyone > > suggest where I might look? Console, top and log are at: > > http://www.zefox.net/~fbsd/rpi2/crashes/crash_10_6_17/ > > > > Thanks for reading, > > > > bob prohaska > > > > _______________________________________________ > > 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 Sat Oct 7 06:50:20 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 DB257E2FBB7 for ; Sat, 7 Oct 2017 06:50:20 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 967DA84F7D for ; Sat, 7 Oct 2017 06:50:20 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: by mail-vk0-x22f.google.com with SMTP id h4so10714311vkg.0 for ; Fri, 06 Oct 2017 23:50:20 -0700 (PDT) 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=0VfDjArqEF7APsHjytCRh9ft/KnWnd1sQaFnmPl+9V8=; b=KZxi0LEl46UFDtC77ZO+79vb8d1YOIo37Ju3vI3ucXx14ZLLJH3VQR25LP3wmBkRa6 G1STgPmV/9rUU3oKtnvNF37iKZ+8cmoF31LAZzpCK0i8lNCQuB98ICjtYGcLGldlsCbD h1tM539qw68lLA429dUz2UtLZeWJ2SJoS8VlXXkv6Bwu5rekbzPCpGWtp3BYc314TqVt BlzrptwfcdW6eLIVLYPN/z5AtD0E5yoAmRiP3ISuJlQg8Aj3ziX2bYtfIz7DuBAUNaWK ZqK6YGP7NRoPftoALqtRSI7nNcn7t9kH6PfgFzbPJUv4sHvGcmF0b3+C0lhoYXvEOvda CtpQ== 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=0VfDjArqEF7APsHjytCRh9ft/KnWnd1sQaFnmPl+9V8=; b=h+apvN9LUhda9A3GQ14iBlWpO6J4cVIetgCvJM5sJtHluscqOl+fHzsSaDNRooAiX+ p7UjFskE1TI2cfLxA4pyxetyZvcADp5cQ/fbkAMMg9ZYn9tIz8geek0NOKUdyfuUPwiw /fShQr2Cg9CYlcKFn8SCwMu3TkpQW7HmQns344WaNALQmL2+DoXHCsGaGDg4QzVhWJfU l3AjHNuwlbjpDwXgb3InAHoCTeyvnVHFKSkWA3Ak+caLTWh3cq0rnusHmFTeEG6DU7ei W+dSm8WhoDrQ+7inMtQP+aMNLm0vGhyKNAIRVofzv+UZtIET34qZUKg8uWLofYavuauR 05nA== X-Gm-Message-State: AMCzsaU4BNPCsNgbwNUHaL+mfmA8amETHzZP5lmIu32WwKenmw+nxZxV MjRHYF84NdEyvFNvUSVi0ie7FMph0vtG9phuFSiN6A== X-Google-Smtp-Source: AOwi7QAXBc7/tXqdvAQydqXYcSMjYV3TUwuE6MpVhvEftD7Z6ILsyYihpL+N7a7FEOSDXgQRbO4MIB90R+nqvIP37+E= X-Received: by 10.31.63.1 with SMTP id m1mr1866483vka.7.1507359019029; Fri, 06 Oct 2017 23:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.160.149 with HTTP; Fri, 6 Oct 2017 23:50:18 -0700 (PDT) From: Alexandru Elisei Date: Sat, 7 Oct 2017 09:50:18 +0300 Message-ID: Subject: bhyve on ARMv8 - initarm() and struct arm64_bootparams To: 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, 07 Oct 2017 06:50:21 -0000 Hello, I am currently working on porting bhyve to ARMv8 and I've managed to start a guest kernel inside bhyve. I am having trouble getting past the initarm() function in the guest and I think the problem is the fact that I am not sending the correct boot parameter arm64_bootparams->modulep to the guest (the other struct variables are computed in locore.S before calling initarm()). As far as I can I can tell modulep is a pointer to the mapped kernel image virtual address where module information is stored, but I don't know how to get that information from the guest kernel when creating the virtual machine. Can anyone provide some help with this issue? Thank you, Alex From owner-freebsd-arm@freebsd.org Sat Oct 7 16:51:30 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 411C1E3C63E for ; Sat, 7 Oct 2017 16:51:30 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD1182580 for ; Sat, 7 Oct 2017 16:51:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id cd5175f3; Sat, 7 Oct 2017 18:51:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=l9CbWy1+Ac/A CeKr59dI6tzJtuE=; b=qJ5G2GwJx4eEIF/wRCY1mFSM9kAV05uDVBFs8B0AnTt/ 0JMoB88c5WXJH/O/ZkuVkjQFOi8u9ldAEHKyUi0Mj9ggDYePnDOoiSFnD+BU+PXE mJixnGgWlHL/bao/0Fn8N/SRVGN1r/KBE9KPY4qHNmerIGsJ52tZwjGHSq8LjqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=Vb4UET xB02uFbQovwMz7x7VzKkUfrcJfeRmfw2AOC5qubyMRv/nJXHpzyUB0T1ru3/tEw5 uEqmDG/sQDzfr0sp8XefCyhJADf4AfNkQIqkK7hrozinGrhFJvM0DsOUznjDeSib wbUE2Xd6nUFGP+AxWIiMkWLlYsFlsCxjqzyg0= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e2ae9c77 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 7 Oct 2017 18:51:20 +0200 (CEST) Date: Sat, 7 Oct 2017 18:51:16 +0200 From: Emmanuel Vadot To: Michael Hrabanek , freebsd-arm@freebsd.org Subject: Re: Allwinner H3 (NanoPi Neo): Getting PORTL (on /dev/gpioc1) to work Message-Id: <20171007185116.6aa97faf3511ebf90a06301d@bidouilliste.com> In-Reply-To: <20171003133901.1de20ce9637720671eee3d33@bidouilliste.com> References: <20170921082259.aa46e554e653ce7bf2d403b2@bidouilliste.com> <20171003133901.1de20ce9637720671eee3d33@bidouilliste.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Sat, 07 Oct 2017 16:51:30 -0000 Hello, On Tue, 3 Oct 2017 13:39:01 +0200 Emmanuel Vadot wrote: > On Tue, 3 Oct 2017 13:27:47 +0200 > Michael Hrabanek wrote: > > > Hello, > > any updates? If you'll need any testing done I'd be happy to help > > > > Cheers, > > Michael > > I've fixed our gpio driver to not attach if we cannot enable one of > the needed clocks. > Now I need to code the clock driver for H3, it seems that there is no > docs so it will take some time. I commited the driver in r324383, let me know if you have any problems. Cheers, -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Oct 7 18:24: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 B35CEE3E885 for ; Sat, 7 Oct 2017 18:24:08 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 0D88B752E6 for ; Sat, 7 Oct 2017 18:24:07 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id u138so13587406wmu.5 for ; Sat, 07 Oct 2017 11:24:07 -0700 (PDT) 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=yuavW2gezpmDO7+m4q95SoU8EN1uNuqCgbSH9lb9UuY=; b=PIQnCbd6W1zdn4RPJqkp8jo63ZpdIFDYWWqu//jTAqQiwwsPh0sYyxF/a77dYmB/sp Zct3+Gh5DK+dRN9qiENEEwJ6WTjDDEKUxE5pGOwl6MgHXc7mxWR+ULbU1/oxUlO5KkAT SiVb8oR5CytJ0MUUDTxlk61StN+QTSQ3kYNcjO4N9AXZS8pNgppqO6/rPt4J+psOEy2r AsSiDwfsdkU9iiakBpMsz6gF3WuhcdTMTpXyWv0aE7JSyUzLdhpI+jHg2pJiLhLOvHwN dHu0aGRs//gkSMWtdZ4ClVpKPj/tbXhFqqOAztcNsU/ajWMDagtrjNRYWf46mdzqhnfJ hEsg== 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=yuavW2gezpmDO7+m4q95SoU8EN1uNuqCgbSH9lb9UuY=; b=laLVjHNqtBO4kVfh/W2eovEGRVcVoiM7AOm7sOQuHocd2RTUu2piTR+h569yjkTvJ0 EWvLC6ZBuhez5z9lJoj3RPyjD36YgCmOkCLyx8USKiqsfMIdiXzz93qwldQ5ZnMjKCHK RF//0BA4JdVXU50pZe/DIshYNoVckm8TJdgRfz0owNAjA9cdCllZF+aIOqhn6K9MFg7u 3syJtDA3FFLQJX0A5A79a1CkcpRKJVzuVEzqy2DvCLtIc8jM5iHl6wAc+F/GIRGDz+yZ HewMaXGjQNtl8j7DqKlzIYx4SGyCsLF7R4qF88MCrMxQ3fg6QUFSZVHNRW4iA/xHKhAx fB8w== X-Gm-Message-State: AMCzsaVmY/5Ps637FV13kNZXG1tk2NW1XAJlva1PmFCXOAdaZ0jxs4Cs CtPPwwsv1Gw0YNtluQUHBT9DL9TY9S+Lj8Cs7CmVOg== X-Google-Smtp-Source: AOwi7QC9dOMb0wz9OoB1WAsMY4gB6KdjWISwGqklCRy5tkhCHh82j7r+veY+rP6buH1kZBNLpzMEs0DQ0OKcYuJ10UM= X-Received: by 10.28.210.5 with SMTP id j5mr4400204wmg.15.1507400645894; Sat, 07 Oct 2017 11:24:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.197.141 with HTTP; Sat, 7 Oct 2017 11:24:05 -0700 (PDT) From: Guy Yur Date: Sat, 7 Oct 2017 21:24:05 +0300 Message-ID: Subject: armv7, building p7zip and -fPIC To: freebsd-arm 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, 07 Oct 2017 18:24:08 -0000 Hi, Does armv7 need -fPIC when compiling? Building archivers/p7zip fails with: /usr/bin/ld: 7zEncode.o(.text+0x2d04): unresolvable R_ARM_MOVW_ABS_NC relocation against symbol `_ZTIi@@CXXABI_1.3' /usr/bin/ld: final link failed: Nonrepresentable section on output c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [../../../../bin/7z.so] Error code 1 make[3]: stopped in /usr/wrkdir/usr/ports/archivers/p7zip/work/p7zip_16.02/CPP/7zip/Bundles/Format7zFree 1 error If I add "CFLAGS_armv7= -fPIC" in the port Makefile it builds fine. The port has -fPIC for aarch64, amd64, powerpc and sparc64. Is it a difference from armv6? When I previously built for armv6 it worked without the option. Thanks, Guy From owner-freebsd-arm@freebsd.org Sat Oct 7 18:40:52 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 92094E3EDC9 for ; Sat, 7 Oct 2017 18:40:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 20BB77CC31 for ; Sat, 7 Oct 2017 18:40:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id 72so4984176itl.5 for ; Sat, 07 Oct 2017 11:40:51 -0700 (PDT) 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=leUO1kk6G4L2+9qM+BOYgDMY3zcfauHi4U09Dwj333o=; b=wzA56He8oZ5bTo2kY9pSwReXpDU99dPZVul7P4/9zQNlflD4D6mhySfhk9DmIcbJvz PnISaxGI2cZkqVu5edP73GQYgMTIV+vPcFZ1pkHbrJyAakm1ihd6KkJTI0K0kzQdO3xV cF5bLUZiZiFN19lRjE8I0pL2yodNeFTkXgll9Bij+OMOOdMZLCJiD2QfQ1pGOkz8ZKRu YPDRisgDA54u/QxwA2ildQqXVpWWUXbVmB69SADFki780Sgke4phG5RXsYmfnU5QV9hq 4xUT2ju1t6/UZ9rbSfsKOF1UidFUg8uuoSGAVlGctUocuvkh9oWOBVHSdJcy9j/6lXnA b4LQ== 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=leUO1kk6G4L2+9qM+BOYgDMY3zcfauHi4U09Dwj333o=; b=JW0RB2JEDr3FPhJYzRMFWNrgBaSFSLE3Rod5qMRwNu8ulRHw8Kmd+Q/2TdC29+Sgyz LHgISsHv2QoNTHpwC1z27JN6fL6t1xvUgYGen1WLPci5D0zAE4NOltMpFKQ+iKK+SIHg VXTeb3uQmlr8WTXUxKCKL9gU3TrnJX9EDu0pzD4Ij2gFVf8Pd6jmmDXCwAdLR6ljXtsI KHbaQ0vliqENGYyiWyGvXHihckRB9oLT3x6g1Ue5Vrqe2LqwtNbKnRv3L/mGNczqp34w usjpZarQIiV2hTZXwa8QNxZ9vt6bXgRE7fRDiuk31qc8XWWJ5WO/ZDJ3sWX+zvCmeqTQ fZQQ== X-Gm-Message-State: AMCzsaWUqeK+7yiio9N6FIS0aH3rA+OneL7O74REASj392w/5yBDylF6 xuiwYK4hf8kRHMBCGYoK8UG9XN5zii56FkpAMFykJQ== X-Google-Smtp-Source: AOwi7QDQBt5R5OGk+zo9AjoJ7gn1exKjQjwi6EWObnVb6wRCgfZrlRCA7AhT/KSB8d6I4FViGRsMbeZrsQXAkJ4mO34= X-Received: by 10.36.19.207 with SMTP id 198mr7247281itz.130.1507401651151; Sat, 07 Oct 2017 11:40:51 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Sat, 7 Oct 2017 11:40:50 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:43b:1393:6fda:6aaa] In-Reply-To: References: From: Warner Losh Date: Sat, 7 Oct 2017 11:40:50 -0700 X-Google-Sender-Auth: 2fuiXFMmDPz5PdPgnGF4HcpEk0M Message-ID: Subject: Re: armv7, building p7zip and -fPIC To: Guy Yur 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: Sat, 07 Oct 2017 18:40:52 -0000 On Sat, Oct 7, 2017 at 11:24 AM, Guy Yur wrote: > Hi, > > Does armv7 need -fPIC when compiling? > > Building archivers/p7zip fails with: > /usr/bin/ld: 7zEncode.o(.text+0x2d04): unresolvable R_ARM_MOVW_ABS_NC > relocation against symbol `_ZTIi@@CXXABI_1.3' > /usr/bin/ld: final link failed: Nonrepresentable section on output > c++: error: linker command failed with exit code 1 (use -v to see > invocation) > *** [../../../../bin/7z.so] Error code 1 > > make[3]: stopped in > /usr/wrkdir/usr/ports/archivers/p7zip/work/p7zip_16.02/CPP/7zip/Bundles/ > Format7zFree > 1 error > > If I add "CFLAGS_armv7= -fPIC" in the port Makefile it builds fine. > The port has -fPIC for aarch64, amd64, powerpc and sparc64. > > Is it a difference from armv6? > When I previously built for armv6 it worked without the option. > armv7 is new in FreeBSD (two days old), and maybe you are tripping over something inside the port that optimized for it? Is there a CFLAGS+armv6=-fPIC? I don't see it with a quick grep, but you never know... If that's what it takes to fix it, maybe you should submit that to the port maintainer? Warner From owner-freebsd-arm@freebsd.org Sat Oct 7 18:59: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 A3CAEE3F330 for ; Sat, 7 Oct 2017 18:59:28 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 0B2AC80C2E for ; Sat, 7 Oct 2017 18:59:27 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id q132so14414568wmd.2 for ; Sat, 07 Oct 2017 11:59:27 -0700 (PDT) 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=GBxG7supTjnQpB05mjsxe5ZoSZv103hjzHskx0C3LA8=; b=Wgcni99LJzmXBS/6SIflPL8K/Kt7uvnRWQuocJnPzXUG4rH2re0CnoAeiwoB5m6IMh MHR6ykhVeISfDz5NyCDF9D1/hcyNXXBQQkJCLeT9d5BXSQM16hgoKclNsq9C3OXh1JG5 Fcm2SfIAbwytWIITOwz8UmuY8ekJmLo140LrPnrtTcbiM5OKVV3+GTZ/xaZZ50ESRVC8 5rVrp6iTIKa/OEGNA2+jUkjdRhcDN+Fm3T9vj95jLj6NJzRL+5pCW87lD059m5YqhT0C uAlN1+apS6gpvlr8vcgag3u4mA5pI8K9Dk+DeBo2D9XUM1+syG2z4QN3Lk/eOvo7wK4h OPVw== 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=GBxG7supTjnQpB05mjsxe5ZoSZv103hjzHskx0C3LA8=; b=srRsdTLWeoNLmimgJD9pA69BaCa2W1ETAcRIbkKmUCGqkrgBv5kBSLn2LQXMAKScST FodHhlLbBjpYdZdoKRspSotLS0ixUHFS3P3+rs/MzVq+iCDUHi4aBNwV/kHddNE3oU9D ixFc77sMoh1v4fjxwEUpzO71DIhMw6jXwY4+WZnUOFiNb7BxDVn0hzKTawn0hc1h5wdT OGMtHKeAE53b4germwEWDXJ+5ATaPDACuSh5weT6y1+LLeXTP0YKh8qYSQyRWrsLyKf7 3/4onl+WtVzgPgwWPuSftULQU2yYhD6GZzs6j+mY7njsUpQbNgvjq5cOYW0ZFbW3BGrT gtYA== X-Gm-Message-State: AMCzsaXgZYojF4vT74boGceqjwOWsLnzoefz+/XgYrAwc5gc7dVuzPAV Gk+bJc/8liza0EVuwfnSAJjeMFfBpSlP9Ovy9e2XH4+f X-Google-Smtp-Source: AOwi7QCikF7HQT0VnWzcHp3jTbPapfkdauA5xECn1C0QT5My4w0aeqeIYx2CxIUDpnT5Gr7I7+IjrebXIPayCOwEn7M= X-Received: by 10.28.210.5 with SMTP id j5mr4441051wmg.15.1507402766230; Sat, 07 Oct 2017 11:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.197.141 with HTTP; Sat, 7 Oct 2017 11:59:25 -0700 (PDT) In-Reply-To: References: From: Guy Yur Date: Sat, 7 Oct 2017 21:59:25 +0300 Message-ID: Subject: Re: armv7, building p7zip and -fPIC To: Warner Losh Cc: freebsd-arm 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, 07 Oct 2017 18:59:28 -0000 On 7 October 2017 at 21:40, Warner Losh wrote: > > > On Sat, Oct 7, 2017 at 11:24 AM, Guy Yur wrote: >> >> Hi, >> >> Does armv7 need -fPIC when compiling? >> >> Building archivers/p7zip fails with: >> /usr/bin/ld: 7zEncode.o(.text+0x2d04): unresolvable R_ARM_MOVW_ABS_NC >> relocation against symbol `_ZTIi@@CXXABI_1.3' >> /usr/bin/ld: final link failed: Nonrepresentable section on output >> c++: error: linker command failed with exit code 1 (use -v to see >> invocation) >> *** [../../../../bin/7z.so] Error code 1 >> >> make[3]: stopped in >> >> /usr/wrkdir/usr/ports/archivers/p7zip/work/p7zip_16.02/CPP/7zip/Bundles/Format7zFree >> 1 error >> >> If I add "CFLAGS_armv7= -fPIC" in the port Makefile it builds fine. >> The port has -fPIC for aarch64, amd64, powerpc and sparc64. >> >> Is it a difference from armv6? >> When I previously built for armv6 it worked without the option. > > > armv7 is new in FreeBSD (two days old), and maybe you are tripping over > something inside the port that optimized for it? Is there a > CFLAGS+armv6=-fPIC? I don't see it with a quick grep, but you never know... > If that's what it takes to fix it, maybe you should submit that to the port > maintainer? > > Warner Hi, Seems to indeed be a difference between armv6 and armv7, found this: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/503448 I will submit a patch to the port maintainer to add CFLAGS for armv7. Thanks, Guy From owner-freebsd-arm@freebsd.org Sat Oct 7 19:09:57 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 6C97AE3F839 for ; Sat, 7 Oct 2017 19:09:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 CF4228307C for ; Sat, 7 Oct 2017 19:09:56 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 03ff8b6b-ab93-11e7-b50b-53dc5ecda239 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id 03ff8b6b-ab93-11e7-b50b-53dc5ecda239; Sat, 07 Oct 2017 19:09:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v97J9lOB008939; Sat, 7 Oct 2017 13:09:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507403387.86205.286.camel@freebsd.org> Subject: Re: armv7, building p7zip and -fPIC From: Ian Lepore To: Guy Yur , Warner Losh Cc: freebsd-arm Date: Sat, 07 Oct 2017 13:09:47 -0600 In-Reply-To: References: 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: Sat, 07 Oct 2017 19:09:57 -0000 On Sat, 2017-10-07 at 21:59 +0300, Guy Yur wrote: > On 7 October 2017 at 21:40, Warner Losh wrote: > > > > > > > > On Sat, Oct 7, 2017 at 11:24 AM, Guy Yur wrote: > > > > > > > > > Hi, > > > > > > Does armv7 need -fPIC when compiling? > > > > > > Building archivers/p7zip fails with: > > > /usr/bin/ld: 7zEncode.o(.text+0x2d04): unresolvable R_ARM_MOVW_ABS_NC > > > relocation against symbol `_ZTIi@@CXXABI_1.3' > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > c++: error: linker command failed with exit code 1 (use -v to see > > > invocation) > > > *** [../../../../bin/7z.so] Error code 1 > > > > > > make[3]: stopped in > > > > > > /usr/wrkdir/usr/ports/archivers/p7zip/work/p7zip_16.02/CPP/7zip/Bundles/Format7zFree > > > 1 error > > > > > > If I add "CFLAGS_armv7= -fPIC" in the port Makefile it builds fine. > > > The port has -fPIC for aarch64, amd64, powerpc and sparc64. > > > > > > Is it a difference from armv6? > > > When I previously built for armv6 it worked without the option. > > > > armv7 is new in FreeBSD (two days old), and maybe you are tripping over > > something inside the port that optimized for it? Is there a > > CFLAGS+armv6=-fPIC? I don't see it with a quick grep, but you never know... > > If that's what it takes to fix it, maybe you should submit that to the port > > maintainer? > > > > Warner > Hi, > > Seems to indeed be a difference between armv6 and armv7, > found this: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/503448 > > I will submit a patch to the port maintainer to add CFLAGS for armv7. > > Thanks, > Guy This is really not just an armv7-only thing, the -fPIC flag should always be used.  On armv6 (and some other non-arm arches) it will accidentally work without that flag, but that doesn't make it right. --- Ian From owner-freebsd-arm@freebsd.org Sat Oct 7 20:15:23 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 CBA72E41329 for ; Sat, 7 Oct 2017 20:15:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 BAC036D7E0 for ; Sat, 7 Oct 2017 20:15:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id 72so8465008itk.3 for ; Sat, 07 Oct 2017 13:15:22 -0700 (PDT) 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=7BdA9J4L3ACvPTPVoOgosPNUpwLFqJQBP7sJDMQBvlY=; b=ekRxZylnZsxj0cKW6aMt1ZjQw0vVzm/E2MqNSAjI1ueCWcd+bXGC+QrSAGr1P/vWge C7cvv/alR13ixwmEggjaxn7Jiwkx3em6I9MoNt3xhvpkCG3Jnx+c/M8/9DZWsvdJUIrY g1vcxuJF+77JZOwxCXETRUCH/QwieCU4Sg+9mpYkh21/ZRyRZyhG8Sg+jyTZPT7nnzI7 sfDJJ5OplbZtq0llzn8vwIYCgncMFrkhl3qPi0ZWyhiuOIhQkJKcsgA73hpjWW+RuQl7 XImxpG1AydekViWQ6bCeIgXWb1FQAqcdpHj7Whw0TaQWFknf44Fa5Buf6XbG+oDqr3/G kIXg== 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=7BdA9J4L3ACvPTPVoOgosPNUpwLFqJQBP7sJDMQBvlY=; b=PDghvrx7kbOWAKequP5WXmDwNlIKSFmZWwPFDH/A5ZtGKlEtfMi4xpMuBe8jfkmVqG ZO5oYL4xihQ4/evweDAxcjF2yllXjlTkgyHSE7XbJAibRbLyR/E7IFUaVpKOYedSL1rQ 5kqlltTIHaNmbrZERDNt16sIwNuij0DfcPDZQDoXcFIyrdANSgrdTWt2HOiA3zpeTdj7 htyr36/w3YtOJnBwyHe86uMS3TWd3FFIl0LQL4sgL+rMcWruZAat0s7nXvRi9fxxF0fl 7dT92VAvmhaSqjBi4nSqSgVjKi+1j3MWdJT2xd0kryEP7t6QCk8RGiuegY6od883wtYz 0waw== X-Gm-Message-State: AMCzsaWY9Fdvb709QmBiFGJop8Fpog+blVQLW9+rrucyLIRO1e9b8M1z POh8RjLb2inM8dhkdwunn/0EHyGAIOKYnXmW1ivwQg== X-Google-Smtp-Source: AOwi7QAe82F6EaCYwg7R8tJfxfCLMnPo5MgEsqy/pwrUNHzoAz9ryA0U1+yAp6wgfVUyjVh3vuWgNB6ylJPwt8kWlJI= X-Received: by 10.36.19.207 with SMTP id 198mr7465019itz.130.1507407321901; Sat, 07 Oct 2017 13:15:21 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Sat, 7 Oct 2017 13:15:21 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:43b:1393:6fda:6aaa] In-Reply-To: <1507403387.86205.286.camel@freebsd.org> References: <1507403387.86205.286.camel@freebsd.org> From: Warner Losh Date: Sat, 7 Oct 2017 13:15:21 -0700 X-Google-Sender-Auth: IxBy4c5Ua-aqox3FhxgM_M09kNE Message-ID: Subject: Re: armv7, building p7zip and -fPIC To: Ian Lepore Cc: Guy Yur , 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: Sat, 07 Oct 2017 20:15:24 -0000 On Sat, Oct 7, 2017 at 12:09 PM, Ian Lepore wrote: > On Sat, 2017-10-07 at 21:59 +0300, Guy Yur wrote: > > On 7 October 2017 at 21:40, Warner Losh wrote: > > > > > > > > > > > > On Sat, Oct 7, 2017 at 11:24 AM, Guy Yur wrote: > > > > > > > > > > > > Hi, > > > > > > > > Does armv7 need -fPIC when compiling? > > > > > > > > Building archivers/p7zip fails with: > > > > /usr/bin/ld: 7zEncode.o(.text+0x2d04): unresolvable R_ARM_MOVW_ABS_NC > > > > relocation against symbol `_ZTIi@@CXXABI_1.3' > > > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > > > c++: error: linker command failed with exit code 1 (use -v to see > > > > invocation) > > > > *** [../../../../bin/7z.so] Error code 1 > > > > > > > > make[3]: stopped in > > > > > > > > /usr/wrkdir/usr/ports/archivers/p7zip/work/p7zip_16. > 02/CPP/7zip/Bundles/Format7zFree > > > > 1 error > > > > > > > > If I add "CFLAGS_armv7= -fPIC" in the port Makefile it builds fine. > > > > The port has -fPIC for aarch64, amd64, powerpc and sparc64. > > > > > > > > Is it a difference from armv6? > > > > When I previously built for armv6 it worked without the option. > > > > > > armv7 is new in FreeBSD (two days old), and maybe you are tripping over > > > something inside the port that optimized for it? Is there a > > > CFLAGS+armv6=-fPIC? I don't see it with a quick grep, but you never > know... > > > If that's what it takes to fix it, maybe you should submit that to the > port > > > maintainer? > > > > > > Warner > > Hi, > > > > Seems to indeed be a difference between armv6 and armv7, > > found this: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/ > 503448 > > > > I will submit a patch to the port maintainer to add CFLAGS for armv7. > > > > Thanks, > > Guy > > This is really not just an armv7-only thing, the -fPIC flag should > always be used. On armv6 (and some other non-arm arches) it will > accidentally work without that flag, but that doesn't make it right. > I've emailed the maintainer asking to apply this: diff --git a/archivers/p7zip/Makefile b/archivers/p7zip/Makefile index 9e2c2a21deec..1bf32ccd39ac 100644 --- a/archivers/p7zip/Makefile +++ b/archivers/p7zip/Makefile @@ -20,6 +20,8 @@ MAKEFILE= makefile MAKE_ARGS= OPTFLAGS="${CXXFLAGS}" WRKSRC= ${WRKDIR}/${PORTNAME}_${PORTVERSION} +CFLAGS_arm= -fPIC +CFLAGS_armv6= -fPIC CFLAGS_armv7= -fPIC CFLAGS_aarch64= -fPIC CFLAGS_amd64= -fPIC Warner From owner-freebsd-arm@freebsd.org Sat Oct 7 20:41: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 ACBF1E41F61 for ; Sat, 7 Oct 2017 20:41:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 863717330D for ; Sat, 7 Oct 2017 20:41:39 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ec7d21eb-ab9f-11e7-a937-4f970e858fdb 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.ore.mailhop.org (Halon) with ESMTPSA id ec7d21eb-ab9f-11e7-a937-4f970e858fdb; Sat, 07 Oct 2017 20:41:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v97KfVqB009069; Sat, 7 Oct 2017 14:41:31 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507408891.86205.289.camel@freebsd.org> Subject: Re: armv7, building p7zip and -fPIC From: Ian Lepore To: Warner Losh Cc: Guy Yur , freebsd-arm Date: Sat, 07 Oct 2017 14:41:31 -0600 In-Reply-To: References: <1507403387.86205.286.camel@freebsd.org> 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: Sat, 07 Oct 2017 20:41:39 -0000 On Sat, 2017-10-07 at 13:15 -0700, Warner Losh wrote: > On Sat, Oct 7, 2017 at 12:09 PM, Ian Lepore wrote: > > > > > On Sat, 2017-10-07 at 21:59 +0300, Guy Yur wrote: > > > > > > On 7 October 2017 at 21:40, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > > On Sat, Oct 7, 2017 at 11:24 AM, Guy Yur > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Does armv7 need -fPIC when compiling? > > > > > > > > > > Building archivers/p7zip fails with: > > > > > /usr/bin/ld: 7zEncode.o(.text+0x2d04): unresolvable > > > > > R_ARM_MOVW_ABS_NC > > > > > relocation against symbol `_ZTIi@@CXXABI_1.3' > > > > > /usr/bin/ld: final link failed: Nonrepresentable section on > > > > > output > > > > > c++: error: linker command failed with exit code 1 (use -v to > > > > > see > > > > > invocation) > > > > > *** [../../../../bin/7z.so] Error code 1 > > > > > > > > > > make[3]: stopped in > > > > > > > > > > /usr/wrkdir/usr/ports/archivers/p7zip/work/p7zip_16. > > 02/CPP/7zip/Bundles/Format7zFree > > > > > > > > > > > > > > > > > 1 error > > > > > > > > > > If I add "CFLAGS_armv7= -fPIC" in the port Makefile it builds > > > > > fine. > > > > > The port has -fPIC for aarch64, amd64, powerpc and sparc64. > > > > > > > > > > Is it a difference from armv6? > > > > > When I previously built for armv6 it worked without the > > > > > option. > > > > armv7 is new in FreeBSD (two days old), and maybe you are > > > > tripping over > > > > something inside the port that optimized for it? Is there a > > > > CFLAGS+armv6=-fPIC? I don't see it with a quick grep, but you > > > > never > > know... > > > > > > > > > > > If that's what it takes to fix it, maybe you should submit that > > > > to the > > port > > > > > > > > > > > maintainer? > > > > > > > > Warner > > > Hi, > > > > > > Seems to indeed be a difference between armv6 and armv7, > > > found this: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bu > > > g/ > > 503448 > > > > > > > > > I will submit a patch to the port maintainer to add CFLAGS for > > > armv7. > > > > > > Thanks, > > > Guy > > This is really not just an armv7-only thing, the -fPIC flag should > > always be used.  On armv6 (and some other non-arm arches) it will > > accidentally work without that flag, but that doesn't make it > > right. > > > I've emailed the maintainer asking to apply this: > diff --git a/archivers/p7zip/Makefile b/archivers/p7zip/Makefile > index 9e2c2a21deec..1bf32ccd39ac 100644 > --- a/archivers/p7zip/Makefile > +++ b/archivers/p7zip/Makefile > @@ -20,6 +20,8 @@ MAKEFILE=     makefile >  MAKE_ARGS=     OPTFLAGS="${CXXFLAGS}" >  WRKSRC=                ${WRKDIR}/${PORTNAME}_${PORTVERSION} > > +CFLAGS_arm=    -fPIC > +CFLAGS_armv6=  -fPIC >  CFLAGS_armv7=  -fPIC >  CFLAGS_aarch64=        -fPIC >  CFLAGS_amd64=  -fPIC > > Warner But why not just CFLAGS+= -fPIC ?  Text-segment relocations triggering COW on shared text pages aren't any better in a powerpc or i386 shared lib than arm, right? -- Ian From owner-freebsd-arm@freebsd.org Sat Oct 7 21:43:30 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 B5381E42F0C for ; Sat, 7 Oct 2017 21:43:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10EE384B69; Sat, 7 Oct 2017 21:43:29 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 7E4C7738; Sat, 7 Oct 2017 16:43:27 -0500 (CDT) Date: Sat, 7 Oct 2017 16:43:26 -0500 From: Mark Linimon To: Warner Losh Cc: Ian Lepore , freebsd-arm , linimon@FreeBSD.org Subject: Re: armv7, building p7zip and -fPIC Message-ID: <20171007214326.GA22150@lonesome.com> References: <1507403387.86205.286.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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, 07 Oct 2017 21:43:30 -0000 On Sat, Oct 07, 2017 at 01:15:21PM -0700, Warner Losh wrote: > I've emailed the maintainer asking to apply this: > > +CFLAGS_arm= -fPIC > +CFLAGS_armv6= -fPIC > CFLAGS_armv7= -fPIC Um ... maybe I'm confused, but isn't the first line a no-op? mcl From owner-freebsd-arm@freebsd.org Sat Oct 7 21:48:53 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 5FA39E4304A for ; Sat, 7 Oct 2017 21:48:53 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 676DCE1A; Sat, 7 Oct 2017 21:48:52 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id E771E738; Sat, 7 Oct 2017 16:48:50 -0500 (CDT) Date: Sat, 7 Oct 2017 16:48:49 -0500 From: Mark Linimon To: Ian Lepore Cc: Guy Yur , Warner Losh , freebsd-arm , linimon@FreeBSD.org Subject: Re: armv7, building p7zip and -fPIC Message-ID: <20171007214849.GB22150@lonesome.com> References: <1507403387.86205.286.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1507403387.86205.286.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 07 Oct 2017 21:48:53 -0000 On Sat, Oct 07, 2017 at 01:09:47PM -0600, Ian Lepore wrote: > This is really not just an armv7-only thing, the -fPIC flag should > always be used. OK, I'm going to admit some ignorance and prepare to take my beating. The last time I tried to pepper some -fPIC flags around without knowing what I was doing, I was told (in no uncertain terms) that I didn't know what I was doing. While this was true I wasn't happy with the way I was told :-) So can you please provide a "-fPIC for dummies" summary? I'll add it to the wiki. (In my old embedded systems days, we didn't need all this fancy stuff; you just stuffed your statically-linked result in the 64KB EPROM and you were done.) mcl From owner-freebsd-arm@freebsd.org Sat Oct 7 22:45:44 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 E2D2FE43E17 for ; Sat, 7 Oct 2017 22:45:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 91B636C981 for ; Sat, 7 Oct 2017 22:45:43 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 2d21d1d1-abb1-11e7-b50b-53dc5ecda239 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id 2d21d1d1-abb1-11e7-b50b-53dc5ecda239; Sat, 07 Oct 2017 22:45:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v97Mjfq6009221; Sat, 7 Oct 2017 16:45:41 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507416341.86205.291.camel@freebsd.org> Subject: Re: armv7, building p7zip and -fPIC From: Ian Lepore To: Mark Linimon , Warner Losh Cc: freebsd-arm Date: Sat, 07 Oct 2017 16:45:41 -0600 In-Reply-To: <20171007214326.GA22150@lonesome.com> References: <1507403387.86205.286.camel@freebsd.org> <20171007214326.GA22150@lonesome.com> 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: Sat, 07 Oct 2017 22:45:45 -0000 On Sat, 2017-10-07 at 16:43 -0500, Mark Linimon wrote: > On Sat, Oct 07, 2017 at 01:15:21PM -0700, Warner Losh wrote: > > > > I've emailed the maintainer asking to apply this: > > > > +CFLAGS_arm=    -fPIC > > +CFLAGS_armv6=  -fPIC > >  CFLAGS_armv7=  -fPIC > Um ... maybe I'm confused, but isn't the first line a no-op? > > mcl Not necessarily.  There probably aren't too many people building ports for arm (v4/v5), but we do so at $work (using modern ports tree and poudriere backported to freebsd 8-stable, no less). -- Ian From owner-freebsd-arm@freebsd.org Sat Oct 7 22:49:44 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 A1078E43F49 for ; Sat, 7 Oct 2017 22:49:44 +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 C97736D6D7 for ; Sat, 7 Oct 2017 22:49:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: cc944c70-abb1-11e7-a893-25625093991c 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 cc944c70-abb1-11e7-a893-25625093991c; Sat, 07 Oct 2017 22:49:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v97Mna29009242; Sat, 7 Oct 2017 16:49:36 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507416576.86205.295.camel@freebsd.org> Subject: Re: armv7, building p7zip and -fPIC From: Ian Lepore To: Mark Linimon Cc: freebsd-arm Date: Sat, 07 Oct 2017 16:49:36 -0600 In-Reply-To: <20171007214849.GB22150@lonesome.com> References: <1507403387.86205.286.camel@freebsd.org> <20171007214849.GB22150@lonesome.com> 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: Sat, 07 Oct 2017 22:49:44 -0000 On Sat, 2017-10-07 at 16:48 -0500, Mark Linimon wrote: > On Sat, Oct 07, 2017 at 01:09:47PM -0600, Ian Lepore wrote: > > > > This is really not just an armv7-only thing, the -fPIC flag should > > always be used. > OK, I'm going to admit some ignorance and prepare to take my beating. > > The last time I tried to pepper some -fPIC flags around without knowing > what I was doing, I was told (in no uncertain terms) that I didn't know > what I was doing.  While this was true I wasn't happy with the way I was > told :-) > > So can you please provide a "-fPIC for dummies" summary?  I'll add it to > the wiki. > > (In my old embedded systems days, we didn't need all this fancy stuff; > you just stuffed your statically-linked result in the 64KB EPROM and you > were done.) > > mcl > Then maybe things I don't understand well enough are in play.  I was under the impression that if you build a shared lib without -fPIC on any arch, then you end up with relocations in the text segment, requiring rtld to do writes into that segment, which triggers COW copying of the pages, at which point it's really no longer a shared library because every process has its own private copy of most/all of the text pages. Maybe some or all of that isn't true somehow on some arches. -- Ian