From owner-freebsd-arm@freebsd.org Thu Apr 1 16:29:29 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CDE9757E748 for ; Thu, 1 Apr 2021 16:29:29 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FB7td2t0yz4VSd; Thu, 1 Apr 2021 16:29:29 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 0D26C255D5; Thu, 1 Apr 2021 16:29:29 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: by mail-yb1-f170.google.com with SMTP id m132so2403489ybf.2; Thu, 01 Apr 2021 09:29:28 -0700 (PDT) X-Gm-Message-State: AOAM531Xsra9zXMetGIFKwqe3FcJnSiF2A4E3p7sk0e9+SDgR1wWy6sJ 2yaRr2mgm1il5zITsxclzqpbYJ+qYBKapiFRg2A= X-Google-Smtp-Source: ABdhPJxA2hkpEC7eQrFr2fOdy181yDdcpQdCU930KrN7t0U1/hbHXbXR0mM6zVYNrQS6rmoptE4/IZZFvONgW6SY6sA= X-Received: by 2002:a25:b21d:: with SMTP id i29mr13071719ybj.226.1617294568329; Thu, 01 Apr 2021 09:29:28 -0700 (PDT) MIME-Version: 1.0 References: <202103311655.12VGtx3T036893@office.dignus.com> <20210401151755.GO92026@FreeBSD.org> In-Reply-To: From: Mitchell Horne Date: Thu, 1 Apr 2021 13:29:17 -0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 32-bit executables on aarch64? To: Warner Losh Cc: Glen Barber , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 16:29:29 -0000 On Thu, Apr 1, 2021 at 1:03 PM Warner Losh wrote: > > > > On Thu, Apr 1, 2021 at 9:18 AM Glen Barber wrote: >> >> On Wed, Mar 31, 2021 at 08:48:50PM -0300, Mitchell Horne wrote: >> > On Wed, Mar 31, 2021 at 7:45 PM Robert Clausecker wrote: >> > > >> > > Hi Mark, >> > > >> > > The intent is to test and develop software that only runs on >> > > armv7 (specifically, Mecrisp Stellaris, a Forth system written >> > > in ARM assembly). This is best done natively. >> > > >> > > It's actually kinda annoying that no binary release tarballs >> > > are provided for armv7, so setting up the jail involves an >> > > annoying make world step. For amd64 jails, I can just unpack >> > > the binary tarballs and fix the configuration and I'm good to go. >> > > >> > >> > This issue about lack of distribution sets for armv7 has come up a >> > couple of times. It wouldn't take much to start producing them >> > officially, so I plan to submit a patch for this once re@ is done with >> > the 13.0 release. >> > >> >> The problem is (was?) the armv6/armv7 bits used a specific KERNCONF for >> each SoC, which made it somewhat impossible to guarantee that >> distribution sets would "just work". As I understand it now, this is no >> longer an issue. >> >> However, the release/Makefile has no real knowledge of how to build >> a release for armv7; the build is done using release.sh and a specific >> configuration file for each board. >> >> If the previous comment regarding KERNCONF is indeed no longer an issue, >> I will be happy to work with you on creating these distribution sets. > > > KERNCONF was never an issue for userland, outside the boot loader bits. It mattered for a while because ubldr needed to know some stuff, but Ian fixed even that a long time ago (9.x or 10.x time frame, IIRC). > > We've moved to having GENERIC on armv7, and a special wart for RPIB for armv6. The former should be available as a generic set, just like we do for x86 where we bundle things with GENERIC. The RPIB stuff we can omit if need be. > > So the goal today is to have as generic an image as others. The IMAGE needs to be flavored with a specific u-boot to be bootable, but the binaries work with any armv7 kernel. > > I'm not entirely sure that we have to do this for 13.0 at the 13.0 release, but should for 13.1 for sure and ideally maybe a few days or weeks after 13.0 is released if possible. > I have the patch for this kicking around locally, so we can move on it soon. If I had been a little faster it might have made 13.0, but it seems better to wait at this point. Mitchell > Warner