Date: Sat, 25 Jan 2014 21:17:15 -0700 From: Warner Losh <imp@bsdimp.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Glen Barber <gjb@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: Rasbperry Pi, what should TARGET_ARCH be? Message-ID: <7D3D51ED-4DDC-484F-9374-877EABB06200@bsdimp.com> In-Reply-To: <20140126035712.GM13704@funkthat.com> References: <20140125044043.GT52955@glenbarber.us> <EEBDA9FC-ADCC-4C0E-A224-BB0DA234E717@bsdimp.com> <20140125181256.GE13704@funkthat.com> <EA652D79-EB0B-440A-8AA8-F38A50F65DBD@bsdimp.com> <20140126035712.GM13704@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 25, 2014, at 8:57 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Sat, Jan 25, 2014 at 11:22 -0700: >> On Jan 25, 2014, at 11:12 AM, John-Mark Gurney wrote: >>=20 >>> Warner Losh wrote this message on Sat, Jan 25, 2014 at 10:50 -0700: >>>> On Jan 24, 2014, at 9:40 PM, Glen Barber wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I've been working on adding support for embedded systems to the = release >>>>> scripts, which set up a chroot to ensure a clean build = environment, then >>>>> runs Tim's Crochet scripts. >>>>>=20 >>>>> For the RPI-B, recent updates to the build scripts work fine for >>>>> 11.0-CURRENT and 10.0-STABLE. However, 10.0-RELEASE images fail = to >>>>> boot. >>>>=20 >>>> If that worked, it worked by accident. >>>>=20 >>>>> I showed output from 'uname -pm' out-of-band of an 11.0-CURRENT = image, >>>>> and was suspicious that the output showed 'arm arm', not 'arm = armv6'. >>>>> Warner had the same impression it should be 'arm armv6'. >>>>>=20 >>>>> Hiren poked around the Crochet code, and saw that = 'TARGET_ARCH=3Darm' is >>>>> set for the RaspberryPi board by default. >>>>=20 >>>> This is incorrect. >>>>=20 >>>>> As a "just in case" experiment, I retried the 10.0-RELEASE code >>>>> (release/10.0.0/) with TARGET_ARCH=3Darmv6, and sure enough, it = works. >>>>>=20 >>>>> But, I don't know *why*. >>>>=20 >>>> It works because that's the architecture that the RPi runs. >>>>=20 >>>>> Is this a change between head/ and stable/10/ versus releng/10.0/ = ? >>>>>=20 >>>>> I can handle a differentiation between the branches with regard to = this >>>>> (sort of), but I want to make sure the correct TARGET_ARCH is = being set >>>>> across the different branches, so it can be handled properly in = the >>>>> build scripts, and usable images can be produced. >>>>=20 >>>> The definition should be the same on both branches. You must use = TARGET_ARCH=3Darmv6 on all known branches to produce working code. You = might get lucky and get TARGET_ARCH=3Darm and have it work, but that's = most definitely not a supported configuration. >>>>=20 >>>>> So, what should be used? And where? >>>>=20 >>>> For RPi, TARGET_ARCH=3Darmv6 everywhere on all branches >=3D 9. RPi = isn't supported 8 and lower. >>>=20 >>> May I propose this patch: >>> https://www.funkthat.com/~jmg/kerncheckarch.patch >>>=20 >>> This uses either TARGET[_ARCH] or uname -[mp] to make sure that the >>> they match w/ the new kernel being built... I believe I did get the >>> -m and -p w/ the correct order, but as I don't have a machine where >>> they different, I can't confirm... >>>=20 >>> This would prevent the issue that Glen experienced... >>=20 >> I hate uname checks. They are almost always wrong. I've been burned = too many times in the past by them, and strongly oppose them on general = principals.=20 >>=20 >> TARGET won't necessarily be defined when building the kernel, so this = patch can't possibly do what you want it to do. Any place outside of = Makefile and Makefile.inc1 that checks for it is generally wrong (with = the exception of some of the cross tools that support being built = standalone outside of makeworld). I believe that at most it will detect = when you are cross building and fail. >=20 > Then we could remove the uname checks and put the remaining under .if > defined() and provide at least some seatbelts... But the remaining is bogus. TARGET isn't defined here (and if it is, it = is an accidental leakage, not an intentional thing) >> Better to check the arch line in the kernel config file matches the = MARCHINE_ARCH. This can likely be done with a tiny bit of config magic = in one of the generated files so the build will check the right = preprocessor defines. There's some magic to do something similar for the = universe builds. >=20 > That's pointless since the MACHINE_ARCH line in the Makefile IS = populated > from the config file... Sure, config generates MACHINE_ARCH, so there's nothing to check. You = can't test against TARGET_ARCH, because that's not defined (or not = guaranteed to be defined), and you can't test against uname because = that's irrelevant. Normally, we define __${MACHINE_ARCH} in the default defines for = building toolchain. Config could generate a .c or .h that tests to make = sure that __${MACHINE_ARCH} is defined, but that's not entirely = foolproof. That's the only place we can rest for sure. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7D3D51ED-4DDC-484F-9374-877EABB06200>