Date: Tue, 26 Sep 2017 16:55:28 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: CUBOX snapshots working? Message-ID: <1506466528.73082.172.camel@freebsd.org> In-Reply-To: <CANCZdfqAM-kXuBq2YcngR9PKajxJSTa_UNpm-v7zbMH2bvpo6g@mail.gmail.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>
index | next in thread | previous in thread | raw e-mail
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.) -- Ianhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1506466528.73082.172.camel>