CUBOX snapshots working?

Tue Sep 26 21:40:58 UTC 2017

On Tue, Sep 26, 2017 at 3:07 PM, Russell Haley <russ.haley at gmail.com> wrote:

> On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot <manu at bidouilliste.com>
> 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/mx6cuboxi/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!).
>

Creating a new port is like 4 lines long. Generally, you can't mix and
match boards and expect u-boot for one board to work with another. This
sounds like that's the case (where we support one board, and people are
incorrectly using it for others which is causing problems).

I'm happy to integrate a new port, or even write one if you can give me the
specific configuration that's needed.

Warner

> Russ
>
> >> You seem to be implying that this is another problem caused by
> >> switching from vendor-specific to mainline uboot.  I'm not sure that's
> >> the case here, but if it is, be clear:  It is purely a freebsd problem,
> >> because it was purely our choice (not mine) to switch from something
> >> that worked to something that doesn't.
> >>
> >> -- Ian
> >
> >  Yes, maybe switching to mainline for IMX boards was a premature one, I
> > honestly don't have IMX board and don't know which way we should take.
> > All I can say is that for TI and Allwinner board, mainline U-Boot is
> > better (at least the support is the same). If you want to switch back
> > to vendor u-boot for IMX board fell free to do so (as long as you don't
> > change the other SoC U-Boot).
>
> >> > >
> >> > > At 08:21 AM 9/26/2017, Ian Lepore wrote:
> >> > >
> >> > > >
> >> > > > I just DLed and booted that snapshot on my Cubox-4i without any
> >> > > > problems.  As near as I can tell, the only difference is you've
> >> > > > got the
> >> > > > dual-core chip and mine has the quad.
> >> > > >
> >> > > > The same u-boot should work for both.  At least, that was the
> >> > > > case when
> >> > > > using the vendor-provided u-boot; the images are now built from
> >> > > > mainline u-boot.  The output you provided does show that it
> >> > > > detected
> >> > > > the right kind of chip and amount of ram, so I think it should
> >> > > > support
> >> > > > both flavors of cubox.
> >> > > >
> >> > > > -- Ian
> >> > > _______________________________________________
> >> > > freebsd-arm at freebsd.org mailing list
> >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.o
> >> > > rg"
> >> >
> >
> >
> > --
> > Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>