From owner-freebsd-arm@freebsd.org Wed Sep 27 09:59:16 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 ECCBAE2FEAE for ; Wed, 27 Sep 2017 09:59:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 A949A6BE99 for ; Wed, 27 Sep 2017 09:59:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id e134so5904104ite.3 for ; Wed, 27 Sep 2017 02:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lk30sxYBQOXHjjqKWFn4zEEXUW049HbQRovkgGWksm0=; b=K0sPP/7hYWzANt6ORpeU1DCOnjXt2KlmV1cfbcwY6Otc/2w+F1S8Zn2WMrdrRXbxn1 cJUvCk6j1UbTazWCgVdtt83ZgjORFF/O2XLqrWvwCsRio2pwSPfmdfgOXUQfC2ZStpF7 E5PuNJQSSNJ+Ksp4B5FkrzPsG7cQe9O6jaBB2CRtTviwdFvDQFA61L+0+IHDkcn3fbAR O/2gHhD8qjZuORdYgfSVBrHrXNR6pEj6VIThA13x71j0n0su5Un4Pkp83jVY4zbyNlz7 KbJLoEnhobtH1SFkz86N9ZQ03FEEocCm5woCp+hnjP0xdI/EI2Vl5N31QaFbl/0dL4zT 29gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lk30sxYBQOXHjjqKWFn4zEEXUW049HbQRovkgGWksm0=; b=c71COY+LJCwfA0k1GZtYAyaQFmA0GQO7qcp/XFezv8z0fotk7sx5HFRMLUCCVYh3gN H0rADqCDTFhLKge2F1Jhf9Vo3L6/6FbWm78b9NHwP0ExyntOzvCgGfiWIbSutW1/oIiw fXGQ+jYSn/w9MpXsfKA9KIOIlIh/ctR7YbVphIemVTngTCEwRBda7L83AxuTdyDj6Cro rhh37EqdsJoDL87uXiRpd1bDcER9zsky+i82ELzPh93oUU9iruxJ5W1ceOF2WXYJnIcX J2cgylZlQvLhYe0tcDNG57s1VSL0uTX0mJAfxk8k3ZKUIoEhiPShb8yNo/M+X0wm1yQR 20pw== X-Gm-Message-State: AHPjjUgiCL2S8+8C0joegRoEcRb5Fz6GE+hs7NXvjsc83k9ADOSlEc04 2MTZ9gBvXipraUUOUUJI14DELdUi8e/PBrFh+EeIeQ== X-Google-Smtp-Source: AOwi7QBF675SpdBzwlbKNLrVXBwkv/R3gz9lixTSvn77nKda+6S3RHoBYuB2J/I+0QSPEr8hdUdtUp5et/1TlQdL33c= X-Received: by 10.36.20.149 with SMTP id 143mr1454444itg.63.1506506355089; Wed, 27 Sep 2017 02:59:15 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.2.194 with HTTP; Wed, 27 Sep 2017 02:59:14 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f996:822c:89a6:8ee4] In-Reply-To: <20170927115429.2cb567567a0523961bae677b@bidouilliste.com> References: <201709260339.VAA16701@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506460653.73082.156.camel@freebsd.org> <1506466528.73082.172.camel@freebsd.org> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> <20170927115429.2cb567567a0523961bae677b@bidouilliste.com> From: Warner Losh Date: Wed, 27 Sep 2017 03:59:14 -0600 X-Google-Sender-Auth: uOMFd80qShNRe6ZgmQMEAwmau1w Message-ID: Subject: Re: CUBOX snapshots working? To: Emmanuel Vadot Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Wed, 27 Sep 2017 09:59:16 -0000 On Wed, Sep 27, 2017 at 3:54 AM, Emmanuel Vadot wrote: > On Wed, 27 Sep 2017 03:34:29 -0600 > Warner Losh wrote: > > > On Wed, Sep 27, 2017 at 3:32 AM, Emmanuel Vadot > > wrote: > > > > > On Wed, 27 Sep 2017 03:28:39 -0600 > > > Warner Losh wrote: > > > > > > > On Wed, Sep 27, 2017 at 3:25 AM, Emmanuel Vadot < > manu@bidouilliste.com> > > > > wrote: > > > > > > > > > On Wed, 27 Sep 2017 03:22:42 -0600 > > > > > Warner Losh wrote: > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 27, 2017 at 3:20 AM, Emmanuel Vadot < > > > manu@bidouilliste.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > > > > > > >> Warner Losh wrote: > > > > > > >> > > > > > > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore < > ian@freebsd.org> > > > > > wrote: > > > > > > >> > > > > > > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > > > > > > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore < > > > ian@freebsd.org> > > > > > > >> wrote: > > > > > > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley > wrote: > > > > > > >> > > > > > > > > > > > >> > > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot > > > > > > >> > > > > > >> > > > > > te.c > > > > > > >> > > > > > om> wrote: > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > > >> > > > > > > Ian Lepore wrote: > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel > Vadot > > > wrote: > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > >> > > > > > > > > Brett Glass wrote: > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > One would think that sauce for the goose > would > > > be > > > > > sauce > > > > > > >> > > > > > > > > > for > > > > > > >> > > > > > > > > > the > > > > > > >> > > > > > > > > > gander. But is this particular Cubox now > useless > > > > > with > > > > > > >> > > > > > > > > > FreeBSD? > > > > > > >> > > > > > > > > > And if so, why? It is not an unusual model. > The > > > > > Cubox > > > > > > >> > > > > > > > > > does > > > > > > >> > > > > > > > > > work > > > > > > >> > > > > > > > > > if I flash their "Ignition" startup software > > > (which > > > > > is > > > > > > >> > > > > > > > > > used > > > > > > >> > > > > > > > > > to > > > > > > >> > > > > > > > > > bootstrap by downloading various OS images) > to > > > the > > > > > same > > > > > > >> > > > > > > > > > Micro SD card. > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > --Brett Glass > > > > > > >> > > > > > > > > The problem isn't FreeBSD related, it's > U-Boot > > > > > related. > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > You could test build mainline u-boot just to > > > confirm > > > > > that > > > > > > >> > > > > > > > > it > > > > > > >> > > > > > > > > isn't > > > > > > >> > > > > > > > > something due to our ports. > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > If we used to provide working cubox images and > we > > > don't > > > > > > >> > > > > > > > anymore, > > > > > > >> > > > > > > > it's > > > > > > >> > > > > > > > hard to call that anything but a freebsd > problem. > > > > > > >> > > > > > > There is working cubox images, the last one is > from > > > > > > >> yesterday. > > > > > > >> > > > > > > You even say yourself that you did test it and > that > > > it > > > > > > >> worked. > > > > > > >> > > > > > > Do we even know if the snapshot worked for this > > > board ? > > > > > > >> > > > > > > Brett, could you test the 11.0 release for > example ? > > > (I > > > > > don't > > > > > > >> > > > > > > remember > > > > > > >> > > > > > > if for 11.1 we already switch u-boot or not). > > > > > > >> > > > > > I believe the change is in the u-boot port itself. > > > However, > > > > > I > > > > > > >> > > > > > don't > > > > > > >> > > > > > think it's a u-boot problem (IMHO), it's a u-boot > build > > > > > > >> > > > > > configuration > > > > > > >> > > > > > problem. There are different board variants with > > > different > > > > > > >> > > > > > hardware > > > > > > >> > > > > > layout. u-boot has code for it, but our build does > not > > > > > account > > > > > > >> > > > > > for. > > > > > > >> > > > > > Unless the scripts that build the 11.1 image use a > > > different > > > > > > >> > > > > > revision > > > > > > >> > > > > > of the u-boot port, wouldn't it just use the current > > > 2017.7 > > > > > > >> base? > > > > > > >> > > > > > > > > > > > >> > > > > > I'm trying to figure out how to generate a u-boot > with > > > the > > > > > > >> > > > > > correct > > > > > > >> > > > > > SPL > > > > > > >> > > > > > portion of u-boot. One could pull the SolidRun > u-boot > > > repo, > > > > > or > > > > > > >> go > > > > > > >> > > > > > find > > > > > > >> > > > > > the ports commit before the changeover and see if > we can > > > > > > >> generate > > > > > > >> > > > > > the > > > > > > >> > > > > > correct SPL. > > > > > > >> > > > > > > > > > > > >> > > > > > I looked at Mainline u-boot and there is a board > > > directory > > > > > for > > > > > > >> > > > > > solid > > > > > > >> > > > > > run. > > > > > > >> > > > > > https://github.com/u-boot/u-boot/blob/master/board/ > > > > > solidrun/ > > > > > > >> mx6cu > > > > > > >> > > > > > boxi > > > > > > >> > > > > > /mx6cuboxi.c > > > > > > >> > > > > > seems to support multiple memory configurations > based on > > > > > > >> defines, > > > > > > >> > > > > > so > > > > > > >> > > > > > this should just be a configuration problem. > > > > > > >> > > > > > > > > > > > >> > > > > > We clearly need to start supporting the lower spec'd > > > > > SolidRun > > > > > > >> > > > > > boards > > > > > > >> > > > > > because this has come up a couple of times now > since the > > > > > > >> > > > > > changeover. > > > > > > >> > > > > > It should be just a matter of creating a port that > does > > > the > > > > > same > > > > > > >> > > > > > thing > > > > > > >> > > > > > but generates the correct SPL file? My SOM is a > i2eX so > > > I > > > > > can't > > > > > > >> > > > > > be > > > > > > >> > > > > > too > > > > > > >> > > > > > much help (and I've also over volunteered myself!). > > > > > > >> > > > > > > > > > > > >> > > > > > Russ > > > > > > >> > > > > > > > > > > > >> > > > > The old imx6 uboot ports generated a single copy of > uboot > > > that > > > > > > >> > > > > would > > > > > > >> > > > > boot dual and quad-core versions of both hummingboard > and > > > > > cubox > > > > > > >> > > > > systems. If the new uboot works only on quad core, > that's > > > > > another > > > > > > >> > > > > regression. It might be possible to extract the > > > u-boot.imx > > > > > file > > > > > > >> > > > > from a > > > > > > >> > > > > freebsd 10 image to get back to the old one. > > > > > > >> > > > > > > > > > > >> > > > > Ooops. Except it appears those no longer exist. > > > > > > >> > > > > > > > > > >> > > > Is this a loss of functionality when the changes were > > > > > upstreamed? Is > > > > > > >> > > > it a > > > > > > >> > > > bad configuration on our part? Any idea what might be > going > > > on > > > > > or > > > > > > >> how > > > > > > >> > > > to > > > > > > >> > > > fix it? > > > > > > >> > > > > > > > > >> > > The vendor uboot worked well. The generic mainline, > > > apparently > > > > > not so > > > > > > >> > > much. It may indicate that the vendor didn't upstream > > > > > everything. I > > > > > > >> > > haven't worked much with the new imx6 uboot packages > because > > > for > > > > > me > > > > > > >> > > they're completely unusable because they lack support for > > > > > netbooting. > > > > > > >> > > (If you feel tempted to say something about efi and > > > netbooting, > > > > > > >> please > > > > > > >> > > provide links to how-to documentation at the very least, > and > > > an > > > > > > >> example > > > > > > >> > > that works for armv6 would be even better.) > > > > > > >> > > > > > > > > >> > > > > > > > >> > I didn't think that we were enabling EFI + armv6 on anything > > > yet by > > > > > > >> > default... > > > > > > >> > > > > > > > >> > Can't help you there. > > > > > > >> > > > > > > > >> > Warner > > > > > > >> > > > > > > >> We do, EFI is enabled by default in U-Boot on most of the > boards. > > > > > > > > > > > > > > > > > > > > > And GENERIC actually supports that? > > > > > > > > > > > > > > > > > > > And more importantly, we have the right tooling to build the > right > > > images > > > > > > for EFI booting? > > > > > > > > > > > > Warner > > > > > > > > > > GENERIC supports that and boot1.efi/loader.efi built for arm is > > > > > correctly built. > > > > > > > > > > > > And -stable kernels boot with this setup as well? Or is this not > default > > > > for ports-built u-boot? > > > > > > > > And the tooling goes well beyond just boot1.efi, and includes things > like > > > > making sure the release images work correctly. And EFI support is > about > > > to > > > > start requiring efirt working (well, efibootmgr is coming soon) to > manage > > > > booting, at least on x86. What's the story for arm? > > > > > > > > Warner > > > > > > You can take the release image for BBB for example, put boot1.efi > > > as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I > > > don't remember right now if you need U-Boot to load the DTB or not but > > > it's just a matter or puting the DTB in the MSDOS as well under / > > > or /DTB). > > > > > > Do they work w/o doing that? > > > > Warner > > Without doing what ? The release script don't put boot1.efi on the > msdos partition. If we do it, it will have a higher priority than > loading ubldr. We should do it at one point, but not now. Sorry, I mean 'will we boot with the old, crappy u-boot ABI interface to /boot/loader and have a kernel boot'. Sounds like the answer is 'that still works, don't worry'. Warner