From owner-freebsd-arm@freebsd.org Wed Sep 27 09:25:52 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 CD14FE2F656 for ; Wed, 27 Sep 2017 09:25:52 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 38ABF6AE50; Wed, 27 Sep 2017 09:25:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 82142f26; Wed, 27 Sep 2017 11:25:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=4zrhyDw0p9QeUAAaroyBOGDZ380=; b=BnkVVJ5tgw7PRc0+phX3YP07x4ST UvJc/AAPQ4/Mxk6KU3ARKxbfITa/3Y/FoucCQc5ipodcSiy61DBplfhKZCrGg5L9 YakdjafJ2Hsw0n4HDAp+0hR1QIw7Kpd2VtCUZkKvUQMQEBwpEaAkYk886ubY5oZo D3yedSZnr+LufhE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=CXZ3LZLEa9b1xZOVthtgMpJm7GiBGlO119oLNDTNzIzHz+ZL6l3cc216 hJ7toBOd7R7NX6AttNl/rcnS8qd7mXxQxwxRaeZUhfkOFMpjE40TJv66w1l3QOZN xLb8b3vfWq5NAHsNL5shMFtKdBcIumgU+VX5HrXS2hgZgd7n+zg= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 98438a18 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 27 Sep 2017 11:25:49 +0200 (CEST) Date: Wed, 27 Sep 2017 11:25:48 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Ian Lepore , freebsd-arm Subject: Re: CUBOX snapshots working? Message-Id: <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> In-Reply-To: References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@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> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:25:52 -0000 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 > > wrote: > > > >> On Tue, 26 Sep 2017 17:05:40 -0600 > >> Warner Losh wrote: > >> > >> > On Tue, Sep 26, 2017 at 4:55 PM, Ian Lepore wrote: > >> > > >> > > On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote: > >> > > > On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore > >> 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. -- Emmanuel Vadot