Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Jan 2014 19:57:12 -0800
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Glen Barber <gjb@freebsd.org>, freebsd-arm@freebsd.org
Subject:   Re: Rasbperry Pi, what should TARGET_ARCH be?
Message-ID:  <20140126035712.GM13704@funkthat.com>
In-Reply-To: <EA652D79-EB0B-440A-8AA8-F38A50F65DBD@bsdimp.com>
References:  <20140125044043.GT52955@glenbarber.us> <EEBDA9FC-ADCC-4C0E-A224-BB0DA234E717@bsdimp.com> <20140125181256.GE13704@funkthat.com> <EA652D79-EB0B-440A-8AA8-F38A50F65DBD@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
> 
> > 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:
> >> 
> >>> Hi,
> >>> 
> >>> 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.
> >>> 
> >>> 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.
> >> 
> >> If that worked, it worked by accident.
> >> 
> >>> 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'.
> >>> 
> >>> Hiren poked around the Crochet code, and saw that 'TARGET_ARCH=arm' is
> >>> set for the RaspberryPi board by default.
> >> 
> >> This is incorrect.
> >> 
> >>> As a "just in case" experiment, I retried the 10.0-RELEASE code
> >>> (release/10.0.0/) with TARGET_ARCH=armv6, and sure enough, it works.
> >>> 
> >>> But, I don't know *why*.
> >> 
> >> It works because that's the architecture that the RPi runs.
> >> 
> >>> Is this a change between head/ and stable/10/ versus releng/10.0/ ?
> >>> 
> >>> 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.
> >> 
> >> The definition should be the same on both branches. You must use TARGET_ARCH=armv6 on all known branches to produce working code.  You might get lucky and get TARGET_ARCH=arm and have it work, but that's most definitely not a supported configuration.
> >> 
> >>> So, what should be used?  And where?
> >> 
> >> For RPi, TARGET_ARCH=armv6 everywhere on all branches >= 9. RPi isn't supported 8 and lower.
> > 
> > May I propose this patch:
> > https://www.funkthat.com/~jmg/kerncheckarch.patch
> > 
> > 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...
> > 
> > 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. 
> 
> 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.

Then we could remove the uname checks and put the remaining under .if
defined() and provide at least some seatbelts...

> 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.

That's pointless since the MACHINE_ARCH line in the Makefile IS populated
from the config file...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140126035712.GM13704>