Date: Sat, 25 Jan 2014 11:22:47 -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: <EA652D79-EB0B-440A-8AA8-F38A50F65DBD@bsdimp.com> In-Reply-To: <20140125181256.GE13704@funkthat.com> References: <20140125044043.GT52955@glenbarber.us> <EEBDA9FC-ADCC-4C0E-A224-BB0DA234E717@bsdimp.com> <20140125181256.GE13704@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 25, 2014, at 11:12 AM, John-Mark Gurney wrote: > 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... 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 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. 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. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA652D79-EB0B-440A-8AA8-F38A50F65DBD>