From owner-freebsd-arm@FreeBSD.ORG Sat Jan 25 18:29:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC620AFF for ; Sat, 25 Jan 2014 18:29:29 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8497F1719 for ; Sat, 25 Jan 2014 18:29:29 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id ar20so4263270iec.10 for ; Sat, 25 Jan 2014 10:29:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xEx+V7lsldatcPQfQWFu9X5fXlJj1q3GoB+Ug/M9NDE=; b=j67m9C6H5ZE9UehKLHhz7j8vkbL0Bz1dKts679S09lfsNjVjRqvuwo5MsOrVRVVOiF 0CiCamrmXAqFiifml6Q9aQsRnUZpIjsU3iiEYubxsPGMR9p6YqfEBmqYWXe6oeEKVi7d 4enr85/y15K/fz9sj1qtbbuEfoUHeXBQMDOE4obDfCQmxYe7grsI+SV/CyGPKC5s2XcD Znn7VGJBSjGLUNH/McrjUPFdWQfl14VtQdijL7O1xIzbrirSztDHYOSZBiycg9UTbR+U Og7806Wc4zZY0R6fUheidokBn1WraRbX7w4nt+74h5OLC1NF3PBfmf3JWrg0Qu2j+9kx Hh5g== X-Gm-Message-State: ALoCoQmqj227nCKI10QCkd+AW/S8pTu1GXKOc6HxDiuqDiOGqNxPV4ohTN91GXPZOUj97OIeiK+k X-Received: by 10.42.121.147 with SMTP id j19mr15735349icr.13.1390674167797; Sat, 25 Jan 2014 10:22:47 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id kz4sm8118940igb.4.2014.01.25.10.22.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 10:22:47 -0800 (PST) Sender: Warner Losh Subject: Re: Rasbperry Pi, what should TARGET_ARCH be? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140125181256.GE13704@funkthat.com> Date: Sat, 25 Jan 2014 11:22:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140125044043.GT52955@glenbarber.us> <20140125181256.GE13704@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) Cc: Glen Barber , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 18:29:29 -0000 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=