Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Sep 2017 11:54:29 +0200
From:      Emmanuel Vadot <manu@bidouilliste.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: CUBOX snapshots working?
Message-ID:  <20170927115429.2cb567567a0523961bae677b@bidouilliste.com>
In-Reply-To: <CANCZdfoJwVYckvDnKsex4Wq18RFbtGgEcb4STr3yDp3M2Zz4%2Bg@mail.gmail.com>
References:  <201709260339.VAA16701@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> <CANCZdfpCS7%2B4=COzw-yP6fBadZ%2BzfjvwqA5=01po672PCDJtSA@mail.gmail.com> <20170927113226.899fbb9617783b356bdb6279@bidouilliste.com> <CANCZdfoJwVYckvDnKsex4Wq18RFbtGgEcb4STr3yDp3M2Zz4%2Bg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Sep 2017 03:34:29 -0600
Warner Losh <imp@bsdimp.com> wrote:

> On Wed, Sep 27, 2017 at 3:32 AM, Emmanuel Vadot <manu@bidouilliste.com>
> wrote:
> 
> > On Wed, 27 Sep 2017 03:28:39 -0600
> > Warner Losh <imp@bsdimp.com> wrote:
> >
> > > 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
> >
> >  You can take the release image for BBB for example, put boot1.efi
> > as /EFI/boot/bootarm.efi in the MSDOS partition and it will work (I
> > don't remember right now if you need U-Boot to load the DTB or not but
> > it's just a matter or puting the DTB in the MSDOS as well under /
> > or /DTB).
> 
> 
> Do they work w/o doing that?
> 
> Warner

 Without doing what ? The release script don't put boot1.efi on the
msdos partition. If we do it, it will have a higher priority than
loading ubldr. We should do it at one point, but not now.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170927115429.2cb567567a0523961bae677b>