Date: Sun, 25 Sep 2016 21:03:30 -0700 From: Russell Haley <russ.haley@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? Message-ID: <CABx9NuQy-Jh8cNDz5iA_dWzPyF4dJHQW6JJoOyjnSkk=FdrhQQ@mail.gmail.com> In-Reply-To: <CANCZdfo9BMThmEvnwmm3rg1OMU=SsETKSBUiX-wwjUDdnT2M5Q@mail.gmail.com> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <CANCZdfqM17qzZg2SqwJRTWO67KCnAC%2BHYKatcb8CBHF3TM7kFg@mail.gmail.com> <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> <CABx9NuRv69k0u84%2B3bpDGPM1U7DsZJUtBC42jktk3ttinY9p%2BA@mail.gmail.com> <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF%2BEEwww@mail.gmail.com> <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com> <CANCZdfo9BMThmEvnwmm3rg1OMU=SsETKSBUiX-wwjUDdnT2M5Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 25, 2016 at 10:19 AM, Warner Losh <imp@bsdimp.com> wrote: > On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley <russ.haley@gmail.com> wro= te: >> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh <imp@bsdimp.com> wrote: >>> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley <russ.haley@gmail.com> = wrote: >>>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wr= ote: >>>>> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote: >>>>> >>>>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> = 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= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuQy-Jh8cNDz5iA_dWzPyF4dJHQW6JJoOyjnSkk=FdrhQQ>