From owner-freebsd-arm@freebsd.org Sat Oct 14 06:28:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6076E3E754 for ; Sat, 14 Oct 2017 06:28:34 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A596654C5 for ; Sat, 14 Oct 2017 06:28:34 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wr0-x243.google.com with SMTP id k15so1900543wrc.4 for ; Fri, 13 Oct 2017 23:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=JrDz3l0iSoRujCdb3/9WTBxLBb44n/v79cGYPI4j4SY=; b=cUo1xJeNHtpz4TdSs058Bbw72IkuMLVBeVY8WnMcML0UggL9lXqzKprIokNTAXhb5s 42XPECI7jsJkP6HBwTQAowCK0hgbqrMFhnhcfruh25bSc2YH4T9CgoZOKVjaMwldy8oT 1HxLXSUp3D0Glgyyu5S9CypbDj7BN7/l4/xNErHkMVcVlpzSHnWaz3XPRM/aLOsk3+dt 33azzNgZbwwzMbPbp87cpa2Yr2Xh2QnFo1j9f3E6gfJrfgHhP4Kv7wkByGJ8lbUomIcP b2UIqCj0tAiCbzp3JMjWg0Iz61k3Visdo9dpyMlbhaaPPKMyFv96YVcgERmyzZC3QMMG sV8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=JrDz3l0iSoRujCdb3/9WTBxLBb44n/v79cGYPI4j4SY=; b=UjNmfAprp/FoNeJfWjqkbz8PRb4j7zRknHB5nHfLBmEMmwUdfaWI9o/4y8d3h/vcZQ 0yalJSwthGxEBeVkNSLgv8urEKXpXuc18esMejki7eHnYU7vJ91bqiGOcBF6WGQ/E7Kt P2Q4m7rZYsMwQsuNCSQI9YjgQ9ZOH69tA791+i1H7eA0GXlKMp4F7wB5TyvsWTM7Kjmp ltfFsEmFyQQXHbbHgZOE5NDuvu2vVl/+bhp6Uz1PqkXk2w+jpLldk6m5qncuRXJ5U4ZS cAKyoy4odx3J1sEphCePKYb6m74iQ+Xm3E1KZJ0MLb1SUdqRfYGZawJWPH0R3bLwwBy9 tu4g== X-Gm-Message-State: AMCzsaVDAcKx8EFu8O2AzPRI/dD8c9/BPgvJRv2yc0V2E+81x0EJ3aug Dagx9gpj9V9imB2Db/RjUmDtmTOFW3I= X-Google-Smtp-Source: AOwi7QD8mByhSCDQ698+/4rxchsfVtlldHewnKjorc16lIP66ESLBKVuFJ6xc2+/5AE3eLMAwcL0Vg== X-Received: by 10.223.135.21 with SMTP id a21mr2917561wra.245.1507962512731; Fri, 13 Oct 2017 23:28:32 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id m25sm2901373wmi.7.2017.10.13.23.28.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 23:28:32 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: Difficulty with armv6 to v7 transition. To: bob prohaska Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska References: <20171011030021.GB57571@www.zefox.net> <20171013020604.GA70845@www.zefox.net> <20171013175943.GA74121@www.zefox.net> <20171014010713.GA75288@www.zefox.net> <254A2C41-59A9-4E4E-8982-ADDBAE2B5F91@dsl-only.net> <20171014021133.GB75288@www.zefox.net> <39f6419f-48f3-aaec-dfa4-3048c8a893d8@freebsd.org> <20171014054706.GC75288@www.zefox.net> Message-ID: <559584b5-47c6-b9f8-9fae-43ee76fc99cc@freebsd.org> Date: Sat, 14 Oct 2017 08:28:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171014054706.GC75288@www.zefox.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 06:28:35 -0000 On 14.10.2017 7:47, bob prohaska wrote: > Hi Michal, > > On Sat, Oct 14, 2017 at 06:28:13AM +0200, Michal Meloun wrote: >> Bob, >> can you please try this? >> setenv MACHINE_ARCH armv7; make buildworld TARGET=arm TARGET_ARCH=armv7 >> > I _believe_ I did try that, with no success, but the scrollback buffer > isn't long enough to let me verify it. > > Right now the machine is running buildworld, using > BUILD_ARCH!= echo armv7 > in /usr/src/Makefile.inc1 to set BUILD_ARCH. If the > buildworld fails I'll try setenv, just to verify. Should know > late Saturday or early Sunday. > A more immediate puzzle is how to test whether the buildworld command > produced an armv7 userland, or something else, before running installworld. > I'd hate to trash the system _again_. Running clang -v ought to give a > good hint, if I can find the executable. Is there a better test? > For not-installed world executable you can dump ABI version encoded in .note.tag section: ' objdump -s -j .note.tag  //bin/sh' the right binary have something like this: ----------------------------------------------------- /bin/sh:     file format elf32-littlearm Contents of section .note.tag:  814c 08000000 04000000 01000000 46726565  ............Free  815c 42534400 b24f1200 08000000 04000000  BSD..O..........  816c 02000000 46726565 42534400 00000000  ....FreeBSD.....  817c 08000000 06000000 03000000 46726565  ............Free  818c 42534400 61726d76 37000000           BSD.armv7... ------------------------------------------------------- where ' FreeBSD.armv7' is ABI version. For installed world, the next method is 'make -V MACHINE_ARCH -f/dev/null' And for kernel, 'sysctl kern.supported_archs' and 'sysctl  hw.machine_arch' shoul return armv7 > Thanks! > > bob prohaska > > > >>>> BUILD_ARCH should end up matching what >>>> you start under, not the end target as >>>> I understand things. >>>> >>>> If I tried a cross build on a host >>>> other than armv7 that BUILD_ARCH result >>>> would be wrong. (I use amd64 for cross >>>> building aarch64 and arm6 . I'm not up to >>>> an armv7 capable context yet and may not >>>> be for some time.) >>>> >>>> That change is a local workaround that is >>>> specific to the environment you are using >>>> for a build. >>>> >>>> This is like my 12.0-CURRENT change being >>>> specific to my not building on 11.x or 10.x . >>>> It is just a local workaround that applies >>>> just to a more limited context. >>>> >>>> I've not figured out what is going on (how/why) >>>> for the != uname behavior that I observed. But >>>> echoing the expected result instead did work. >>>> >>>> None of this is appropriate to check-in. >>>> >>>>> I'll stop the buildworld in progress and try it. >>>> Please report if echo of the host type of context >>>> appears to make your local environment work vs. >>>> not. If it does work then it suggests that >>>> != uname -p did not get the expected text for >>>> some reason. >>>> >>>> Older material: >>>> >>>> On Fri, Oct 13, 2017 at 11:36:46AM -0700, Mark Millard wrote: >>>>> On 2017-Oct-13, at 10:59 AM, bob prohaska wrote: >>>>> >>>>>> It turns out that simply commenting out lines 447-452 in >>>>>> /usr/src/Makefile.inc1 allows buildworld to run, even with >>>>>> no /etc/make.conf in place. >>>>> For reference: >>>>> >>>>> 447 .if make(buildworld) >>>>> 448 BUILD_ARCH!= uname -p >>>>> 449 .if ${MACHINE_ARCH} != ${BUILD_ARCH} >>>>> 450 .error To cross-build, set TARGET_ARCH. >>>>> 451 .endif >>>>> 452 .endif >>>>> >>>>> (I suggest that the .error message include the >>>>> MACHINE_ARCH text and the BUILD_ARCH text, probably >>>>> with ""s around each so that empty is easy to see.) >>>>> >>>>> >>>>> I've had problems with Makefiles using != and uname >>>>> ending up with the MACRO assigned being an empty string >>>>> despite a command-line uname returning the expected >>>>> text. >>>>> >>>>> For example I've applied the below local work arounds >>>>> to my /usr/ports/Mk/bsd.port.mk copy as part of setting >>>>> up to do amd64 -> aarch64 or amd64 -> armv6 cross >>>>> builds of ports via poudriere (I've not updated to a >>>>> armv7-targeting vintage sources yet): >>>>> >>>>> >>>>> # Get the operating system type >>>>> .if !defined(OPSYS) >>>>> -OPSYS!= ${UNAME} -s >>>>> +OPSYS!= echo FreeBSD >>>>> .endif >>>>> _EXPORTED_VARS+= OPSYS >>>>> >>>>> .if !defined(_OSRELEASE) >>>>> -_OSRELEASE!= ${UNAME} -r >>>>> +_OSRELEASE!= echo 12.0-CURRENT >>>>> .endif >>>>> _EXPORTED_VARS+= _OSRELEASE >>>>> >>>>> >>>>> I was specifically ending up with _OSRELEASE >>>>> being empty as seen in poudriere prior to the >>>>> workaround and that was messing up poudriere >>>>> such that it stopped with an associated >>>>> message. >>>> >>>> === >>>> Mark Millard >>>> markmi at dsl-only.net >>>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>>