From owner-freebsd-arm@freebsd.org Sun Sep 25 00:19:08 2016 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 2A25BBDE2EC for ; Sun, 25 Sep 2016 00:19:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 DE7FD84E for ; Sun, 25 Sep 2016 00:19:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9165 invoked from network); 25 Sep 2016 00:12:26 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Sep 2016 00:12:26 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 24 Sep 2016 20:12:32 -0400 (EDT) Received: (qmail 28171 invoked from network); 25 Sep 2016 00:12:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Sep 2016 00:12:31 -0000 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 4D64FEC8FEB; Sat, 24 Sep 2016 17:12:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? From: Mark Millard In-Reply-To: Date: Sat, 24 Sep 2016 17:12:24 -0700 Cc: FreeBSD-STABLE Mailing List , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 00:19:08 -0000 On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: > On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard = wrote: >> [A resend since I forget to list free-arm in the To: the first time.] >>=20 >> =46rom https://www.freebsd.org/platforms/arm.html : >>=20 >>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD = project does not provide official releases or pre-built packages for = this platform due to it primarily targeting the embedded arena. However, = FreeBSD/ARM is being actively developed and maintained, is well = supported, and provides an excellent framework for building ARM-based = systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 = supports ARMv6 and ARMv7 processors, including SMP on the latter. >>=20 >> "does not provide official releases or pre-built packages"? >>=20 >>> # uname -apKU >>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: = Sun Aug 28 03:17:54 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100502 1100502 >>=20 >>> # pkg search '.*' | wc >>> 21349 155540 1596736 >>=20 >> Will 11.0-RELEASE change the tier level for any of the specific = arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files = built, such as for RPI2? >>=20 >> Even if all the officially built arm-armv6 variants stay tier 2, the = wording on the web page likely needs to be changed because so much is = built and available that the above quote claims is not available. >=20 > armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or > amd64 due to the fragmented nature of the arm world. On the platforms > we run on and create releases for, however, it's my opinion that it is > Tier 1: it has been running in production a while, things people > expect from a FreeBSD system are present, you can get decent support > if you ask questions, there's no known major gotchas in deploying this > hardware. The only remaining annoying issue is the 'u-boot' problem > where we have to have a different u-boot image for every board and no > standardized way to convert a 'generic' image into one that's specific > for specific boards. For x86 this is all done with the installer since > that boot environment is more standardized. Does this last issue keep > arm from being Tier 1? That's a judgement call, but I think the > project should promote w/o this last issue. Interesting and good to know. Thanks. I might have guessed that going along with the u-boot issue would be the = fanout in: 11.0/sys/arm/ . . . allwinner/a10/ allwinner/a20/ allwinner/a31/ allwinner/a83t/ allwinner/h3/ . . . broadcom/bcm2835/ . . . (Full list not shown.) I was thinking that this might make the tier level specific to the = status of each such directory's content so that it was the combination = of that and the sysutils/u-boot-*/ status that made the difference for = assigning the level. I'd guess that lack of a usable directory in = either place would not be tier 2 even. Similarly until the required = sys/arm/*/* and sysutils/u-boot-*/ directory-tree content have reached a = sufficiently complete status. I'd expect that there will always be a lag for what exists in the world = vs. what has these materials worked out in FreeBSD. >> Also from https://www.freebsd.org/platforms/arm.html : >>=20 >>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms = follow a set of standard conventions, and a single FreeBSD build will = work on hardware from multiple vendors. As a result, FreeBSD will = provide official releases for FreeBSD/arm64 and packages will be = available. FreeBSD/arm64 is on the path to becoming a Tier 1 = architecture. >>=20 >> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>=20 >> [I will note that, while there are no official builds for the Pine64 = family (A64 based) that are under the Allwinner arm activity, the SOC's = involved are Cortex-A53 64-bit arm based. They likely do not fit in the = "standard conventions" or arm64/aarch64 would be where they would have = been supported. Some rewording might be appropriate for the above quote = as well.] >=20 > No. aarch64 isn't Tier 1 yet. There's many small bits that are > missing. It is quite solidly Tier 2, but we don't have a linker, we > don't have widespread hardware availability, we don't have production > experience with the platform. Most things work, but there's still some > gotchas. There's still the 'u-boot' problem with many arm64 systems > because for systems that use u-boot to bootstrap UEFI, you need a > different image for each board (some closely related board families > can get by with one to be pedantic). All these issues are still > significant barriers to production use. It's not been officially > promoted yet and I don't think the time is quite right yet. Intersting as well. I'd guess that conceptually this probably would = apply to both: sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) and. . . sys/arm64/cavium/ sys/arm64/cloudabi64/ So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a = difference yet for tier level. > Warner Thanks again for the notes. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 25 04:21:09 2016 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 47033BE9707; Sun, 25 Sep 2016 04:21:09 +0000 (UTC) (envelope-from russ.haley@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 F29CBEA4; Sun, 25 Sep 2016 04:21:08 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22f.google.com with SMTP id z126so18820319vkd.0; Sat, 24 Sep 2016 21:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HR5m8jhBvw3EId8GNMY/0AwEF4ng6yUm5Kwml8joCLU=; b=LB9kOPUaP8ZwPG/EbHcn8/lziBYfTj5VpjqVrx9m/1aBVJe0G8qVTFcz/ZhxgLlDF5 NZfZ7bx+ZwOe262U9eITWjy0D3TwjNGvokHhw4jo3nxGGsnmVdDCwcqzvHUepblPHCOD GcrK1Wtr6s2J0paz2PXCjMBfSAHapuKG4KvdZtAVuaOxfX9kSYFZdjPalu146QHZndUp C6PUb5PSscKKkgvY1Y9lEkQ4fpl/V/xZZrvxuiZEnl4LCwsFH5BzK6jJVx+tptqqbBkq 4u+lbHh4jgnzqUIoJRfRNhHQrMx9O9mgTnOfxCmv/SDW8y1IdcBnAiInx09mDxk+kvRs eTzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HR5m8jhBvw3EId8GNMY/0AwEF4ng6yUm5Kwml8joCLU=; b=aEzA/aY+g0erehnIFD9QWQ3c0G5pXvS/xXpu5j2krjLg5Lo7SKC02kDqCuTAJdrXhH sxXTETEv9mmj5Q0q0xfwdvtVRDpbDbjVcFAB5ZcGfQpzRchO1p/m7bZUthkL8DknaAG4 IyuDvQ1FeC87mtVce0dJ1HdvQ5tPxf7BbSonGiQJ2t8nHQsuJ+C7CZd5lcbWju1A+Rxo l/ZQCaRRV2bpc7fSKGvETKvLd5o+r7bn7al7FGLZlZIVrqy4yHF8xt0Men7fh79UKV26 4EaIX/1y7ajnxGv6wICuKBcEbwxEyUtSIMU06+oI0Y2JydIe3azocEsnJ1NOvGPo/DIi j3jg== X-Gm-Message-State: AA6/9RlTJ6EWZTt2BEQxAGAOu4XwnnpeAlo8NnkrN0Qv8rzb3tRpH43LFI8PZzRqn2mHAnhr1uCytMY6dIcvkA== X-Received: by 10.31.242.206 with SMTP id q197mr3668053vkh.46.1474777268017; Sat, 24 Sep 2016 21:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.124.202 with HTTP; Sat, 24 Sep 2016 21:21:07 -0700 (PDT) In-Reply-To: <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> From: Russell Haley Date: Sat, 24 Sep 2016 21:21:07 -0700 Message-ID: Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? To: Mark Millard Cc: Warner Losh , freebsd-arm , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 04:21:09 -0000 On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard wrote: > On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: > >> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard wrot= e: >>> [A resend since I forget to list free-arm in the To: the first time.] >>> >>> From https://www.freebsd.org/platforms/arm.html : >>> >>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project= does not provide official releases or pre-built packages for this platform= due to it primarily targeting the embedded arena. However, FreeBSD/ARM is = being actively developed and maintained, is well supported, and provides an= excellent framework for building ARM-based systems. FreeBSD/arm supports A= RMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processor= s, including SMP on the latter. >>> >>> "does not provide official releases or pre-built packages"? >>> >>>> # uname -apKU >>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun = Aug 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr= /src/sys/RPI2-NODBG arm armv6 1100502 1100502 >>> >>>> # pkg search '.*' | wc >>>> 21349 155540 1596736 >>> >>> Will 11.0-RELEASE change the tier level for any of the specific arm-arm= v6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as = for RPI2? >>> >>> Even if all the officially built arm-armv6 variants stay tier 2, the wo= rding on the web page likely needs to be changed because so much is built a= nd available that the above quote claims is not available. >> >> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or >> amd64 due to the fragmented nature of the arm world. On the platforms >> we run on and create releases for, however, it's my opinion that it is >> Tier 1: it has been running in production a while, things people >> expect from a FreeBSD system are present, you can get decent support >> if you ask questions, there's no known major gotchas in deploying this >> hardware. The only remaining annoying issue is the 'u-boot' problem >> where we have to have a different u-boot image for every board and no >> standardized way to convert a 'generic' image into one that's specific >> for specific boards. I'll point out again that barebox is an excellent alternative to u-boot (IM= HO): - Supports most, if not all of the boards that FreeBSD supports, plus many that it doesn't - Single source tree for all boards. Specify build time parameters to build one or all the images - Well supported community with central maintainer-ship - Simple, familiar shell interface (*awesome*) - Excellent documentation (u-boots is good too though) - Has support for (U)EFI - Supports quemu aarch64 (not *quite*sure what the means though) To be fair, I'm not saying the problem is the fault of denx, but barebox has a lot going for it. The maintainer was very keen to see it ported top FreeBSD and was willing to support the effort. I ran into some build time linux api requirements, but he didn't think that would be much to overcome (and it wasn't I just kept adding the patches he sent me and the build moved forward. As always, I ran out of time for the really fun stuff). While I am a hopeless dreamer and I'm sure I've over simplified the problem, I thought it would be neat to see FreeBSD upstream support for zfs and ufs to the barebox boot loader and do away with ubldr. We would then have a modern, easy to use, boot loader that supports the standard startup toolchain. Either way, if installers move to a pkgng based method (so cool) then installing u-boot and arm binaries from pkg-static will be the same as x86 (ha ha I said that with a straight face!). >>For x86 this is all done with the installer since >> that boot environment is more standardized. Does this last issue keep >> arm from being Tier 1? That's a judgement call, but I think the >> project should promote w/o this last issue. How does a platform get promoted? Is that something the Core team decides? I see two facts about current Arm support that show platform maturity: a) u-boot is in the ports tree and we have Lego-easy build scripts in crochet that could be called an installation method. Building for arm is not difficult anymore. b)Arm requires images, not installers. Correct me if I'm wrong but, installers are a tool primarily invented for x86 PC type computers. FreeBSD publishes standardized ISOs for all supported Arm platforms that work by simply "xzcat | dd" onto the sd card (or wherever you need it). I'm not sure how standardized or manual that build process is, but I would think that if the Arm platform support is able to keep up with the standard FreeBSD release cycle (i.e. not break every other release) then there would be no reason to NOT call it tier 1? What I don't know about is "official" documentation for building for arm and supporting cross building to Arm. Will someone need to write an "Arm Handbook" to be promoted? Cheers, Russ > > Interesting and good to know. Thanks. > > I might have guessed that going along with the u-boot issue would be the = fanout in: > > 11.0/sys/arm/ . . . > > allwinner/a10/ > allwinner/a20/ > allwinner/a31/ > allwinner/a83t/ > allwinner/h3/ > . . . > broadcom/bcm2835/ > . . . > > (Full list not shown.) > > I was thinking that this might make the tier level specific to the status= of each such directory's content so that it was the combination of that an= d the sysutils/u-boot-*/ status that made the difference for assigning the = level. I'd guess that lack of a usable directory in either place would not= be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-bo= ot-*/ directory-tree content have reached a sufficiently complete status. > > I'd expect that there will always be a lag for what exists in the world v= s. what has these materials worked out in FreeBSD. > > >>> Also from https://www.freebsd.org/platforms/arm.html : >>> >>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms follo= w a set of standard conventions, and a single FreeBSD build will work on ha= rdware from multiple vendors. As a result, FreeBSD will provide official re= leases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is o= n the path to becoming a Tier 1 architecture. >>> >>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>> >>> [I will note that, while there are no official builds for the Pine64 fa= mily (A64 based) that are under the Allwinner arm activity, the SOC's invol= ved are Cortex-A53 64-bit arm based. They likely do not fit in the "standar= d conventions" or arm64/aarch64 would be where they would have been support= ed. Some rewording might be appropriate for the above quote as well.] >> >> No. aarch64 isn't Tier 1 yet. There's many small bits that are >> missing. It is quite solidly Tier 2, but we don't have a linker, we >> don't have widespread hardware availability, we don't have production >> experience with the platform. Most things work, but there's still some >> gotchas. There's still the 'u-boot' problem with many arm64 systems >> because for systems that use u-boot to bootstrap UEFI, you need a >> different image for each board (some closely related board families >> can get by with one to be pedantic). All these issues are still >> significant barriers to production use. It's not been officially >> promoted yet and I don't think the time is quite right yet. > > Intersting as well. I'd guess that conceptually this probably would apply= to both: > > sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ > (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) > > and. . . > > sys/arm64/cavium/ > sys/arm64/cloudabi64/ > > So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a di= fference yet for tier level. > >> Warner > > Thanks again for the notes. > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Sep 25 06:10:47 2016 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 2A8B5BE8B05 for ; Sun, 25 Sep 2016 06:10:47 +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 E2B2162B for ; Sun, 25 Sep 2016 06:10:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id o3so48677458ita.1 for ; Sat, 24 Sep 2016 23:10:46 -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:content-transfer-encoding; bh=uGkLDd2L62s0iz+iWbFM5qC1zvqnVU/ulEAtpR38sV8=; b=H7VMloZcBldbBRdlpytXeLIIMvgLJH/91BWZd8oQkXvszI7lh1doFw9GGQZIbFan7q z4JHkKp+jdLuLW7XF+7OS+V4ZIkcIfQ9cbiS6G8CAsD2f5UmAtsZUWYtDIx1p7sI6453 AZR4YmpogVpeH1/tS3ZxXPsHGNVtQ7kldce1a4V4fHf+nw4lBbYkdtRNpto6vnY3Pis9 7XJ1gdwwXIWgCDmq3qEWVIGRKnmMUT31OHzWPGAhcaTZMd3Hh4j6aXYfw8C3lNbgA/RY o2a0Z6Rwp+o79MOPbGXfMYktvJ5jgrKAUAdSnFiKsUKl4Ip6y0VAaxFi8TCYT9QKufDO pzLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=uGkLDd2L62s0iz+iWbFM5qC1zvqnVU/ulEAtpR38sV8=; b=GZ2YbsMEYBGwoacH+rcqXPGFJ93PlLZCrahKHyEo+B3QCZIuyUZVAyCmR+zGcR6H++ vL3iAl+1/Hdotau3xIkENScadq4jONyo2OCY91onTK8XaF8/YBPDTyNXxklm1/EWuSuU keRLINNhOxAgLCapLmXJr/wmU4lkJKQsDtK6XmLk7dU9MJOmltUQvRDLIfAA3WwF7ppj Uzuzqst04cKlZphdWt6EuaZNnYW65G5a5yyLSuV6smiL080t07uv4/xaxZIHqy65oXv1 wGB38okSm1kyWZ0RBVIQ5w9eFwVK3fEu7WDCV3OHpuRQG/7j6TMTtM9TeCSd5usSSB3i 3pKg== X-Gm-Message-State: AA6/9RnCzPq5RSkZIKvU3PBB5RV87SoGvTcJJ1xu9sBgVZbCgy7YTwKxcDjT3B5MeDMAlZIVm0vtK/3/VpPpBA== X-Received: by 10.36.58.133 with SMTP id m127mr931821itm.79.1474783845897; Sat, 24 Sep 2016 23:10:45 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Sat, 24 Sep 2016 23:10:45 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> From: Warner Losh Date: Sun, 25 Sep 2016 00:10:45 -0600 X-Google-Sender-Auth: 2ppeaJ_eoltWttM19XyzCBbiCKo Message-ID: Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? To: Russell Haley Cc: Mark Millard , freebsd-arm , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 06:10:47 -0000 On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley wrot= e: > On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard wrote= : >> On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: >> >>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard wro= te: >>>> [A resend since I forget to list free-arm in the To: the first time.] >>>> >>>> From https://www.freebsd.org/platforms/arm.html : >>>> >>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD projec= t does not provide official releases or pre-built packages for this platfor= m due to it primarily targeting the embedded arena. However, FreeBSD/ARM is= being actively developed and maintained, is well supported, and provides a= n excellent framework for building ARM-based systems. FreeBSD/arm supports = ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processo= rs, including SMP on the latter. >>>> >>>> "does not provide official releases or pre-built packages"? >>>> >>>>> # uname -apKU >>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun= Aug 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/us= r/src/sys/RPI2-NODBG arm armv6 1100502 1100502 >>>> >>>>> # pkg search '.*' | wc >>>>> 21349 155540 1596736 >>>> >>>> Will 11.0-RELEASE change the tier level for any of the specific arm-ar= mv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as= for RPI2? >>>> >>>> Even if all the officially built arm-armv6 variants stay tier 2, the w= ording on the web page likely needs to be changed because so much is built = and available that the above quote claims is not available. >>> >>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or >>> amd64 due to the fragmented nature of the arm world. On the platforms >>> we run on and create releases for, however, it's my opinion that it is >>> Tier 1: it has been running in production a while, things people >>> expect from a FreeBSD system are present, you can get decent support >>> if you ask questions, there's no known major gotchas in deploying this >>> hardware. The only remaining annoying issue is the 'u-boot' problem >>> where we have to have a different u-boot image for every board and no >>> standardized way to convert a 'generic' image into one that's specific >>> for specific boards. > > I'll point out again that barebox is an excellent alternative to u-boot (= IMHO): Doesn't matter, still has the same issues that u-boot has. But does it support the u-boot ABI? > - Supports most, if not all of the boards that FreeBSD supports, plus > many that it doesn't > - Single source tree for all boards. Specify build time parameters to > build one or all the images > - Well supported community with central maintainer-ship > - Simple, familiar shell interface (*awesome*) > - Excellent documentation (u-boots is good too though) > - Has support for (U)EFI > - Supports quemu aarch64 (not *quite*sure what the means though) Right, u-boot has all these things, except maybe the shell interface (not sure what you mean by that). > To be fair, I'm not saying the problem is the fault of denx, but > barebox has a lot going for it. The maintainer was very keen to see it > ported top FreeBSD and was willing to support the effort. I ran into > some build time linux api requirements, but he didn't think that would > be much to overcome (and it wasn't I just kept adding the patches he > sent me and the build moved forward. As always, I ran out of time for > the really fun stuff). While I am a hopeless dreamer and I'm sure I've > over simplified the problem, I thought it would be neat to see FreeBSD > upstream support for zfs and ufs to the barebox boot loader and do > away with ubldr. We would then have a modern, easy to use, boot loader > that supports the standard startup toolchain. We can't easily do away with ubldr if we want to support tunables, kernel modules loaded at boot time and a few other nifty features like nextboot. > Either way, if installers move to a pkgng based method (so cool) then > installing u-boot and arm binaries from pkg-static will be the same as > x86 (ha ha I said that with a straight face!). Yea, not so much. You have to build the bootable image not on the target system, like you do on x86. We'd have to have something that installs uboot onto a generic image (perhaps with hooks for kernels since those aren't generic on armv6) and then put that into a bootable SD card. >>>For x86 this is all done with the installer since >>> that boot environment is more standardized. Does this last issue keep >>> arm from being Tier 1? That's a judgement call, but I think the >>> project should promote w/o this last issue. > > How does a platform get promoted? Is that something the Core team decides= ? Yes. > I see two facts about current Arm support that show platform maturity: > a) u-boot is in the ports tree and we have Lego-easy build scripts in > crochet that could be called an installation method. Building for arm > is not difficult anymore. Except corchet isn't in the tree, and the solution is horrible. It's a script for each SoC, and those scripts are now scattered about. Plus that's a creation from source model, not a creation from RE produced bits model, which is needed for Tier 1. > b)Arm requires images, not installers. Correct me if I'm wrong but, > installers are a tool primarily invented for x86 PC type computers. > FreeBSD publishes standardized ISOs for all supported Arm platforms > that work by simply "xzcat | dd" onto the sd card (or wherever you > need it). I'm not sure how standardized or manual that build process > is, but I would think that if the Arm platform support is able to keep > up with the standard FreeBSD release cycle (i.e. not break every other > release) then there would be no reason to NOT call it tier 1? Creating the images is currently a pita. That's it. > What I don't know about is "official" documentation for building for > arm and supporting cross building to Arm. Will someone need to write > an "Arm Handbook" to be promoted? No. While useful, most of that already exists. Warner >> Interesting and good to know. Thanks. >> >> I might have guessed that going along with the u-boot issue would be the= fanout in: >> >> 11.0/sys/arm/ . . . >> >> allwinner/a10/ >> allwinner/a20/ >> allwinner/a31/ >> allwinner/a83t/ >> allwinner/h3/ >> . . . >> broadcom/bcm2835/ >> . . . >> >> (Full list not shown.) >> >> I was thinking that this might make the tier level specific to the statu= s of each such directory's content so that it was the combination of that a= nd the sysutils/u-boot-*/ status that made the difference for assigning the= level. I'd guess that lack of a usable directory in either place would no= t be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-b= oot-*/ directory-tree content have reached a sufficiently complete status. >> >> I'd expect that there will always be a lag for what exists in the world = vs. what has these materials worked out in FreeBSD. >> >> >>>> Also from https://www.freebsd.org/platforms/arm.html : >>>> >>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms foll= ow a set of standard conventions, and a single FreeBSD build will work on h= ardware from multiple vendors. As a result, FreeBSD will provide official r= eleases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is = on the path to becoming a Tier 1 architecture. >>>> >>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>>> >>>> [I will note that, while there are no official builds for the Pine64 f= amily (A64 based) that are under the Allwinner arm activity, the SOC's invo= lved are Cortex-A53 64-bit arm based. They likely do not fit in the "standa= rd conventions" or arm64/aarch64 would be where they would have been suppor= ted. Some rewording might be appropriate for the above quote as well.] >>> >>> No. aarch64 isn't Tier 1 yet. There's many small bits that are >>> missing. It is quite solidly Tier 2, but we don't have a linker, we >>> don't have widespread hardware availability, we don't have production >>> experience with the platform. Most things work, but there's still some >>> gotchas. There's still the 'u-boot' problem with many arm64 systems >>> because for systems that use u-boot to bootstrap UEFI, you need a >>> different image for each board (some closely related board families >>> can get by with one to be pedantic). All these issues are still >>> significant barriers to production use. It's not been officially >>> promoted yet and I don't think the time is quite right yet. >> >> Intersting as well. I'd guess that conceptually this probably would appl= y to both: >> >> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ >> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) >> >> and. . . >> >> sys/arm64/cavium/ >> sys/arm64/cloudabi64/ >> >> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a d= ifference yet for tier level. >> >>> Warner >> >> Thanks again for the notes. >> >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Sep 25 07:13:34 2016 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 EFEABBE97D4; Sun, 25 Sep 2016 07:13:34 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA9D71AC; Sun, 25 Sep 2016 07:13:34 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-ua0-x230.google.com with SMTP id q42so80503861uaq.1; Sun, 25 Sep 2016 00:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3w18S6CCpMbBbLQxKd8MkMZ4N+6E7eGEY06c06Td6pU=; b=PTl/HldNjG7KiUs5wNtM0cJ+lhvcsw93zL7vgz224BD/yU/MmsPxHAQuv6Iveuv6p0 ra15D6naSj8E53PANRefr/Qxr4JF6YtBYZ+BlNo5vzHAnjOIRwCPrk3t7e5oCkTyLPmC HNcIA7Jvpu2ZYHhy1uvDK3hs2Eeuzh26/GXvrEOQUGx15j/2J5BXTQimUo4J4Kmi8zrJ qCfB7wI0muhzRKfO8j6wNKPJxBSurfrpDRYk4jsP3B65U3JqZZRCfnyT7YzKPJsoGgWc jSeBb08KgsVDvGDrwU0Eya6M4BhLUIGSFX9cWbPXCN9jTvLtUzYMwBHiK+wm+HoPI1NC p7aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3w18S6CCpMbBbLQxKd8MkMZ4N+6E7eGEY06c06Td6pU=; b=EDjEi3vxlwwptxgugmnxDZP5qruis0vAU0eY2CgMs6kk+Ra4tvvKX30PodvEZArghi 8GiJiuKKHl9L5j67zr+bKk5GUjb2b0Oo3JNFJSP8p3Bac/h5yVkd6o8xoC4RSJPaT4Ko BsvZPl55VBw5VyOtFTc+Qo1MqJ0CUiBrlz4jKXYFSTW96rFEcMax1S1exKx8n3hbbzGV 2tGEixTOJi/pU536ah2Zi85g4h5Ivnk8aG53hn7wB+L7f5fJrtiqcnkE3Fdcbi7WhZOJ uLsPTBLian5nG9CNuFYFRKScCbCrLGey+ymUujfqDWTNudS2PxxhnByEPG5pqqjv3kAM vlOA== X-Gm-Message-State: AA6/9Rnbm1pfW2+SabB+2ADBqYVgn+xQxd4SNag1W4oC3Oc9kI8jPxGfXhMlclM5CiwjwungLRl1EXyT9EIVFA== X-Received: by 10.176.3.197 with SMTP id 63mr7815345uau.149.1474787613540; Sun, 25 Sep 2016 00:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.124.202 with HTTP; Sun, 25 Sep 2016 00:13:31 -0700 (PDT) In-Reply-To: References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> From: Russell Haley Date: Sun, 25 Sep 2016 00:13:31 -0700 Message-ID: Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? To: Warner Losh Cc: Mark Millard , freebsd-arm , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 07:13:35 -0000 On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh wrote: > On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley wr= ote: >> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard wrot= e: >>> On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: >>> >>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard wr= ote: >>>>> [A resend since I forget to list free-arm in the To: the first time.] >>>>> >>>>> From https://www.freebsd.org/platforms/arm.html : >>>>> >>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD proje= ct does not provide official releases or pre-built packages for this platfo= rm due to it primarily targeting the embedded arena. However, FreeBSD/ARM i= s being actively developed and maintained, is well supported, and provides = an excellent framework for building ARM-based systems. FreeBSD/arm supports= ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 process= ors, including SMP on the latter. >>>>> >>>>> "does not provide official releases or pre-built packages"? >>>>> >>>>>> # uname -apKU >>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Su= n Aug 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/u= sr/src/sys/RPI2-NODBG arm armv6 1100502 1100502 >>>>> >>>>>> # pkg search '.*' | wc >>>>>> 21349 155540 1596736 >>>>> >>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-a= rmv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such a= s for RPI2? >>>>> >>>>> Even if all the officially built arm-armv6 variants stay tier 2, the = wording on the web page likely needs to be changed because so much is built= and available that the above quote claims is not available. >>>> >>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or >>>> amd64 due to the fragmented nature of the arm world. On the platforms >>>> we run on and create releases for, however, it's my opinion that it is >>>> Tier 1: it has been running in production a while, things people >>>> expect from a FreeBSD system are present, you can get decent support >>>> if you ask questions, there's no known major gotchas in deploying this >>>> hardware. The only remaining annoying issue is the 'u-boot' problem >>>> where we have to have a different u-boot image for every board and no >>>> standardized way to convert a 'generic' image into one that's specific >>>> for specific boards. >> >> I'll point out again that barebox is an excellent alternative to u-boot = (IMHO): > > Doesn't matter, still has the same issues that u-boot has. u-boot has a different sources for almost each board we support (due to the usual FOSS issues). That is NOT the case in barebox. There is one source and it's kept up to date by the team, not the vendors. > But does it support the u-boot ABI? I'd have to look into this. > >> - Supports most, if not all of the boards that FreeBSD supports, plus >> many that it doesn't >> - Single source tree for all boards. Specify build time parameters to >> build one or all the images >> - Well supported community with central maintainer-ship >> - Simple, familiar shell interface (*awesome*) >> - Excellent documentation (u-boots is good too though) >> - Has support for (U)EFI >> - Supports quemu aarch64 (not *quite*sure what the means though) > > Right, u-boot has all these things, except maybe the shell interface > (not sure what you mean by that). Instead of stringing together variables and commands, it uses a scripting language like a simplified sh. Want to change how something boots? Update a script. Save it to disk (it has it's own persistence mechanisms) and export it. >> To be fair, I'm not saying the problem is the fault of denx, but >> barebox has a lot going for it. The maintainer was very keen to see it >> ported top FreeBSD and was willing to support the effort. I ran into >> some build time linux api requirements, but he didn't think that would >> be much to overcome (and it wasn't I just kept adding the patches he >> sent me and the build moved forward. As always, I ran out of time for >> the really fun stuff). While I am a hopeless dreamer and I'm sure I've >> over simplified the problem, I thought it would be neat to see FreeBSD >> upstream support for zfs and ufs to the barebox boot loader and do >> away with ubldr. We would then have a modern, easy to use, boot loader >> that supports the standard startup toolchain. > > We can't easily do away with ubldr if we want to support tunables, kernel > modules loaded at boot time and a few other nifty features like nextboot. Are these things not in standard loader? Should they be? >> Either way, if installers move to a pkgng based method (so cool) then >> installing u-boot and arm binaries from pkg-static will be the same as >> x86 (ha ha I said that with a straight face!). > > Yea, not so much. You have to build the bootable image not on the > target system, like you do on x86. Doesn't the current ports and packages cross build everything that's marked= ? > We'd have to have something that > installs uboot onto a generic image (perhaps with hooks for kernels > since those aren't generic on armv6) and then put that into a bootable > SD card. The x86 installer (that I argue is a platform legacy) has to customize the bootloader for each installation. If we HAVE to use an installer on arm, what wrong prompting the user for some input (i.e. what som are you using) while including all the u-boots in the ports tree and all the supported kernels, then just installing the correct ones for the board (with input from the user)? >>>>For x86 this is all done with the installer since >>>> that boot environment is more standardized. Does this last issue keep >>>> arm from being Tier 1? That's a judgement call, but I think the >>>> project should promote w/o this last issue. >> >> How does a platform get promoted? Is that something the Core team decide= s? > > Yes. > >> I see two facts about current Arm support that show platform maturity: >> a) u-boot is in the ports tree and we have Lego-easy build scripts in >> crochet that could be called an installation method. Building for arm >> is not difficult anymore. > > Except corchet isn't in the tree, and the solution is horrible. It's > a script for each SoC, and those scripts are now scattered about. > Plus that's a creation from source model, not a creation from > RE produced bits model, which is needed for Tier 1. Both correctable sins, especially as it's BSD licensed. My point was that even building a SOM specific image is relatively painless with the right scripts. Hell, I've even got a custom build script that could be modified for generic use. >> b)Arm requires images, not installers. Correct me if I'm wrong but, >> installers are a tool primarily invented for x86 PC type computers. >> FreeBSD publishes standardized ISOs for all supported Arm platforms >> that work by simply "xzcat | dd" onto the sd card (or wherever you >> need it). I'm not sure how standardized or manual that build process >> is, but I would think that if the Arm platform support is able to keep >> up with the standard FreeBSD release cycle (i.e. not break every other >> release) then there would be no reason to NOT call it tier 1? > > Creating the images is currently a pita. That's it. I see. So not so mature. >> What I don't know about is "official" documentation for building for >> arm and supporting cross building to Arm. Will someone need to write >> an "Arm Handbook" to be promoted? > > No. While useful, most of that already exists. Thanks for the response Warner, I always appreciate the chance to learn more about FreeBSD. Russ > Warner > >>> Interesting and good to know. Thanks. >>> >>> I might have guessed that going along with the u-boot issue would be th= e fanout in: >>> >>> 11.0/sys/arm/ . . . >>> >>> allwinner/a10/ >>> allwinner/a20/ >>> allwinner/a31/ >>> allwinner/a83t/ >>> allwinner/h3/ >>> . . . >>> broadcom/bcm2835/ >>> . . . >>> >>> (Full list not shown.) >>> >>> I was thinking that this might make the tier level specific to the stat= us of each such directory's content so that it was the combination of that = and the sysutils/u-boot-*/ status that made the difference for assigning th= e level. I'd guess that lack of a usable directory in either place would n= ot be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-= boot-*/ directory-tree content have reached a sufficiently complete status. >>> >>> I'd expect that there will always be a lag for what exists in the world= vs. what has these materials worked out in FreeBSD. >>> >>> >>>>> Also from https://www.freebsd.org/platforms/arm.html : >>>>> >>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms fol= low a set of standard conventions, and a single FreeBSD build will work on = hardware from multiple vendors. As a result, FreeBSD will provide official = releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is= on the path to becoming a Tier 1 architecture. >>>>> >>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>>>> >>>>> [I will note that, while there are no official builds for the Pine64 = family (A64 based) that are under the Allwinner arm activity, the SOC's inv= olved are Cortex-A53 64-bit arm based. They likely do not fit in the "stand= ard conventions" or arm64/aarch64 would be where they would have been suppo= rted. Some rewording might be appropriate for the above quote as well.] >>>> >>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are >>>> missing. It is quite solidly Tier 2, but we don't have a linker, we >>>> don't have widespread hardware availability, we don't have production >>>> experience with the platform. Most things work, but there's still some >>>> gotchas. There's still the 'u-boot' problem with many arm64 systems >>>> because for systems that use u-boot to bootstrap UEFI, you need a >>>> different image for each board (some closely related board families >>>> can get by with one to be pedantic). All these issues are still >>>> significant barriers to production use. It's not been officially >>>> promoted yet and I don't think the time is quite right yet. >>> >>> Intersting as well. I'd guess that conceptually this probably would app= ly to both: >>> >>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ >>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) >>> >>> and. . . >>> >>> sys/arm64/cavium/ >>> sys/arm64/cloudabi64/ >>> >>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a = difference yet for tier level. >>> >>>> Warner >>> >>> Thanks again for the notes. >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Sep 25 09:06:19 2016 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 0BF8FBE97EA; Sun, 25 Sep 2016 09:06:19 +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 6F50161A; Sun, 25 Sep 2016 09:06:17 +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 e1f576f8; Sun, 25 Sep 2016 10:59:34 +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=Q/AEsWSuJ7fPslsjr+gDPT7sa3I=; b=FsTM63OtxNLGwlKEPGy2I6zlnh0L LFPckQOmuM50VPx2G8iypvuFxdK3UXtRQBD9xqQRmaV4P9V/u6zNwm6yUYPiHI5s f4yhr4cFFZrUwRnhhl5dcK4Od1JPtVEK/TNOI6KexI/YmmcBz+XGvNXCnYHlxg2y CXlianbQqNgvFKs= 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=oabMqTLMB2cjHXnrsUiIy/IYmcS/M4+1n9DzCNdZv/vn2MH68kwybjV0 IKthBV+DcUQaxrXJ3fnqVCLGLYrevPc7x0ToPb3da/TqNrT41Z+kO3SczzmNgoTY z9uaMbJNuuq5yv5+fuUTV3E/mI3mxU2Q0oznXhoFpvA+4dLOxrQ= Received: from knuckles.blih.net (free-229-194.mediaworksit.net [109.111.229.194]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e737a702 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 25 Sep 2016 10:59:33 +0200 (CEST) Date: Sun, 25 Sep 2016 10:59:30 +0200 From: Emmanuel Vadot To: Russell Haley Cc: Warner Losh , freebsd-arm , FreeBSD-STABLE Mailing List , Mark Millard Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? Message-Id: <20160925105930.2039e17f47a177a7465c9ee7@bidouilliste.com> In-Reply-To: References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 09:06:19 -0000 On Sun, 25 Sep 2016 00:13:31 -0700 Russell Haley wrote: > On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh wrote: > > On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley wrote: > >> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard wrote: > >>> On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: > >>> > >>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard wrote: > >>>>> [A resend since I forget to list free-arm in the To: the first time.] > >>>>> > >>>>> From https://www.freebsd.org/platforms/arm.html : > >>>>> > >>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. However, FreeBSD/ARM is being actively developed and maintained, is well supported, and provides an excellent framework for building ARM-based systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processors, including SMP on the latter. > >>>>> > >>>>> "does not provide official releases or pre-built packages"? > >>>>> > >>>>>> # uname -apKU > >>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun Aug 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm armv6 1100502 1100502 > >>>>> > >>>>>> # pkg search '.*' | wc > >>>>>> 21349 155540 1596736 > >>>>> > >>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as for RPI2? > >>>>> > >>>>> Even if all the officially built arm-armv6 variants stay tier 2, the wording on the web page likely needs to be changed because so much is built and available that the above quote claims is not available. > >>>> > >>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or > >>>> amd64 due to the fragmented nature of the arm world. On the platforms > >>>> we run on and create releases for, however, it's my opinion that it is > >>>> Tier 1: it has been running in production a while, things people > >>>> expect from a FreeBSD system are present, you can get decent support > >>>> if you ask questions, there's no known major gotchas in deploying this > >>>> hardware. The only remaining annoying issue is the 'u-boot' problem > >>>> where we have to have a different u-boot image for every board and no > >>>> standardized way to convert a 'generic' image into one that's specific > >>>> for specific boards. > >> > >> I'll point out again that barebox is an excellent alternative to u-boot (IMHO): > > > > Doesn't matter, still has the same issues that u-boot has. > u-boot has a different sources for almost each board we support (due > to the usual FOSS issues). That is NOT the case in barebox. There is > one source and it's kept up to date by the team, not the vendors. This is not true, U-Boot support all the platforms we are running on right now in a single source tree. I think that the only ports that is not using the main U-Boot is the wandboard one and I think that Warner have it working now. > > But does it support the u-boot ABI? > I'd have to look into this. > > > >> - Supports most, if not all of the boards that FreeBSD supports, plus > >> many that it doesn't > >> - Single source tree for all boards. Specify build time parameters to > >> build one or all the images > >> - Well supported community with central maintainer-ship > >> - Simple, familiar shell interface (*awesome*) > >> - Excellent documentation (u-boots is good too though) > >> - Has support for (U)EFI > >> - Supports quemu aarch64 (not *quite*sure what the means though) > > > > Right, u-boot has all these things, except maybe the shell interface > > (not sure what you mean by that). > Instead of stringing together variables and commands, it uses a > scripting language like a simplified sh. Want to change how something > boots? Update a script. Save it to disk (it has it's own persistence > mechanisms) and export it. You can do the same with U-Boot. > >> To be fair, I'm not saying the problem is the fault of denx, but > >> barebox has a lot going for it. The maintainer was very keen to see it > >> ported top FreeBSD and was willing to support the effort. I ran into > >> some build time linux api requirements, but he didn't think that would > >> be much to overcome (and it wasn't I just kept adding the patches he > >> sent me and the build moved forward. As always, I ran out of time for > >> the really fun stuff). While I am a hopeless dreamer and I'm sure I've > >> over simplified the problem, I thought it would be neat to see FreeBSD > >> upstream support for zfs and ufs to the barebox boot loader and do > >> away with ubldr. We would then have a modern, easy to use, boot loader > >> that supports the standard startup toolchain. > > > > We can't easily do away with ubldr if we want to support tunables, kernel > > modules loaded at boot time and a few other nifty features like nextboot. > > Are these things not in standard loader? Should they be? They are in the standard loader, using ubldr,loader or loader.efi doesn't matter but we have to use one of them. > >> Either way, if installers move to a pkgng based method (so cool) then > >> installing u-boot and arm binaries from pkg-static will be the same as > >> x86 (ha ha I said that with a straight face!). > > > > Yea, not so much. You have to build the bootable image not on the > > target system, like you do on x86. > > Doesn't the current ports and packages cross build everything that's marked? > > > We'd have to have something that > > installs uboot onto a generic image (perhaps with hooks for kernels > > since those aren't generic on armv6) and then put that into a bootable > > SD card. > > The x86 installer (that I argue is a platform legacy) has to customize > the bootloader for each installation. If we HAVE to use an installer > on arm, what wrong prompting the user for some input (i.e. what som > are you using) while including all the u-boots in the ports tree and > all the supported kernels, then just installing the correct ones for > the board (with input from the user)? > > >>>>For x86 this is all done with the installer since > >>>> that boot environment is more standardized. Does this last issue keep > >>>> arm from being Tier 1? That's a judgement call, but I think the > >>>> project should promote w/o this last issue. > >> > >> How does a platform get promoted? Is that something the Core team decides? > > > > Yes. > > > >> I see two facts about current Arm support that show platform maturity: > >> a) u-boot is in the ports tree and we have Lego-easy build scripts in > >> crochet that could be called an installation method. Building for arm > >> is not difficult anymore. > > > > Except corchet isn't in the tree, and the solution is horrible. It's > > a script for each SoC, and those scripts are now scattered about. > > Plus that's a creation from source model, not a creation from > > RE produced bits model, which is needed for Tier 1. > Both correctable sins, especially as it's BSD licensed. My point was > that even building a SOM specific image is relatively painless with > the right scripts. Hell, I've even got a custom build script that > could be modified for generic use. > > >> b)Arm requires images, not installers. Correct me if I'm wrong but, > >> installers are a tool primarily invented for x86 PC type computers. > >> FreeBSD publishes standardized ISOs for all supported Arm platforms > >> that work by simply "xzcat | dd" onto the sd card (or wherever you > >> need it). I'm not sure how standardized or manual that build process > >> is, but I would think that if the Arm platform support is able to keep > >> up with the standard FreeBSD release cycle (i.e. not break every other > >> release) then there would be no reason to NOT call it tier 1? > > > > Creating the images is currently a pita. That's it. > I see. So not so mature. > > >> What I don't know about is "official" documentation for building for > >> arm and supporting cross building to Arm. Will someone need to write > >> an "Arm Handbook" to be promoted? > > > > No. While useful, most of that already exists. > > Thanks for the response Warner, I always appreciate the chance to > learn more about FreeBSD. > Russ > > > Warner > > > >>> Interesting and good to know. Thanks. > >>> > >>> I might have guessed that going along with the u-boot issue would be the fanout in: > >>> > >>> 11.0/sys/arm/ . . . > >>> > >>> allwinner/a10/ > >>> allwinner/a20/ > >>> allwinner/a31/ > >>> allwinner/a83t/ > >>> allwinner/h3/ > >>> . . . > >>> broadcom/bcm2835/ > >>> . . . > >>> > >>> (Full list not shown.) > >>> > >>> I was thinking that this might make the tier level specific to the status of each such directory's content so that it was the combination of that and the sysutils/u-boot-*/ status that made the difference for assigning the level. I'd guess that lack of a usable directory in either place would not be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-boot-*/ directory-tree content have reached a sufficiently complete status. > >>> > >>> I'd expect that there will always be a lag for what exists in the world vs. what has these materials worked out in FreeBSD. > >>> > >>> > >>>>> Also from https://www.freebsd.org/platforms/arm.html : > >>>>> > >>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms follow a set of standard conventions, and a single FreeBSD build will work on hardware from multiple vendors. As a result, FreeBSD will provide official releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is on the path to becoming a Tier 1 architecture. > >>>>> > >>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? > >>>>> > >>>>> [I will note that, while there are no official builds for the Pine64 family (A64 based) that are under the Allwinner arm activity, the SOC's involved are Cortex-A53 64-bit arm based. They likely do not fit in the "standard conventions" or arm64/aarch64 would be where they would have been supported. Some rewording might be appropriate for the above quote as well.] > >>>> > >>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are > >>>> missing. It is quite solidly Tier 2, but we don't have a linker, we > >>>> don't have widespread hardware availability, we don't have production > >>>> experience with the platform. Most things work, but there's still some > >>>> gotchas. There's still the 'u-boot' problem with many arm64 systems > >>>> because for systems that use u-boot to bootstrap UEFI, you need a > >>>> different image for each board (some closely related board families > >>>> can get by with one to be pedantic). All these issues are still > >>>> significant barriers to production use. It's not been officially > >>>> promoted yet and I don't think the time is quite right yet. > >>> > >>> Intersting as well. I'd guess that conceptually this probably would apply to both: > >>> > >>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ > >>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) > >>> > >>> and. . . > >>> > >>> sys/arm64/cavium/ > >>> sys/arm64/cloudabi64/ > >>> > >>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a difference yet for tier level. > >>> > >>>> Warner > >>> > >>> Thanks again for the notes. > >>> > >>> === > >>> Mark Millard > >>> markmi at dsl-only.net > >>> > >>> _______________________________________________ > >>> freebsd-arm@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Sep 25 10:02:09 2016 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 6EA56BE687A for ; Sun, 25 Sep 2016 10:02:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24972F9 for ; Sun, 25 Sep 2016 10:02:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30664 invoked from network); 25 Sep 2016 09:55:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Sep 2016 09:55:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sun, 25 Sep 2016 05:55:32 -0400 (EDT) Received: (qmail 28027 invoked from network); 25 Sep 2016 09:55:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Sep 2016 09:55:32 -0000 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 48356EC8A8B; Sun, 25 Sep 2016 02:55:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Just FYI: FreeBSD-11.0-RELEASE-arm64-aarch64.raw under qemu on odroid-c2 Ubuntu 16.04.1 LTS Message-Id: <27466846-3031-47C7-82FE-808FCE920E69@dsl-only.net> Date: Sun, 25 Sep 2016 02:55:25 -0700 To: FreeBSD-STABLE Mailing List , freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 10:02:09 -0000 This is just an FYI about my attempt to use = FreeBSD-11.0-RELEASE-arm64-aarch64.raw under Ubuntu's qemu on an = odroid-c2. (This is my first ever use of qemu. I've no clue about how = well the qemu for this context works --or how well for any other = context.) Context of use of FreeBSD 11.0-RELEASE: > Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 3.14.79-83 aarch64) . . . > root@odroid64:~# uname -ap > Linux odroid64 3.14.79-83 #1 SMP PREEMPT Thu Sep 22 13:47:47 BRT 2016 = aarch64 aarch64 aarch64 GNU/Linux > qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ > -bios QEMU_EFI.fd -nographic \ > -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-11.0-RELEASE-arm64-aarch64.raw,id=3D= hd0 \ > -device virtio-blk-device,drive=3Dhd0 \ > -device virtio-net-device,netdev=3Dnet0 \ > -netdev user,id=3Dnet0 \ > -smp cpus=3D4 Note the "-nographic". The QEMU_EFI.fd is from: = https://releases.linaro.org/components/kernel/uefi-linaro/15.12/release/qe= mu64/QEMU_EFI.fd > # freebsd-version -ku; uname -apKU > 11.0-RELEASE > 11.0-RELEASE > FreeBSD odroidc2FBSD 11.0-RELEASE FreeBSD 11.0-RELEASE #0 r306211: Fri = Sep 23 11:42:02 UTC 2016 = root@releng2.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC = arm64 aarch64 1100122 1100122 Issue #0: "random" illegal instruction faults in FreeBSD use Example *.core file names for an occasional "illegal instruction" (other = times the same command works fine): cron.core fsck_ufs.core ifconfig.core login.core ntpd.core route.core sh.core shutdown.core top.core vi.core All these programs usually/frequently work fine. Some programs tend to not leave .core files and cause me to have to log = in again when they get the illegal instruction fault. ps is a command = that has had this happen. Issue #1: command input/output stops For both the serial console and an ssh into Ubuntu from which I start up = qemu for FreeBSD. . . Special keys, such as up-arrow for command line recall, stop the = input/output for typing commands and such. It is ignoring what is typed = (not just not displaying it). I end up having to kill the = qemu-system-aarch64 process from Ubuntu or use "Control-a x". Sometimes = "Control-a x" does not work. Sometimes pasting text into the window cause such input/output hangups = in FreeBSD use. Usually qemu's "Control-A x" sequence will quit qemu. So usually there = must be some amount of processing of what is typed but at some stage the = text is otherwise being ignored. (I normally kill qemu-system-aarch64 = from another Ubuntu command shell.) Other point(s): I've not managed to get FreeBSD qemu to even ping a numeric address ("No = route to host"). But this may be just my current ignorance of how things = are supposed to be configured, both in Ubuntu and in FreeBSD and on the = command line options to qemu-system-aarch64. I've not put much effort = into figuring such out given the more basic problems above. (The = environment the attempt was done from is dhcp based.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Sep 25 15:57:29 2016 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 13351BE8273; Sun, 25 Sep 2016 15:57:29 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3947EE8; Sun, 25 Sep 2016 15:57:28 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id u8PFvISP062229; Sun, 25 Sep 2016 15:57:18 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.106] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id w39erfebfkspmgvzbf2vpmx3vi; Sun, 25 Sep 2016 15:57:18 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3243\)) Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? From: Tim Kientzle In-Reply-To: Date: Sun, 25 Sep 2016 08:57:18 -0700 Cc: Warner Losh , freebsd-arm , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: <9BFF1495-8142-4C2F-8919-D9A870D3E2BD@kientzle.com> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> To: Russell Haley X-Mailer: Apple Mail (2.3243) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 15:57:29 -0000 > On Sep 25, 2016, at 12:13 AM, Russell Haley wrote: > >> We can't easily do away with ubldr if we want to support tunables, kernel >> modules loaded at boot time and a few other nifty features like nextboot. > > Are these things not in standard loader? Should they be? "ubldr" *is* the standard loader. It's built from (mostly) the same source as loader(8) used on x86. But, where loader(8) uses the BIOS interface to access the disk, "ubldr" uses the U-Boot ABI to access the disk. FreeBSD's current boot sequence for ARM boards looks like this: * U-Boot loads ubldr * ubldr uses U-Boot to access disk and console * ubldr loads the kernel, kernel modules, and sets kernel tunables To replace U-Boot, bare box would either have to duplicate everything ubldr does (which is a lot) or would have to provide the U-Boot ABI (or something similar) so that ubldr can provide the final boot stage. Tim From owner-freebsd-arm@freebsd.org Sun Sep 25 17:19:57 2016 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 F301CBE98DC for ; Sun, 25 Sep 2016 17:19:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6F27B1B for ; Sun, 25 Sep 2016 17:19:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id r192so55402619ita.0 for ; Sun, 25 Sep 2016 10:19:56 -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:content-transfer-encoding; bh=qGvEMyB29f9K9/MEbbEa5i3Kmfo/gfnVwXX/y/Yv6wc=; b=B+xivf9WzjKeUlCQbMpYfsYB/p0IQ84iTg0G2q5XCW0ihCVYpOl3WjP2x5x6IDFcbw iPRVgakKjp2wVqdNjpMT3HSDubIHJvwxg3dgn4qhmdJl7LtKIRPk/n4yq77amHTUg7AB Wrhvr/kEL9JJyVIuvmb4MFZHNM7aD+iffMPMLzm0dBmQ91Z22+W+WM5xM1R4G9ysXJLx snIF4LaAcPYen9CliUeaYSQ/8iRKBXwQ0cAEmzxwyvQ9FoyKlSYvgWuD1dpmiBBjyMdG pgpVBHKMbbQIRdkAjw8kXG/QHFiNXOWSGO45/qBzxgJg9GBVCnAXPg3GtVQru5HWfy4r uwIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=qGvEMyB29f9K9/MEbbEa5i3Kmfo/gfnVwXX/y/Yv6wc=; b=hlHJhS/D04culbiaZ1jTgKfMwvNJmeZADEe1I7hTyOrp+Vosk7SQkyJYtfDp7ymx+u G2rHW6He0SbvQfWVtegCdpD/9/vUKQFLJgVP7nIMU1UHv+83uf4DQ2NhZqYJIdBdh5pA 6XyVJ3H0ZyCpqBrQViOBzZgiF4nsOfZXs9gigrpy7zNnAXyBqYu3u5YJCsW8U1pr88nE lI2lxhR3UizJuqf82KXglTkXB8h608XcVmncmv51uPsHL8xqy1GBgP9Qcij0P8GEq8Os aFf4XJt49yE2ETI2CUg20tfqt+NBAcMNf1PypMRleL93qqNU7pXLByfoNy8bAGKjlx8n 8n+A== X-Gm-Message-State: AA6/9RkoXHAuMC8pdv3IoxRuk8dnOCtk1nHvkbnyUcAtrvn6zbTQdL+SKF1Ws/cpnjBfj9shfDuN8B7eBfBGCw== X-Received: by 10.36.14.68 with SMTP id 65mr12200559ite.99.1474823995988; Sun, 25 Sep 2016 10:19:55 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Sun, 25 Sep 2016 10:19:55 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> From: Warner Losh Date: Sun, 25 Sep 2016 11:19:55 -0600 X-Google-Sender-Auth: LsklrTS85t_g121n76IX46KNqBc Message-ID: Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? To: Russell Haley Cc: Mark Millard , freebsd-arm , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 17:19:57 -0000 On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley wrote= : > On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh wrote: >> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley w= rote: >>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard wro= te: >>>> On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: >>>> >>>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard w= rote: >>>>>> [A resend since I forget to list free-arm in the To: the first time.= ] >>>>>> >>>>>> From https://www.freebsd.org/platforms/arm.html : >>>>>> >>>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD proj= ect does not provide official releases or pre-built packages for this platf= orm due to it primarily targeting the embedded arena. However, FreeBSD/ARM = is being actively developed and maintained, is well supported, and provides= an excellent framework for building ARM-based systems. FreeBSD/arm support= s ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 proces= sors, including SMP on the latter. >>>>>> >>>>>> "does not provide official releases or pre-built packages"? >>>>>> >>>>>>> # uname -apKU >>>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: S= un Aug 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/= usr/src/sys/RPI2-NODBG arm armv6 1100502 1100502 >>>>>> >>>>>>> # pkg search '.*' | wc >>>>>>> 21349 155540 1596736 >>>>>> >>>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-= armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such = as for RPI2? >>>>>> >>>>>> Even if all the officially built arm-armv6 variants stay tier 2, the= wording on the web page likely needs to be changed because so much is buil= t and available that the above quote claims is not available. >>>>> >>>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or >>>>> amd64 due to the fragmented nature of the arm world. On the platforms >>>>> we run on and create releases for, however, it's my opinion that it i= s >>>>> Tier 1: it has been running in production a while, things people >>>>> expect from a FreeBSD system are present, you can get decent support >>>>> if you ask questions, there's no known major gotchas in deploying thi= s >>>>> hardware. The only remaining annoying issue is the 'u-boot' problem >>>>> where we have to have a different u-boot image for every board and no >>>>> standardized way to convert a 'generic' image into one that's specifi= c >>>>> for specific boards. >>> >>> I'll point out again that barebox is an excellent alternative to u-boot= (IMHO): >> >> Doesn't matter, still has the same issues that u-boot has. > u-boot has a different sources for almost each board we support (due > to the usual FOSS issues). That is NOT the case in barebox. There is > one source and it's kept up to date by the team, not the vendors. Actually, that's no longer the case. All boards we support have all their bits in u-boot's main repo. But you can't say no one will fork barebox to get their support out faster, which is why we have the current situation in ports... u-boot forked because it was so popular, and the forks rejoined. >> But does it support the u-boot ABI? > I'd have to look into this. >> >>> - Supports most, if not all of the boards that FreeBSD supports, plus >>> many that it doesn't >>> - Single source tree for all boards. Specify build time parameters to >>> build one or all the images >>> - Well supported community with central maintainer-ship >>> - Simple, familiar shell interface (*awesome*) >>> - Excellent documentation (u-boots is good too though) >>> - Has support for (U)EFI >>> - Supports quemu aarch64 (not *quite*sure what the means though) >> >> Right, u-boot has all these things, except maybe the shell interface >> (not sure what you mean by that). > Instead of stringing together variables and commands, it uses a > scripting language like a simplified sh. Want to change how something > boots? Update a script. Save it to disk (it has it's own persistence > mechanisms) and export it. Sounds cool. >>> To be fair, I'm not saying the problem is the fault of denx, but >>> barebox has a lot going for it. The maintainer was very keen to see it >>> ported top FreeBSD and was willing to support the effort. I ran into >>> some build time linux api requirements, but he didn't think that would >>> be much to overcome (and it wasn't I just kept adding the patches he >>> sent me and the build moved forward. As always, I ran out of time for >>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've >>> over simplified the problem, I thought it would be neat to see FreeBSD >>> upstream support for zfs and ufs to the barebox boot loader and do >>> away with ubldr. We would then have a modern, easy to use, boot loader >>> that supports the standard startup toolchain. >> >> We can't easily do away with ubldr if we want to support tunables, kerne= l >> modules loaded at boot time and a few other nifty features like nextboot= . > > Are these things not in standard loader? Should they be? ubldr is the standard loader, just spelled in a funky way and living on a place u-boot can see :). We have different loaders for different environments. even on x86 we have /boot/loader for BIOS boots and /boot/loader.efi for EFI boots. >>> Either way, if installers move to a pkgng based method (so cool) then >>> installing u-boot and arm binaries from pkg-static will be the same as >>> x86 (ha ha I said that with a straight face!). >> >> Yea, not so much. You have to build the bootable image not on the >> target system, like you do on x86. > > Doesn't the current ports and packages cross build everything that's mark= ed? For builds from source, yes. But that's different than installing from FreeBSD's installer. >> We'd have to have something that >> installs uboot onto a generic image (perhaps with hooks for kernels >> since those aren't generic on armv6) and then put that into a bootable >> SD card. > > The x86 installer (that I argue is a platform legacy) has to customize > the bootloader for each installation. If we HAVE to use an installer > on arm, what wrong prompting the user for some input (i.e. what som > are you using) while including all the u-boots in the ports tree and > all the supported kernels, then just installing the correct ones for > the board (with input from the user)? Ummm, you can't boot anything to do that work like you can on x86. >>>>>For x86 this is all done with the installer since >>>>> that boot environment is more standardized. Does this last issue keep >>>>> arm from being Tier 1? That's a judgement call, but I think the >>>>> project should promote w/o this last issue. >>> >>> How does a platform get promoted? Is that something the Core team decid= es? >> >> Yes. >> >>> I see two facts about current Arm support that show platform maturity: >>> a) u-boot is in the ports tree and we have Lego-easy build scripts in >>> crochet that could be called an installation method. Building for arm >>> is not difficult anymore. >> >> Except corchet isn't in the tree, and the solution is horrible. It's >> a script for each SoC, and those scripts are now scattered about. >> Plus that's a creation from source model, not a creation from >> RE produced bits model, which is needed for Tier 1. > Both correctable sins, especially as it's BSD licensed. My point was > that even building a SOM specific image is relatively painless with > the right scripts. Hell, I've even got a custom build script that > could be modified for generic use. Yea, a developer can do it with little pain. However, compared to the pain to boot Linux on these boards, the pain is quite high and you need to know way too much to make it work. BTW, my 'horrible' comment was given the state of things today: we have scattered knowledge of how to make images, custom one-off that work on some boards well, and fail on others. We have crazy, quirky things that aren't well integrated into the tree. Crochet itself solves an interesting problem, but does so a bit in isolation. >>> b)Arm requires images, not installers. Correct me if I'm wrong but, >>> installers are a tool primarily invented for x86 PC type computers. >>> FreeBSD publishes standardized ISOs for all supported Arm platforms >>> that work by simply "xzcat | dd" onto the sd card (or wherever you >>> need it). I'm not sure how standardized or manual that build process >>> is, but I would think that if the Arm platform support is able to keep >>> up with the standard FreeBSD release cycle (i.e. not break every other >>> release) then there would be no reason to NOT call it tier 1? >> >> Creating the images is currently a pita. That's it. > I see. So not so mature. Yes. It's an area I work on when I have time to make better... Warner >>> What I don't know about is "official" documentation for building for >>> arm and supporting cross building to Arm. Will someone need to write >>> an "Arm Handbook" to be promoted? >> >> No. While useful, most of that already exists. > > Thanks for the response Warner, I always appreciate the chance to > learn more about FreeBSD. > Russ > >> Warner >> >>>> Interesting and good to know. Thanks. >>>> >>>> I might have guessed that going along with the u-boot issue would be t= he fanout in: >>>> >>>> 11.0/sys/arm/ . . . >>>> >>>> allwinner/a10/ >>>> allwinner/a20/ >>>> allwinner/a31/ >>>> allwinner/a83t/ >>>> allwinner/h3/ >>>> . . . >>>> broadcom/bcm2835/ >>>> . . . >>>> >>>> (Full list not shown.) >>>> >>>> I was thinking that this might make the tier level specific to the sta= tus of each such directory's content so that it was the combination of that= and the sysutils/u-boot-*/ status that made the difference for assigning t= he level. I'd guess that lack of a usable directory in either place would = not be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u= -boot-*/ directory-tree content have reached a sufficiently complete status= . >>>> >>>> I'd expect that there will always be a lag for what exists in the worl= d vs. what has these materials worked out in FreeBSD. >>>> >>>> >>>>>> Also from https://www.freebsd.org/platforms/arm.html : >>>>>> >>>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms fo= llow a set of standard conventions, and a single FreeBSD build will work on= hardware from multiple vendors. As a result, FreeBSD will provide official= releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 i= s on the path to becoming a Tier 1 architecture. >>>>>> >>>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>>>>> >>>>>> [I will note that, while there are no official builds for the Pine64= family (A64 based) that are under the Allwinner arm activity, the SOC's in= volved are Cortex-A53 64-bit arm based. They likely do not fit in the "stan= dard conventions" or arm64/aarch64 would be where they would have been supp= orted. Some rewording might be appropriate for the above quote as well.] >>>>> >>>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are >>>>> missing. It is quite solidly Tier 2, but we don't have a linker, we >>>>> don't have widespread hardware availability, we don't have production >>>>> experience with the platform. Most things work, but there's still som= e >>>>> gotchas. There's still the 'u-boot' problem with many arm64 systems >>>>> because for systems that use u-boot to bootstrap UEFI, you need a >>>>> different image for each board (some closely related board families >>>>> can get by with one to be pedantic). All these issues are still >>>>> significant barriers to production use. It's not been officially >>>>> promoted yet and I don't think the time is quite right yet. >>>> >>>> Intersting as well. I'd guess that conceptually this probably would ap= ply to both: >>>> >>>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ >>>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) >>>> >>>> and. . . >>>> >>>> sys/arm64/cavium/ >>>> sys/arm64/cloudabi64/ >>>> >>>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a= difference yet for tier level. >>>> >>>>> Warner >>>> >>>> Thanks again for the notes. >>>> >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>> >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Sep 26 04:03:32 2016 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 5E8D1BE83D4; Mon, 26 Sep 2016 04:03:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 09688BA; Mon, 26 Sep 2016 04:03:32 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22c.google.com with SMTP id z126so37771435vkd.0; Sun, 25 Sep 2016 21:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iADDNrBlTH0JqYCNNhbcwEoGJITLYOtnB0Sll8KcL8U=; b=AENVV+mQDzd/jAzsGq5d+wLxGMQTdYwD/EGWn21H5E97dktyCcWjeok5i1zDI7MZKt FBtzUgbAcpLxcnI6bZeANYzMDbH2er5RgV2hqvsutcenM3cfIwmkvUByu5I3h+TiM6Cp HKJihonCS2E5wYMOBCyWs3Sf9Q8vO8Erux4lr5VLBW9n/BwoZokTSBtIwOzzrX9BZpBH szkQ3cVOYU8owOAfRjLwZYyIivr16EKZtBdCyoO7JM7FQhM62LO5CXFr7y35MlBk0dzj WtG/Ak1lK/H0i0+FsKVIaconn5yAswGiuiWf/pYswzVrwcyoUdJIhzvi42qzbW61OeiM RSEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iADDNrBlTH0JqYCNNhbcwEoGJITLYOtnB0Sll8KcL8U=; b=UHUcA4/5FHZKfRxjWmtw7/v5WyGYyufEpWlXSs/zQkbaH7SR7euzJIaSw1NdmNH4kr bJirHoW6H0TLdYzsLiFoRgYjKolLcit1aEEFdJqOq1x0yrm6jEH++XUxtZPGMdgn1Oru Rf77E8GpamWIbljuXLkTDIBJXkM6lo6YA/kl7xMAZYrWX7tTNBv/yhb+LGEe3MC6OM9E UfYKeTV7ofv7cnU6HXEP0N2NRGtQlT9ado0qRA0gQJBgvqSBIdFgo8HvwbnMKFya/LxT 8TkDlA8E1npKVI6JaP3R+QE+QL+Uf0kwIQK1F6SVrhMdaMjXcwIzGyGR70YC95ys/84a WfkA== X-Gm-Message-State: AA6/9RmCc8L0zsVMmv1nCO/lWi8gXEQZFg1LHyw8A7z9j6T+CspSrd0v8CRvzCRE1XP6SIC5Y7msKtTAzDNtJQ== X-Received: by 10.31.5.19 with SMTP id 19mr5592437vkf.75.1474862610967; Sun, 25 Sep 2016 21:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.124.202 with HTTP; Sun, 25 Sep 2016 21:03:30 -0700 (PDT) In-Reply-To: References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> From: Russell Haley Date: Sun, 25 Sep 2016 21:03:30 -0700 Message-ID: Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? To: Warner Losh Cc: Mark Millard , freebsd-arm , FreeBSD-STABLE Mailing List 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, 26 Sep 2016 04:03:32 -0000 On Sun, Sep 25, 2016 at 10:19 AM, Warner Losh wrote: > On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley wro= te: >> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh wrote: >>> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley = wrote: >>>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard wr= ote: >>>>> On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: >>>>> >>>>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard = wrote: >>>>>>> [A resend since I forget to list free-arm in the To: the first time= .] >>>>>>> >>>>>>> From https://www.freebsd.org/platforms/arm.html : >>>>>>> >>>>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD pro= ject does not provide official releases or pre-built packages for this plat= form due to it primarily targeting the embedded arena. However, FreeBSD/ARM= is being actively developed and maintained, is well supported, and provide= s an excellent framework for building ARM-based systems. FreeBSD/arm suppor= ts ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 proce= ssors, including SMP on the latter. >>>>>>> >>>>>>> "does not provide official releases or pre-built packages"? >>>>>>> >>>>>>>> # uname -apKU >>>>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: = Sun Aug 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6= /usr/src/sys/RPI2-NODBG arm armv6 1100502 1100502 >>>>>>> >>>>>>>> # pkg search '.*' | wc >>>>>>>> 21349 155540 1596736 >>>>>>> >>>>>>> Will 11.0-RELEASE change the tier level for any of the specific arm= -armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such= as for RPI2? >>>>>>> >>>>>>> Even if all the officially built arm-armv6 variants stay tier 2, th= e wording on the web page likely needs to be changed because so much is bui= lt and available that the above quote claims is not available. >>>>>> >>>>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or >>>>>> amd64 due to the fragmented nature of the arm world. On the platform= s >>>>>> we run on and create releases for, however, it's my opinion that it = is >>>>>> Tier 1: it has been running in production a while, things people >>>>>> expect from a FreeBSD system are present, you can get decent support >>>>>> if you ask questions, there's no known major gotchas in deploying th= is >>>>>> hardware. The only remaining annoying issue is the 'u-boot' problem >>>>>> where we have to have a different u-boot image for every board and n= o >>>>>> standardized way to convert a 'generic' image into one that's specif= ic >>>>>> for specific boards. >>>> >>>> I'll point out again that barebox is an excellent alternative to u-boo= t (IMHO): >>> >>> Doesn't matter, still has the same issues that u-boot has. >> u-boot has a different sources for almost each board we support (due >> to the usual FOSS issues). That is NOT the case in barebox. There is >> one source and it's kept up to date by the team, not the vendors. > > Actually, that's no longer the case. All boards we support have all > their bits in u-boot's main repo. But you can't say no one will fork > barebox to get their support out faster, which is why we have the > current situation in ports... u-boot forked because it was so popular, > and the forks rejoined. Good show, I'm not advocating change for change sake and have had good success with u-boot as a novice. I'll have to have a look in the ports tree. I wasn't aware that so much progress had been made. I wish I had time to skulk on the IRC channel too. :( Russ >>> But does it support the u-boot ABI? >> I'd have to look into this. >>> >>>> - Supports most, if not all of the boards that FreeBSD supports, plus >>>> many that it doesn't >>>> - Single source tree for all boards. Specify build time parameters to >>>> build one or all the images >>>> - Well supported community with central maintainer-ship >>>> - Simple, familiar shell interface (*awesome*) >>>> - Excellent documentation (u-boots is good too though) >>>> - Has support for (U)EFI >>>> - Supports quemu aarch64 (not *quite*sure what the means though) >>> >>> Right, u-boot has all these things, except maybe the shell interface >>> (not sure what you mean by that). >> Instead of stringing together variables and commands, it uses a >> scripting language like a simplified sh. Want to change how something >> boots? Update a script. Save it to disk (it has it's own persistence >> mechanisms) and export it. > > Sounds cool. > >>>> To be fair, I'm not saying the problem is the fault of denx, but >>>> barebox has a lot going for it. The maintainer was very keen to see it >>>> ported top FreeBSD and was willing to support the effort. I ran into >>>> some build time linux api requirements, but he didn't think that would >>>> be much to overcome (and it wasn't I just kept adding the patches he >>>> sent me and the build moved forward. As always, I ran out of time for >>>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've >>>> over simplified the problem, I thought it would be neat to see FreeBSD >>>> upstream support for zfs and ufs to the barebox boot loader and do >>>> away with ubldr. We would then have a modern, easy to use, boot loader >>>> that supports the standard startup toolchain. >>> >>> We can't easily do away with ubldr if we want to support tunables, kern= el >>> modules loaded at boot time and a few other nifty features like nextboo= t. >> >> Are these things not in standard loader? Should they be? > > ubldr is the standard loader, just spelled in a funky way and living > on a place u-boot can see :). We have different loaders for different > environments. even on x86 we have /boot/loader for BIOS boots and > /boot/loader.efi for EFI boots. > >>>> Either way, if installers move to a pkgng based method (so cool) then >>>> installing u-boot and arm binaries from pkg-static will be the same as >>>> x86 (ha ha I said that with a straight face!). >>> >>> Yea, not so much. You have to build the bootable image not on the >>> target system, like you do on x86. >> >> Doesn't the current ports and packages cross build everything that's mar= ked? > > For builds from source, yes. But that's different than installing from > FreeBSD's installer. > >>> We'd have to have something that >>> installs uboot onto a generic image (perhaps with hooks for kernels >>> since those aren't generic on armv6) and then put that into a bootable >>> SD card. >> >> The x86 installer (that I argue is a platform legacy) has to customize >> the bootloader for each installation. If we HAVE to use an installer >> on arm, what wrong prompting the user for some input (i.e. what som >> are you using) while including all the u-boots in the ports tree and >> all the supported kernels, then just installing the correct ones for >> the board (with input from the user)? > > Ummm, you can't boot anything to do that work like you can on x86. > >>>>>>For x86 this is all done with the installer since >>>>>> that boot environment is more standardized. Does this last issue kee= p >>>>>> arm from being Tier 1? That's a judgement call, but I think the >>>>>> project should promote w/o this last issue. >>>> >>>> How does a platform get promoted? Is that something the Core team deci= des? >>> >>> Yes. >>> >>>> I see two facts about current Arm support that show platform maturity: >>>> a) u-boot is in the ports tree and we have Lego-easy build scripts in >>>> crochet that could be called an installation method. Building for arm >>>> is not difficult anymore. >>> >>> Except corchet isn't in the tree, and the solution is horrible. It's >>> a script for each SoC, and those scripts are now scattered about. >>> Plus that's a creation from source model, not a creation from >>> RE produced bits model, which is needed for Tier 1. >> Both correctable sins, especially as it's BSD licensed. My point was >> that even building a SOM specific image is relatively painless with >> the right scripts. Hell, I've even got a custom build script that >> could be modified for generic use. > > Yea, a developer can do it with little pain. However, compared to the > pain to boot Linux on these boards, the pain is quite high and you > need to know way too much to make it work. > > BTW, my 'horrible' comment was given the state of things today: we > have scattered knowledge of how to make images, custom one-off that > work on some boards well, and fail on others. We have crazy, quirky > things that aren't well integrated into the tree. Crochet itself > solves an interesting problem, but does so a bit in isolation. > >>>> b)Arm requires images, not installers. Correct me if I'm wrong but, >>>> installers are a tool primarily invented for x86 PC type computers. >>>> FreeBSD publishes standardized ISOs for all supported Arm platforms >>>> that work by simply "xzcat | dd" onto the sd card (or wherever you >>>> need it). I'm not sure how standardized or manual that build process >>>> is, but I would think that if the Arm platform support is able to keep >>>> up with the standard FreeBSD release cycle (i.e. not break every other >>>> release) then there would be no reason to NOT call it tier 1? >>> >>> Creating the images is currently a pita. That's it. >> I see. So not so mature. > > Yes. It's an area I work on when I have time to make better... > > Warner > >>>> What I don't know about is "official" documentation for building for >>>> arm and supporting cross building to Arm. Will someone need to write >>>> an "Arm Handbook" to be promoted? >>> >>> No. While useful, most of that already exists. >> >> Thanks for the response Warner, I always appreciate the chance to >> learn more about FreeBSD. >> Russ >> >>> Warner >>> >>>>> Interesting and good to know. Thanks. >>>>> >>>>> I might have guessed that going along with the u-boot issue would be = the fanout in: >>>>> >>>>> 11.0/sys/arm/ . . . >>>>> >>>>> allwinner/a10/ >>>>> allwinner/a20/ >>>>> allwinner/a31/ >>>>> allwinner/a83t/ >>>>> allwinner/h3/ >>>>> . . . >>>>> broadcom/bcm2835/ >>>>> . . . >>>>> >>>>> (Full list not shown.) >>>>> >>>>> I was thinking that this might make the tier level specific to the st= atus of each such directory's content so that it was the combination of tha= t and the sysutils/u-boot-*/ status that made the difference for assigning = the level. I'd guess that lack of a usable directory in either place would= not be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/= u-boot-*/ directory-tree content have reached a sufficiently complete statu= s. >>>>> >>>>> I'd expect that there will always be a lag for what exists in the wor= ld vs. what has these materials worked out in FreeBSD. >>>>> >>>>> >>>>>>> Also from https://www.freebsd.org/platforms/arm.html : >>>>>>> >>>>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms f= ollow a set of standard conventions, and a single FreeBSD build will work o= n hardware from multiple vendors. As a result, FreeBSD will provide officia= l releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 = is on the path to becoming a Tier 1 architecture. >>>>>>> >>>>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>>>>>> >>>>>>> [I will note that, while there are no official builds for the Pine6= 4 family (A64 based) that are under the Allwinner arm activity, the SOC's i= nvolved are Cortex-A53 64-bit arm based. They likely do not fit in the "sta= ndard conventions" or arm64/aarch64 would be where they would have been sup= ported. Some rewording might be appropriate for the above quote as well.] >>>>>> >>>>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are >>>>>> missing. It is quite solidly Tier 2, but we don't have a linker, we >>>>>> don't have widespread hardware availability, we don't have productio= n >>>>>> experience with the platform. Most things work, but there's still so= me >>>>>> gotchas. There's still the 'u-boot' problem with many arm64 systems >>>>>> because for systems that use u-boot to bootstrap UEFI, you need a >>>>>> different image for each board (some closely related board families >>>>>> can get by with one to be pedantic). All these issues are still >>>>>> significant barriers to production use. It's not been officially >>>>>> promoted yet and I don't think the time is quite right yet. >>>>> >>>>> Intersting as well. I'd guess that conceptually this probably would a= pply to both: >>>>> >>>>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ >>>>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) >>>>> >>>>> and. . . >>>>> >>>>> sys/arm64/cavium/ >>>>> sys/arm64/cloudabi64/ >>>>> >>>>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make = a difference yet for tier level. >>>>> >>>>>> Warner >>>>> >>>>> Thanks again for the notes. >>>>> >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> markmi at dsl-only.net >>>>> >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " From owner-freebsd-arm@freebsd.org Mon Sep 26 12:52:47 2016 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 AB307BE6849 for ; Mon, 26 Sep 2016 12:52:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 918ACE82 for ; Mon, 26 Sep 2016 12:52:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 9085CBE6847; Mon, 26 Sep 2016 12:52:47 +0000 (UTC) Delivered-To: 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 8FCD7BE6846 for ; Mon, 26 Sep 2016 12:52:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FE08E7D for ; Mon, 26 Sep 2016 12:52:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.81.13]) by kabab.cs.huji.ac.il with esmtp id 1boVOb-0006CS-FV; Mon, 26 Sep 2016 15:52:33 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ALL WINNER high temp. stop From: Daniel Braniss In-Reply-To: Date: Mon, 26 Sep 2016 15:52:33 +0300 Cc: arm@freebsd.org Message-Id: <6E63B10F-86C5-45EE-8D8B-2192D8C8A63C@cs.huji.ac.il> References: <20160917171911.a2ec80da747ba373ba3d1b4a@bidouilliste.com> <5ADFE16E-FD60-45B1-8CF1-6FFC10BABBDE@cs.huji.ac.il> <20160917195544.a2a8bbdb113029700fa7642d@bidouilliste.com> <588E44BB-40BF-40B8-9C5A-BA025AB87E00@cs.huji.ac.il> <4F7891B0-FBD7-451C-BA42-50F872804C95@cs.huji.ac.il> <08E5651B-A28E-4BE8-803B-650CD2434979@cs.huji.ac.il> <01D85517-15ED-46FF-8C11-5A774EC1262F@cs.huji.ac.il> <7BFD291A-E619-4DE4-9BBB-C1F40E81F12A@cs.huji.ac.il> To: Jared McNeill X-Mailer: Apple Mail (2.3124) 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, 26 Sep 2016 12:52:47 -0000 > On 21 Sep 2016, at 14:22, Daniel Braniss wrote: >=20 >>=20 >> On 21 Sep 2016, at 14:13, Daniel Braniss > wrote: >>=20 >>=20 >>> On 21 Sep 2016, at 13:49, Jared McNeill = wrote: >>>=20 >>> CPU frequency scaling is supported now. Have you added operating = points to the dts? Without a heatsink or fan, you need to set a = reasonable set of operating points. >>>=20 >>> 64C does seem quite low, the thermal driver uses the power-on = default temperature for the shutdown temperature though (which should be = > 100C). >>>=20 >>> Are you sure you are using the correct compat string for the thermal = driver in your dts? Different SoCs use a different formula for reading = the temperature. >>=20 >> I=E2=80=99m using what you sent me :-) >> = https://github.com/jaredmcneill/freebsd/blob/allwinner-h3/sys/boot/fdt/dts= /arm/orangepi-plus-2e.dts#L12 = = > >>=20 >=20 > here is my dts for the orange-one: > /*- > * Copyright (c) 2016 Jared McNeill > > * All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in = the > * documentation and/or other materials provided with the = distribution. > * > * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND > * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, = THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE > * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE > * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS > * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF > * SUCH DAMAGE. > * > * $FreeBSD$ > */ > #include "sun8i-h3-orangepi-one.dts" >=20 > / { > clocks { > ths_clk: clk@1c20074 { > #clock-cells =3D <0>; > compatible =3D "allwinner,sun8i-h3-ths-clk"; > reg =3D <0x01c20074 0x4>; > clocks =3D <&osc24M>; > clock-output-names =3D "ths"; > }; > }; > soc { > emac: ethernet@1c30000 { > compatible =3D "allwinner,sun8i-h3-emac"; > reg =3D <0x01c30000 0x104>, <0x01c00030 0x4>; > reg-names =3D "emac", "syscon"; > interrupts =3D ; > resets =3D <&ahb_rst 17>; > reset-names =3D "ahb"; > clocks =3D <&bus_gates 17>; > clock-names =3D "ahb"; > #address-cells =3D <1>; > #size-cells =3D <0>; > status =3D "disabled"; > }; > =09 > sid: eeprom@01c14000 { > compatible =3D "allwinner,sun8i-h3-sid"; > reg =3D <0x01c14000 0x400>; > }; >=20 > rtp: rtp@1c25000 { > compatible =3D "allwinner,sun8i-h3-ts"; > reg =3D <0x01c25000 0x400>; > interrupts =3D ; > clocks =3D <&bus_gates 72>,<&ths_clk>; > clock-names =3D "ahb", "ths"; > resets =3D <&apb1_rst 8>; > #thermal-sensor-cells =3D <0>; > }; >=20 > }; > }; >=20 > &mmc0_pins_a { > allwinner,pull =3D ; > }; >=20 > &pio { > emac_pins_rgmii_a: emac_rgmii@0 { > allwinner,pins =3D "PD0", "PD1", "PD2", "PD3", "PD4", = "PD5", > "PD7", "PD8", "PD9", "PD10", "PD12", = "PD13", > "PD15", "PD16", "PD17"; > allwinner,function =3D "emac"; > allwinner,drive =3D ; > allwinner,pull =3D ; > }; >=20 > emac_phy_reset_pin: emac_phy_reset_pin@0 { > allwinner,pins =3D "PD6"; > allwinner,function =3D "gpio_out"; > allwinner,drive =3D ; > allwinner,pull =3D ; > }; > }; >=20 >=20 > /* > * Board-specific stuff here > */ >=20 > / { > /* > model =3D "Xunlong Orange Pi One"; > compatible =3D "xunlong,orangepi-one", "allwinner,sun8i-h3"; > */ > reg_gmac_3v3: gmac-3v3 { > compatible =3D "regulator-fixed"; > pinctrl-names =3D "default"; > pinctrl-0 =3D <&emac_phy_reset_pin>; > regulator-name =3D "gmac-3v3"; > regulator-min-microvolt =3D <3300000>; > regulator-max-microvolt =3D <3300000>; > startup-delay-us =3D <100000>; > enable-active-high; > gpio =3D <&pio 3 6 GPIO_ACTIVE_HIGH>; > }; > }; >=20 > &emac { > phy-supply =3D <®_gmac_3v3>; > phy-mode =3D "mii"; > phy =3D <&phy1>; >=20 > allwinner,leds-active-low; > status =3D "okay"; >=20 > allwinner,use-internal-phy; > resets =3D <&ahb_rst 17>,<&ahb_rst 66>; > reset-names =3D "ahb", "ephy"; > clocks =3D <&bus_gates 17>,<&bus_gates 128>; > clock-names =3D "ahb","ephy"; >=20 > phy1: ethernet-phy@1 { > reg =3D <1>; > }; > }; >=20 > &ehci2 { > status =3D "okay"; > }; >=20 >=20 >>=20 >>>=20 >>> Cheers, >>> Jared >>>=20 >>> On Wed, 21 Sep 2016, Daniel Braniss wrote: >>>=20 >>>> hi all, >>>> now that there is thermal control, trying to compile e.g. from = ports >>>> portmaster, heats up the cpu, which somewhere around 64C >>>> decides to halt. >>>> Now, I remember some weeks ago, with a kernel version >>>> without the thermal stuff compiling python and all went ok, >>>> so >>>> Q: what is the thermal high water mark? >>>> Q: are the latest changes overheating the cpu, or is the thermal = driver over >>>> cautious? >>>>=20 >>>> danny >>>>=20 >>>>=20 >>>>=20 I added a printf to see what is read off the thermal sensor, and the = first surprise is that it prints it twice for each sysctl call, next, if I apply the formula from the docs: temp =3D (val - 2794) / -14.882 the numbers are much higher!=20 val C C=E2=80=99 5ef: 32C 85.67C 5f4: 32C 85.34C 5e0: 34C 86.68C 5e6: 34C 86.28C 5de: 35C 86.82C 5d2: 36C 87.62C 5ca: 37C 88.16C 5ba: 39C 89.24C 5ae: 40C 90.04C 5a9: 41C 90.38C 59d: 42C 91.18C 581: 46C 93.07C 549: 53C 96.83C 541: 54C 97.37C 536: 55C 98.11C 51e: 58C 99.72C 516: 59C 100.26C 509: 60C 101.13C 502: 61C 101.60C 4f7: 62C 102.34C 4ef: 63C 102.88C 4f4: 63C 102.54C 4ea: 64C 103.21C 4eb: 64C 103.14C Accordingly, the the SHUT0_T_HOT is 0x4E9, and so it shuts down at ~ = 64/103, but I checking the temperature externally and when it shows 35C, sysctl says 38C but val is 0x5C0 so what the f=E2=80=A6. is going on here? danny From owner-freebsd-arm@freebsd.org Tue Sep 27 21:32:04 2016 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 14F70BEA756 for ; Tue, 27 Sep 2016 21:32:04 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C689E10DB for ; Tue, 27 Sep 2016 21:32:03 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id t7so30264475qkh.2 for ; Tue, 27 Sep 2016 14:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=457kYpONf9KbzukloZL2ih6dhXwXdooh2CcblZWPTUQ=; b=YHjCdc43PSh2p18BLNp/BjGSXwdAzK9xmxCY2mjwc3uQ6uatyOUUPYYI66GW/xbKdM G4I0JAqMm5E8ztyMYWIHKA5QrZuGVWmUw7Dh41TBomKymhRi0p+GturO50b9EB5Wislo zXOGW0XSaMEBEimcjK3sekKDgu1MXzA9QDkdWQI7PX17kEIClEfn31VK0gJzYWkXaVze YcfsjEUqoX7JHGXyJ89+rtOa8TUpjW1C7doDu8L0ma9Y/SiO7W5RjLQFXgcv4Qj5iTnz 963+w0+wLnItA3oDpRbxVgZhtbaaInw6AUJo7BIkUc6pm7uJCGMYkURh+mjCAvq0Ycjx A+Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=457kYpONf9KbzukloZL2ih6dhXwXdooh2CcblZWPTUQ=; b=MbEPNQukUMjwgMLsrFaX2tRuRdIrloRzYXVUR+sMDfcOllgqyvOwC/JT/WERd8uMuh DNqH7c02IhMe6JJHuH+WcVnLiruZyG6yet83b35ymdlftPDOWFv8CjvxYV19QGrWPjrA 5FVXQY+gwOyzgMomxg50I/RtWDwHdHVX82xSeLENv1wJiiDx2J6fRfHl0Bk4yOd/ZZYG IH8wa/7FPsYaFLT8zzd/Jrh2TP2jBlltQBVgnRJpqMBm5HtdptW4TAZFAVrlS76ThlU6 xYW1/Zw6qSUrac7v7VXvm+d638PpgF3pXxx0naIdUGn5iSdIwGI0D33eS7YNCvvovR6H Fppg== X-Gm-Message-State: AA6/9RkeJn3hoSY/BrUnqUJEoqWtam4YkyKRDKvvVTJnwyECfdiUDIB51GHNpx8JCJ4urmhZO1b6DLBXvN/sKw== X-Received: by 10.55.188.195 with SMTP id m186mr32255208qkf.180.1475011922797; Tue, 27 Sep 2016 14:32:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.194 with HTTP; Tue, 27 Sep 2016 14:32:02 -0700 (PDT) From: Lee D Date: Tue, 27 Sep 2016 17:32:02 -0400 Message-ID: Subject: SD-Card driver modification for Zynq questions To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 21:32:04 -0000 Hello, I have designed a custom Xilinx Zynq board that I am running FreeBSD 10.3 on. Everything is working well except for my second SD-Card. The problem is that I cannot run the card at maximum speed due to a hardware signal integrity limitation -- which was expected and is not an issue. However, it does not seem to be possible to configure the FreeBSD driver to run at lower than the maximum card speed. There is a "max-frequency" parameter that I can set in the DTS file. But that parameter specifies the clock frequency of the SDIO controller in the Zynq part, not the maximum frequency of the card. If "max-frequency" is changed, then the card ceases to work at all. So, my questions: 1. Is there a way to set the maximum data rate for card communications? 2. How can I add a parameter to the sdhci/mmc driver so that I can set the maximum data rate for the card, in the DTS file? 3. Would you please review my hacked-in MMC driver changes, below? My mmc.c hacks: In order to limit the maximum card frequency to 20MHz, I tracked down the place where it was being set in the mmc.c file, and hacked in a hard-coded limitation. In src/sys/dev/mmc/mmc.c, in the mmc_calculate_clock() function, right before the call to mmcbr_set_timing(), I inserted the following code: if (device_get_unit(sc->dev) == 1) { int max_dtr_limit=20000000; if (max_dtr > max_dtr_limit) { max_dtr=max_dtr_limit; } max_timing=0; } The intent is to lower the "max_dtr" variable to 20MHz for device #1 only. I am also turning off high speed timing for that device. This seems to work well. Is this a viable change for my board? Is this a good place to insert this limitation? I don't really understand the full SDIO/MMC ecosystem so I'm kind of flying blind here. Some background: My DTS file entry looks like this: sdhci@101000 { compatible = "xlnx,zy7_sdhci"; reg = <0x101000 0x1000>; interrupts = <0x4F>; interrupt-parent = <0x1>; max-frequency = <0x5f5e100>; // 100 MHz }; The reason that I must limit the maximum data rate to the card is because I have the card slot connected to the Zynq using EMIO pins. Xilinx warns that the maximum card data rates will not work when using EMIO. Thank you, Lee From owner-freebsd-arm@freebsd.org Wed Sep 28 14:17:01 2016 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 3FC00C013D7 for ; Wed, 28 Sep 2016 14:17:01 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm21-vm7.bullet.mail.gq1.yahoo.com (nm21-vm7.bullet.mail.gq1.yahoo.com [98.136.217.54]) (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 0D6C211CD for ; Wed, 28 Sep 2016 14:17:00 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475072214; bh=orAva9iqKCWev4Uw6Dbk06QnI0nk7yruEjSj5vBC9Fg=; h=From:Subject:Date:To:From:Subject; b=PI2FoDBj46ioG4sne6zErsgPLFO776GOFo0gD+JM3CFNWFsBAUSccYwNqQnEsEP3WA6bxtqQ398oRu6XYZEg4hCNDeXgDxIeiQN7GurPCErKXwALtW9FVNnYlbdilnxRVq1kbsDx7v6ZIoY0CKRZ872KcgvOMrnATjXUKt3AYgBox5K2dhPywR3wTv1Isc/QrvZaVB6qGbeyX5JSfZ1Xus5JMneF2hMP+5r3pTxVrOXSw1fCtp86cTSCh7UFTOcLttV8s9syG1BHqHjgBuaHK1T6/tybEDaZd6Xp1b/mIpmDlwSlzIwX8aaraUlABnUEgXCqGTzAsoYysKQpta25FA== Received: from [216.39.60.180] by nm21.bullet.mail.gq1.yahoo.com with NNFMP; 28 Sep 2016 14:16:54 -0000 Received: from [98.136.164.65] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 28 Sep 2016 14:16:54 -0000 Received: from [127.0.0.1] by smtp227.mail.gq1.yahoo.com with NNFMP; 28 Sep 2016 14:16:54 -0000 X-Yahoo-Newman-Id: 171281.88073.bm@smtp227.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: c2ptatAVM1nxxOaYNUuisHk3PN8ly8LqA56omdFgjzINuJe mv80IUBLZOOEaWz6Hlh_cyBk6nYIbNIOhPkKNtKFfKBUSJ6vsbi2Az40UNrz gPRd2OqVwWhyRQyD.NOeFyHlKe7uPYBaqGUtokYUCUoGLk0UPkeKe8wjsQbt swpeXfebfG5sZRWQ4uQjeqWNr5cm6NlvNaQvtmCLRk5Xgk027RDCowy62ieM tsBz0LzYZ82l00jBco6x5I0fgyfh7fnyQDT9DYWstrb1o_JB.QO4CRVKyjDc w.Ruf6rpn7_te3O.tigD_8fHZkA59U1q9T2YCwzOzPIfk_28Wo3YTaolhLXU vhDyVvbhHVc7mkux_djtZ3KcM.1EE6MXdKVMWudfrBavzkoxskCAOPT148yS A0mvqYP70aivV0DPqn3565XvJsxwUI2EPywI7QSIayY7kyJ2pR_hpC22h0Ef .IrK.qVENkxPrzNb8.kmvTVymk0RLB4p44AQkzu4cYZn2dcks9_fsT5D5PGw Ggl62h1LKaMc9HhEUhqjOrhz5hJZ0WZpxLq7E5j0.hKNAQbSutRyQaePoDRe qPFV9DQh4sxaYp.rzNg-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: SD-Card driver modification for Zynq questions Message-Id: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> Date: Wed, 28 Sep 2016 07:16:52 -0700 To: freebsd-arm@freebsd.org, Lee D Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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, 28 Sep 2016 14:17:01 -0000 Why not just set max-frequency to 200Mhz in the DTS file entry? =E2=80=94=E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Wed Sep 28 21:01:12 2016 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 9AF7BC01621 for ; Wed, 28 Sep 2016 21:01:12 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 827EB99A for ; Wed, 28 Sep 2016 21:01:12 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [208.184.220.60] (helo=limiting-factor.dolby.net) by id.bluezbox.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1bpLyR-000KVF-Vv; Wed, 28 Sep 2016 14:01:04 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: Re: SD-Card driver modification for Zynq questions From: Oleksandr Tymoshenko In-Reply-To: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> Date: Wed, 28 Sep 2016 14:00:34 -0700 Cc: freebsd-arm@freebsd.org, Lee D Content-Transfer-Encoding: quoted-printable Message-Id: <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com> References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> To: Thomas Skibo X-Mailer: Apple Mail (2.3226) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm wrote: > > > Why not just set max-frequency to 200Mhz in the DTS file entry? From quick glance it’s not going to help. Slot’s max_clk is set to that value but then it’s overwritten in sdhci_init_slot by value obtained from register. We need to fix it and also add tunable for non-fdt systems. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 21:01:12 -0000 > On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm = wrote: >=20 >=20 > Why not just set max-frequency to 200Mhz in the DTS file entry? =46rom quick glance it=E2=80=99s not going to help. Slot=E2=80=99s = max_clk is set to that value but then it=E2=80=99s overwritten in sdhci_init_slot by value obtained from register. We need = to fix it and also add tunable for non-fdt systems. =20= From owner-freebsd-arm@freebsd.org Wed Sep 28 21:52:14 2016 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 2B5F4C0116B for ; Wed, 28 Sep 2016 21:52:14 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm29-vm5.bullet.mail.gq1.yahoo.com (nm29-vm5.bullet.mail.gq1.yahoo.com [98.136.216.180]) (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 00FC81A8 for ; Wed, 28 Sep 2016 21:52:13 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475099376; bh=b8y+CoinN7eENoOX5cG75/JmktDWZPuILuhdQNauUx0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=ljPD6+o8ivgQpY7BhJ5gEPXiaaUmmMHDso5HWVW5U0x3qQlfMWDm/wFwcSL82FgvcEIRaSOOqFbyXWF5yFlLegVe8d59UWOqhGilKaJ75nVVGwuBbIYWG+hYkOUrlQmUUlbHXP+1KGeCniNmIGk4AddcvjzpkuNVk1i4HH2mY84rkUNCpurzULKiYAX7tcNsWMOWAon1FcKrpcjxCckvPg8fvlw57C5//Mkb37vka5yYWEX5/UcKWUGi8Prv4GH1khbPdNtDvxu1EIaTv1IYpitDaC/IW064dELz7u22wmtPrFz0KZj+oNSBG/VskG3G+mQjT/VS6jQqzvjjDOz4dw== Received: from [98.137.12.61] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 28 Sep 2016 21:49:36 -0000 Received: from [208.71.42.204] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 28 Sep 2016 21:49:36 -0000 Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP; 28 Sep 2016 21:49:36 -0000 X-Yahoo-Newman-Id: 15103.96361.bm@smtp215.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _9NaADMVM1m8q8gXzWDaQ9BrAI2TKR0Dsmbr5VflJ7I1wDJ pWFXId9xX5msOqMJpfs5qHZRJHojawFSTgUNl9_9hBy9LB4CeOgIAh5PbvnM lT9Rq7D.BljFZ.56Kq3rAXNNOhfdPA0b9p1u1hZzG7Q3lvNX6yzzJ6AuLzKA mOY6hK1G5V1JZdlMqZda4MY5J_DeyBAoI7T.9ARpoLtVZjHaQofXcWjFVSTB xzzlsXhEBwyUCf1pSBRwzXg1x_zHr.BNCxlejRNZfsUhttrQEZUSLcwHywNj O7XgWM4__m9CnIk0X3rDsape6ni8VHvbxKvOs3FrIXDtxOyvTveMVcRww0MR qAvD_Oy3Jql6tkg7NcnepMy207wM3y0z4ox8WLQr8meGp9OCelCvgNN6VkEV sRtGgFg315an31lm57njkmOhRp3Cd3XKUgGB3p9rVbiqCHKfwt2OUADiWWm7 6L1_Y2xk.Bk7ayOEeQRXbxa0DSG_KXDuVBvyxQiSeLXJdl3wmPmlVoXYhXdu YivsIVA9dHaUi54yq88lB3PsLuUFOtEZHfvjgmGOs9gCxLmym7rY- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: SD-Card driver modification for Zynq questions From: Thomas Skibo In-Reply-To: <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com> Date: Wed, 28 Sep 2016 14:49:33 -0700 Cc: freebsd-arm@freebsd.org, Lee D Content-Transfer-Encoding: quoted-printable Message-Id: References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.3124) 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, 28 Sep 2016 21:52:14 -0000 > On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko = wrote: >=20 >=20 >> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm = wrote: >>=20 >>=20 >> Why not just set max-frequency to 200Mhz in the DTS file entry? >=20 > =46rom quick glance it=E2=80=99s not going to help. Slot=E2=80=99s = max_clk is set to that value but then it=E2=80=99s > overwritten in sdhci_init_slot by value obtained from register. We = need to fix it and also > add tunable for non-fdt systems. =20 I checked the Zynq manual and it looks like it doesn=E2=80=99t provide a = frequency in the capabilities register so sdhci_init_slot() won=E2=80=99t = change the slot=E2=80=99s max_clk. From owner-freebsd-arm@freebsd.org Wed Sep 28 21:54:31 2016 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 1B124C0124B for ; Wed, 28 Sep 2016 21:54:31 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F20002D7 for ; Wed, 28 Sep 2016 21:54:30 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [208.184.220.60] (helo=limiting-factor.dolby.net) by id.bluezbox.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1bpMo8-000Kaa-5F; Wed, 28 Sep 2016 14:54:28 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: Re: SD-Card driver modification for Zynq questions From: Oleksandr Tymoshenko In-Reply-To: Date: Wed, 28 Sep 2016 14:53:58 -0700 Cc: freebsd-arm@freebsd.org, Lee D Content-Transfer-Encoding: quoted-printable Message-Id: <9859398E-0592-4B8F-A3DA-0364970A92B4@bluezbox.com> References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com> To: Thomas Skibo X-Mailer: Apple Mail (2.3226) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Sep 28, 2016, at 2:49 PM, Thomas Skibo wrote: > > >> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko wrote: >> >> >>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm wrote: >>> >>> >>> Why not just set max-frequency to 200Mhz in the DTS file entry? >> >> From quick glance it’s not going to help. Slot’s max_clk is set to that value but then it’s >> overwritten in sdhci_init_slot by value obtained from register. We need to fix it and also >> add tunable for non-fdt systems. > > I checked the Zynq manual and it looks like it doesn’t provide a frequency in the capabilities register so sdhci_init_slot() won’t change the slot’s max_clk. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 21:54:31 -0000 > On Sep 28, 2016, at 2:49 PM, Thomas Skibo = wrote: >=20 >=20 >> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko = wrote: >>=20 >>=20 >>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm = wrote: >>>=20 >>>=20 >>> Why not just set max-frequency to 200Mhz in the DTS file entry? >>=20 >> =46rom quick glance it=E2=80=99s not going to help. Slot=E2=80=99s = max_clk is set to that value but then it=E2=80=99s >> overwritten in sdhci_init_slot by value obtained from register. We = need to fix it and also >> add tunable for non-fdt systems. =20 >=20 > I checked the Zynq manual and it looks like it doesn=E2=80=99t provide = a frequency in the capabilities register so sdhci_init_slot() won=E2=80=99= t change the slot=E2=80=99s max_clk. You=E2=80=99re right, I misread code, max-frequency can do the trick. = Still tunable may be a good idea.=20= From owner-freebsd-arm@freebsd.org Fri Sep 30 02:29:08 2016 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 A4605C02484 for ; Fri, 30 Sep 2016 02:29:08 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 5EE351A7B for ; Fri, 30 Sep 2016 02:29:08 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id n189so22277909qke.0 for ; Thu, 29 Sep 2016 19:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lt7XdQQo85Bfx5fnu21/6HmBZeL80EjEqhmS6WRmgM8=; b=opoYAYyJumFvZ8LH1q/iH6S7BZee8XCd/+rdricu7Fu8gIYPMpgkg9BrJ8N4u8gXxG NOL4do1Tbi5omYSjMOIlT0PH9Gwus6nN/I6fuL7PLL8tSLHC1FOScnOwpFv7zXTyT04w /+KH2BrutU8IY5PUwazVZB74UG3XjkVRFsbxDinDheV50TcLTvyb8h1qipxYwrqdP8Jo zaTJWVLhaKf97+cthHqouCT5kWsnJ27Qm5kef8xA9wwYiBiyen7YaIxc5MN60u4kNDi1 r8zq22fJn1ogeDHkG6Vhmi2mZki/C2T16zOGk08oo+ILV0sBbsvp7CFXDhVf/bwsGWxj eQuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lt7XdQQo85Bfx5fnu21/6HmBZeL80EjEqhmS6WRmgM8=; b=K0mH3E2JGWj7dYfJ0V+2OCejYw7U/vRX2o1LbugLU/xi/H+KpDwrqzjZeTX5aFnGdP +Npz8xVvOn+JJuPI9qCnOp9zfkewsl1n7Ug4gSUW+joPs7MVACvn7DKBK8ROz0VxdSgN /hOjvZNPNfGJPdtbj0nQYV454rFXByP/2R9QEiB6yt+kcRbdFLflQm+Npo/NaoygPV56 jr8Sv+18s0pCahkxgFasA6dcwtASOpR9JR2kx44oKGxFOXqT/9uF/eyO4NwhaLdwA73b 8wa+oDdBlA1B1/e41JQTJfPuWQQBCCN1BB6/sKNKQ1GyFQDxH7i0CPg1NrnPgkZFIc9R wBSg== X-Gm-Message-State: AA6/9RmMhRpRrLinvFUBWKBsEdAZa54ihFjpBfAjAN277esJ+KYSmUQfl0fqF6e4tc7g5Iv/vb1irmAxtgRWDg== X-Received: by 10.55.104.199 with SMTP id d190mr4825572qkc.163.1475202547651; Thu, 29 Sep 2016 19:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.194 with HTTP; Thu, 29 Sep 2016 19:29:07 -0700 (PDT) In-Reply-To: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> From: Lee D Date: Thu, 29 Sep 2016 22:29:07 -0400 Message-ID: Subject: Re: SD-Card driver modification for Zynq questions To: Thomas Skibo Cc: freebsd-arm 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: Fri, 30 Sep 2016 02:29:08 -0000 On Wed, Sep 28, 2016 at 10:16 AM, Thomas Skibo wrote: > > Why not just set max-frequency to 200Mhz in the DTS file entry? > > =E2=80=94=E2=80=94 > Thomas Skibo > thomasskibo@yahoo.com > > I hadn't thought of that. I think you are suggesting that I tell the driver that the clock speed is higher than it is so all of the clock divisors are set higher, which would result in a lower data rate. That's a clever idea, but I think I would actually have to set the max-frequency to 500MHz, since some cards are capable of operating up to 100MHz and my SD-Card slot can only run (safely) at 20MHz. That means at that all normal 25MHz cards would run dramatically slower than they need to. In the event that I can't figure out how to make a new DTS file parameter for max data rate, do you think that my modification is a decent way to accomplish my goal? Thanks, Lee From owner-freebsd-arm@freebsd.org Fri Sep 30 02:39:45 2016 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 398EAC027EB for ; Fri, 30 Sep 2016 02:39:45 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 E67F31EED for ; Fri, 30 Sep 2016 02:39:44 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id z190so95562965qkc.3 for ; Thu, 29 Sep 2016 19:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2f1E0jqHHo6f7pjCPWL8fmRr+ttIB5m8y1uckocyLlI=; b=MOPeycF6S/4im561F4U/ldFRj8Ac7eGwhNXQ2lIxxMCa6l/8pAW2QRKUIJGlJ5v5Ej 0G+sTygvRkpAKfxAngnk0rH+3BNXlYN2UUAwJOKDcSj7vTcSPAlAIbfvCWvTDhlzGzga AxLFYmsCNsn1/BCYOKOgBY+vyXBPWSrVGT1Z5ZVfgig3WsUt1mGgITEgbauOolFuZC4A qJ7DxhpIt8btBzlKIYIJtfsZSd5q929QK9LO99RLRlPVsDoW6HwELUm3SOVcQ9oxOmfN NaBlaLqcnb7llmTHDcPV9uAcPlQZao+5sDccAfuY+LMHU3WQZ9Kgb/PPpEXXHoGYwMW5 zvJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2f1E0jqHHo6f7pjCPWL8fmRr+ttIB5m8y1uckocyLlI=; b=iyTSDWKYj4L8isNxijhuIG/mRohQQr062rYPr1DxSjj90BAn2YbkwL+jN/qHneY4TG NuYkZxdGgfH+P9TXzn4/c9TVKPXmfCF6VMUKcZK+Le3uhWY2X9dUuyFhMO1j/n8WNxMY V/VstFU4EfRF68DLDjbl0XmY+SBaHAN3zKaY1uPSRSfrFYbTM7ZjEYYDbQBSXTv61Zsh mArKXne23nBfUY5WhWtBneMv6hzbx2l76fTc5YCmb+pCCggsS4ThDzMyI/ZdiyvIRLI7 wA6sJC5QUF7bkITclPGqr6llRXTK9Di1ClzYBX1KdkFY32EakeBO0ydpy/pt46AVneok lAsw== X-Gm-Message-State: AA6/9RkHl6UVrF3fIz4ovVvA1noLve7DLdgSshZs32KSjsF4aK0FNayvCYxuYZ83cCLXP7+SBxr9TgWLK92NwQ== X-Received: by 10.55.185.130 with SMTP id j124mr4480503qkf.84.1475203184134; Thu, 29 Sep 2016 19:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.194 with HTTP; Thu, 29 Sep 2016 19:39:43 -0700 (PDT) In-Reply-To: <9859398E-0592-4B8F-A3DA-0364970A92B4@bluezbox.com> References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com> <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com> <9859398E-0592-4B8F-A3DA-0364970A92B4@bluezbox.com> From: Lee D Date: Thu, 29 Sep 2016 22:39:43 -0400 Message-ID: Subject: Re: SD-Card driver modification for Zynq questions To: Oleksandr Tymoshenko Cc: Thomas Skibo , freebsd-arm 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: Fri, 30 Sep 2016 02:39:45 -0000 On Wed, Sep 28, 2016 at 5:53 PM, Oleksandr Tymoshenko wrote: > > > On Sep 28, 2016, at 2:49 PM, Thomas Skibo wrote= : > > > > > >> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko > wrote: > >> > >> > >>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm < > freebsd-arm@freebsd.org> wrote: > >>> > >>> > >>> Why not just set max-frequency to 200Mhz in the DTS file entry? > >> > >> From quick glance it=E2=80=99s not going to help. Slot=E2=80=99s max_c= lk is set to that > value but then it=E2=80=99s > >> overwritten in sdhci_init_slot by value obtained from register. We > need to fix it and also > >> add tunable for non-fdt systems. > > > > I checked the Zynq manual and it looks like it doesn=E2=80=99t provide = a > frequency in the capabilities register so sdhci_init_slot() won=E2=80=99t= change > the slot=E2=80=99s max_clk. > > You=E2=80=99re right, I misread code, max-frequency can do the trick. St= ill > tunable may be a good idea. Setting max-frequency to an incorrect value will technically work, but it will make many cards run much more slowly than they need to. See my other post. It would be nice to have a DTS file parameter to set the max data rate of the card. Do you have any pointers on where I might find information on how to do this? I have read "FreeBSD Device Drivers: A guide for the intrepid", but it only scratches the surface. I've written a few drivers for my custom devices but I think I am pretty far from being able to do any serious kernel work. One thing I am confused about is how drivers talk to each other. I spent a few days trying to understand the source for the mmc and sdhci drivers but there is a lot going on that I couldn't figure out. Thanks, Lee From owner-freebsd-arm@freebsd.org Fri Sep 30 23:28:22 2016 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 7B1F2C04DDE for ; Fri, 30 Sep 2016 23:28:22 +0000 (UTC) (envelope-from contact=lactasoy.com@txm15.net) Received: from svout-c19-48.txmsv.com (svout-c19-48.txmsv.com [203.150.19.48]) by mx1.freebsd.org (Postfix) with ESMTP id C0FAF10F5 for ; Fri, 30 Sep 2016 23:28:21 +0000 (UTC) (envelope-from contact=lactasoy.com@txm15.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mail; d=txm15.net; h=Date:Sender:To:From:Reply-to:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type; i=contact=3Dlactasoy.com@txm15.net; bh=Vl/v6vSvAZtoSc5Sb1HHqKEjcuw=; b=eW2Dig010Ah6aCl8O8ovC8YdON+37HEtrGSpnYe1ZeIVhWOGAc71UFjOhgLcNpXZ0e5GY+ko3bkw uL1dY886NcbScDhtkOOCjBsL/Bd/FXXHX4bhfUlDIfPnLZmQk/B3Yvrb8awClAlsvaM42ffcYK5s wfo3eM1S8SjRwcKzuCY= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=mail; d=txm15.net; b=Ncmt2BrQ72Owvk6RSZCOwBUf+T/H+H4Iw8KFL/6HpfMcBVKrQgILdDHpXULgiTNiij6kKt3w/1o8 wKiaX8lMNRU6e1sJWgiZsEbbzKmRxcEOS4f3sBIDry6JP7S4nuELmkPYCS0saFMhqF2AAi/Vy1BZ 4AU7C8z0NvHIjl+0E+o=; Received: from localhost.localdomain (203.150.19.243) by svout-c19-48.txmsv.com for ; Sat, 1 Oct 2016 06:25:07 +0700 (envelope-from ) Date: Sat, 1 Oct 2016 06:25:06 +0700 Sender: =?UTF-8?B?4LmB4Lil4LiE4LiV4Liy4LiL4Lit4LiiIOC4nuC4peC4seC4h+C5gOC4iCDguJ7guKXguLHguIfguYPguIg=?= To: freebsd-arm@freebsd.org From: =?UTF-8?B?4LmB4Lil4LiE4LiV4Liy4LiL4Lit4LiiIOC4nuC4peC4seC4h+C5gOC4iCA=?= =?UTF-8?B?4Lie4Lil4Lix4LiH4LmD4LiI?= Reply-to: =?UTF-8?B?4LmB4Lil4LiE4LiV4Liy4LiL4Lit4LiiIOC4nuC4peC4seC4h+C5gOC4iCA=?= =?UTF-8?B?4Lie4Lil4Lix4LiH4LmD4LiI?= Subject: =?windows-874?B?4L7VwqfD6MfB4arD7KHUqKHDw8G51ekgoefgu+e5yujHucu51uin47mh0sPK?= =?windows-874?B?wbe6t9i5qujHwuDLxdfNvNnpu+jHwuLDpMvRx+OoIKHRuiDDvi6o2MzSxaeh?= =?windows-874?B?w7PsysDSodKq0rTkt8I=?= Message-ID: <0254238926b6b7784eb9a3058da71c01@localhost.localdomain> X-Mailer: TaxiMail2 X-Mailer-Pool: recipient-5 X-Campaign: 515-51-d008qvb-57eef1dc59d262335406c940 X-Complaints-To: fbl@txm15.net X-Report-Abuse: http://lactasoy.th.listmng.com/cb/f/515/51/d008qvb X-Report-Abuse-To: fbl@txm15.net MIME-Version: 1.0 Content-Type: text/plain; charset = "UTF-8" Content-Transfer-Encoding: base64 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, 30 Sep 2016 23:28:22 -0000 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CklzIHRoaXMgZW1haWwgbm90IGRpc3BsYXlpbmcgY29ycmVjdGx5PyBWaWV3IGl0IGluIHlvdXIg YnJvd3NlciBhdCBodHRwOi8vbGFjdGFzb3kudGgubGlzdG1uZy5jb20vY2IvYi81MTUvNTEvZDAw OHF2Yi9GCgpUaGlzIG1lc3NhZ2Ugd2FzIGRlbGl2ZXJlZCB0byBmcmVlYnNkLWFybUBmcmVlYnNk Lm9yZy4KSWYgeW91IHByZWZlciBub3QgdG8gcmVjZWl2ZSB0aGVzZSBtZXNzYWdlcyBpbiB0aGUg ZnV0dXJlLCBwbGVhc2UgdW5zdWJzY3JpYmUgYXQgaHR0cDovL2xhY3Rhc295LnRoLmxpc3Rtbmcu Y29tL2cvdS81MTUvNTEvZDAwOHF2Yi9GCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQrCqSAyMDE2IExhY3Rhc295IENvLiwgTHRkLiBBbGwg cmlnaHQgcmVzZXJ2ZWQuCiAzMzUyIFN1a2h1bXZpdCBSb2FkLCBCYW5nbmEsIEJhbmduYSwgQmFu Z2tvayAxMDI2MA== From owner-freebsd-arm@freebsd.org Sat Oct 1 10:30:44 2016 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 552F3C037A6 for ; Sat, 1 Oct 2016 10:30:44 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh504-vm3.bullet.mail.kks.yahoo.co.jp (nh504-vm3.bullet.mail.kks.yahoo.co.jp [183.79.57.89]) by mx1.freebsd.org (Postfix) with SMTP id EB04BF03 for ; Sat, 1 Oct 2016 10:30:43 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.141] by nh504.bullet.mail.kks.yahoo.co.jp with NNFMP; 01 Oct 2016 10:29:00 -0000 Received: from [183.79.100.133] by t504.bullet.mail.kks.yahoo.co.jp with NNFMP; 01 Oct 2016 10:29:00 -0000 Received: from [127.0.0.1] by omp502.mail.kks.yahoo.co.jp with NNFMP; 01 Oct 2016 10:29:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 615565.39995.bm@omp502.mail.kks.yahoo.co.jp Received: (qmail 96744 invoked by uid 60001); 1 Oct 2016 10:29:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1475317740; bh=Bv2UJk3q1fm/9i+WlI2nd+2DuoaWzB2P9L0/IJm+APw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IBe5gaqfoCmfI/YoqA0ZTrZf9z1vV2sDH6xunuEoyvFIE1N5eFHx00vZtKz003sSHMU496Wl53qKo+BpovmD9/dzi45hL05L+RdvmJSopXg16QAIYeb6YkuW669FmG+gxihz2gV/OZ/Off28sB5W3goNWRyYY2761Jpli0Ak7yA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nHPBrNHwiiQaPBevpJwF1TXaif5i8CplM0kGkuIhLDr9uyzEo3Tm8I/9tmByP7psVXWFfpV0oJ5eY2irQCn8xwFGv/payXZXnRbiIlS/MME346pTiR5ZJRFvPWoFgl4IJSWFtOTAKnKTdr4yB1J246vCPq9HesvdSj6W0YdJ8cA=; Message-ID: <309539.93259.qm@web101708.mail.ssk.yahoo.co.jp> X-YMail-OSG: 27qY8KEVM1llD4RCDtXy_vqg4E1msiltw8irnfQLt6ZXHF9erRKOTfroBnra6ti5gQvhXt0PYvl7nHjamDO19wmROwj8.7ig_9C6ZHkhL8PuWz2zY5GVDGHcrf5TqmkK7b4Tx5tkuOvuZ06SN1_ppT2rA7x9ZtRzNPvkBiNZ6POoz0_BWoPyEFGKfXNZF12NbqYKpnKS6imtsBm0M9h4GLSYhArLT7G8tAaNVDaDKXTnXdhjwtFmw86K7Q5WjZ79L3gzygYqX5wBn5M865KuJ222Ak33oUNyvo3HE.GBwc5Ta7hrzdKVolQQoQGQwdlmFghtfm_iRedN1iRh4zDd6TvCdNDjQbIsop2XXFD3hNFMWea7hfXW.nuC87IdGupa0E2O4Kwq8amAgOilioXOZizPmwitKgpS2A9qZTHLbuyamgH_k8AahPCHed6GxGhAfkPly6Y3_g.q1RHQ8ryyeHUVrEmpaM4Wg9owMUUiw06xYATPsbwgMoMahl3fP5LRP8oCwvj9h945UFzf_QpV2vzbuT4cxr7gz2Qevs8ZnJpyt6O9K47o Received: from [110.134.196.53] by web101708.mail.ssk.yahoo.co.jp via HTTP; Sat, 01 Oct 2016 19:29:00 JST X-Mailer: YahooMailWebService/0.8.111_69 X-YMail-JAS: L0slSO8VM1kFGkK3cRzFaelj5d5WQzNoWXkWL3KJ5B0XHuWMMS5x6TXGDkNcPmi8U6QYWnM6xCFqFrrSVr3rZKAPKLaczIAvQYT.SdQkaYRUJXaBLwhgulz7JnLzG_pv93Sr References: <201604191539.u3JFdkHx048678@repo.freebsd.org> <20160419171243.GA30453@bsdpad.com> <1461097280.1232.34.camel@freebsd.org> Date: Sat, 1 Oct 2016 19:29:00 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: svn commit: r298274 - head/sys/dev/spibus To: Adrian Chadd , Patrick Kelsey Cc: "freebsd-arm@freebsd.org" , Ruslan Bukin , "freebsd-mips@freebsd.org" In-Reply-To: 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: Sat, 01 Oct 2016 10:30:44 -0000 Hi.=0A=0AI add SD card socket to my=A0WZR-HP-G300NH(AR9132).=0A=0Ahttps://f= lic.kr/p/MAuUBf=0A=0A=0AI am looking forward to support mmcspi.=0A=0ARegard= s=0A=0AHiroki Mori=0A=0A=0A----- Original Message -----=0A> From: Adrian Ch= add =0A> To: Patrick Kelsey =0A> C= c: "freebsd-arm@freebsd.org" ; Ruslan Bukin ; "freebsd-mips@freebsd.org" =0A> Date:= 2016/5/26, Thu 14:00=0A> Subject: Re: svn commit: r298274 - head/sys/dev/s= pibus=0A> =0A> On 25 May 2016 at 18:57, Patrick Kelsey wrote:=0A>> =0A>> On Fri, May 20, 2016 at 2:35 AM, Adrian Chadd =0A> wrote:=0A>>> =0A>>> I've reviewed the patches from luiz,= and these look fine. but =0A> indeed,=0A>>> this patchset does set/releas= e the bus each transaction so we can do=0A>>> multiple transactions whilst= holding the bus.=0A>>> =0A>>> Which is fine, but it means I have to undo = ruslan's removal in the =0A> below=0A>>> commit.=0A>>> =0A>>> I'm happy t= o run through and do each of the spi bus drivers (as =0A> there=0A>>> are = more now than the two you patched) but it's a bit close to the=0A>>> 11.0-= release cycle to go and churn the spibus code.=0A>>> =0A>>> But, if people= think it's worth doing it so we can try to get =0A> mmcspi=0A>>> into the= tree before 11.0-rel is cut, I'm happy to run through and =0A> do=0A>>> i= t. I actually have some AR9331 stuff now that could use mmcspi. :)=0A>>> = =0A>>> What do people think?=0A>>> =0A>> =0A>> Thanks, Adrian.=A0 My opin= ion is that the changes to the spi bus interface =0A> and=0A>> the corresp= onding changes to the spi bus drivers you are talking about are=0A>> very = straightforward and low risk.=A0 There is non-zero other interest out=0A>> = there in using the mmcspi driver, based on the couple of emails I've=0A>> = received seeking help on the subject in the last six months or so, so I=0A= >> don't think this would be just a commit for the sake of getting some=0A= >> interesting new code in.=0A> =0A> loos and i are thinking about it. I m= ay start landing some of the=0A> spibus changes tonight just to lay the fou= ndation.=0A> =0A> =0A> =0A> -adrian=0A> ___________________________________= ____________=0A> freebsd-mips@freebsd.org mailing list=0A> https://lists.fr= eebsd.org/mailman/listinfo/freebsd-mips=0A> To unsubscribe, send any mail t= o =0A> "freebsd-mips-unsubscribe@freebsd.org"=0A> From owner-freebsd-arm@freebsd.org Sat Oct 1 23:18:08 2016 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 DA83FA94E60 for ; Sat, 1 Oct 2016 23:18:08 +0000 (UTC) (envelope-from lists@felix-maurer.de) Received: from mail.felix-maurer.de (felix-maurer.de [IPv6:2a02:c200:1:10:3:0:7193:1]) by mx1.freebsd.org (Postfix) with ESMTP id A898F19A for ; Sat, 1 Oct 2016 23:18:08 +0000 (UTC) (envelope-from lists@felix-maurer.de) Received: from Felix-MBP.fritz.box (p2003008B2F5CE700D94B6D71FB913B91.dip0.t-ipconnect.de [IPv6:2003:8b:2f5c:e700:d94b:6d71:fb91:3b91]) by mail.felix-maurer.de (Postfix) with ESMTPSA id 933781B84770 for ; Sun, 2 Oct 2016 01:17:05 +0200 (CEST) Message-ID: <57F0440A.4060709@felix-maurer.de> Date: Sun, 02 Oct 2016 01:17:30 +0200 From: Felix Maurer User-Agent: Postbox 5.0.3 (Macintosh/20160930) MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: FreeBSD on Pine64: ubldr for arm64 X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 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, 01 Oct 2016 23:18:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I am currently trying to build a FreeBSD image with Crochet to boot on the Pine64. Thanks to the sysutils/u-boot-pine64 port I already got a working SPL that starts U-Boot. The normal way to continue booting a image built by Crochet is to start ubldr. But at the moment there is no arm64 version of ubldr in the tree. The only thing I found about this is this diff: https://reviews.freebsd.org/D5512 . It has been lying around there since March and the last comments state that the changes are unnecessary now for the RPI3 because a way has been found to boot on a RPI3 without U-Boot. Now I have two questions: 1. Is there a chance for the diff to make it into the tree? Although it is no longer needed for the RPI3 it may be needed by other boards. 2. As an alternative: What is this mysterious way to boot without U-Boot and may this be possible for other boards like the Pine64? Regards, Felix -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJX8EQKAAoJEEy46Yy6oqJ0ZZYQAIdDp6zwuCa7FsP1XGcOomnw qYftBWerVZZYuiXKrwtmAaKDY/OTn4WNwvEMUa5Zp4ny01QUV5DW+TcbDfdfV/9W T+dNOhsbzWbUvaK3U2y8fmrNs8TswtEENpFhlaPWNeloDqocFtvyvTKS7IQQYnMQ UFE+VPvMw9kZORKblNdQb4e4sGgQdq2QtyFaPmtrpzg8ax0NJFciRG7myhrVqQ5R kOClK5loPJSfSebN7YpePablGHjXyS/IKjtvds5VpDMe8jJ8b+dPmHCumeSJ6vor lccX6J+WXlLtdCeIBD8Z1TMT4XKX6Gz60WWMSf6XysNldkxl2y2k9mfSTTxGdygc SSDpRGZh7xqwySZhF6/7L6Wz/uwXp9iI94BgW+uTXlJ0+GARt+xR4ArNL4jYFED2 eLxvTyVVxt8lCVMJZAPdVH87SEB1MNEwzYzu8r7Hmj+5q9rUyv3bJeCnRPdf9XAP DQVRYvimVW7uR21REYlwb+uS/169As0g7LR5kk2zBbaemc8PcL4QAvyTNwpLWYfS qznwqcN1ca1Unoo9vn7zYPmBavKunobrbjl4GjKDh1kuOmWKx4C+LUj7qT8+yAY9 SgD/98Wl8QMTNmCdgICVMYHdyzDVO66WLBI48kbEESi1RT/ESbQAm6bCScl8h+Av /znPEvXG2SCueYu34EPF =CGiK -----END PGP SIGNATURE-----