Date: Wed, 27 Sep 2017 03:28:39 -0600 From: Warner Losh <imp@bsdimp.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: CUBOX snapshots working? Message-ID: <CANCZdfpCS7%2B4=COzw-yP6fBadZ%2BzfjvwqA5=01po672PCDJtSA@mail.gmail.com> In-Reply-To: <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com> 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> <CABx9NuRSCe54e%2B3LjOJphGP=5EAWYbBtub-%2BEvsE9JHXYdcmbw@mail.gmail.com> <1506460653.73082.156.camel@freebsd.org> <CANCZdfqAM-kXuBq2YcngR9PKajxJSTa_UNpm-v7zbMH2bvpo6g@mail.gmail.com> <1506466528.73082.172.camel@freebsd.org> <CANCZdfp55ZB5tT%2BBN2=gO88gzEa2pVH724=%2BuXY6L3v6maQUAg@mail.gmail.com> <20170927112015.e997d7b1b8e9002c8377547a@bidouilliste.com> <CANCZdfofigFMdv=BqRVy24%2Bj=C7zpJ4gRf4YBcStKn4dGxLesQ@mail.gmail.com> <CANCZdfqGPc_kK3bfvaQ7iE3oa3Dqf0nRirqacOKiHdmkbnEX=w@mail.gmail.com> <20170927112548.1b405a726da9938c26ad5cbb@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> wrote: > > > On Wed, Sep 27, 2017 at 3:21 AM, Warner Losh <imp@bsdimp.com> 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 <imp@bsdimp.com> 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 > > >> <manu@bidouillis > > >> > > > > > te.c > > >> > > > > > om> wrote: > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > >> > > > > > > Ian Lepore <ian@freebsd.org> wrote: > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > >> > > > > > > > > Brett Glass <brett@lariat.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpCS7%2B4=COzw-yP6fBadZ%2BzfjvwqA5=01po672PCDJtSA>