CUBOX snapshots working?

[Ian Lepore]

On Tue, 2017-09-26 at 16:45 -0600, Warner Losh wrote:
> On Tue, Sep 26, 2017 at 3:17 PM, Ian Lepore <ian at 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 at bidouillis
> > > te.c
> > > om> wrote:
> > > > 
> > > > 
> > > > On Tue, 26 Sep 2017 12:21:52 -0600
> > > > Ian Lepore <ian at 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 at 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.)

-- Ian