From owner-freebsd-arm@FreeBSD.ORG Sun Jan 26 04:17:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4902D3E2 for ; Sun, 26 Jan 2014 04:17:19 +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 0FE64154F for ; Sun, 26 Jan 2014 04:17:18 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id ar20so4389643iec.24 for ; Sat, 25 Jan 2014 20:17:18 -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=RH0UacwppW21VomYaAhaVXa9njZf/0ZdirW9uAbymwU=; b=IistKnNLMTUw06nAjC00vYlOYYDW+Y5iPZioGqL2rQs69y2QMTKxuJyrgB4hDTWjZE 9Fr+dcUO3dYseIEf61kQnX4uXmvLz/lGx0zvYYHZnLidhliNlCQVY0XLWib0MtbB5ur+ sYaH2jWxEEnMfyz1AbsecOw5YtbmRop7Xmij4KpA8LZfYQQNbbA21zd0h8MqLx40EM8r FXLxAU4067hb0iVJFRIlbkZAN2xS36sk0GKNffjg6JNAcA5hxQXP+NGDYlimOw+ONC0k twoUL5hopqo3/0KkDyTn0nzbj1CwDl3lUDx7LB0z72HZ200S1/ciDZoYRmSXdASSyXEh euLg== X-Gm-Message-State: ALoCoQnKDNXWrv13EsVt/kkqbJwl7sl1hXFTVvkn35g52xRcmvjs5mP0/cdWNUd/rRm26GYgRQ2I X-Received: by 10.50.78.200 with SMTP id d8mr11648910igx.38.1390709837932; Sat, 25 Jan 2014 20:17:17 -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 kt2sm37301625igb.1.2014.01.25.20.17.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 20:17:16 -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: <20140126035712.GM13704@funkthat.com> Date: Sat, 25 Jan 2014 21:17:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D3D51ED-4DDC-484F-9374-877EABB06200@bsdimp.com> References: <20140125044043.GT52955@glenbarber.us> <20140125181256.GE13704@funkthat.com> <20140126035712.GM13704@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: Sun, 26 Jan 2014 04:17:19 -0000 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=