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= "