CUBOX snapshots working?

[Emmanuel Vadot]

On Tue, 26 Sep 2017 16:55:28 -0600
Ian Lepore <ian at 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 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

 Just set 'filename' to loader.efi in dhcpd.conf (if you use isc-dhcpd)
and have it served by tftpd.
 In U-boot :

 $ env set boot_targets=dhcp (default is different for each board but
will look like "mmc0 dhcp usb")
 $ env save (if you want it by default)
 $ boot

 This will make u-boot do dhcp request, tftp load the DTB (so
have it in your tftpd directory), loader.efi and run it.

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>