Date: Wed, 27 Sep 2017 11:24:13 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: CUBOX snapshots working? Message-ID: <20170927112413.4fc048082df75f51a4b71eea@bidouilliste.com> In-Reply-To: <1506466528.73082.172.camel@freebsd.org> 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> <1506466528.73082.172.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Sep 2017 16:55:28 -0600 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: > >=20 > > >=20 > > > On Tue, 2017-09-26 at 14:07 -0700, Russell Haley wrote: > > > >=20 > > > > On Tue, Sep 26, 2017 at 11:46 AM, Emmanuel Vadot <manu@bidouillis > > > > te.c > > > > om> wrote: > > > > >=20 > > > > >=20 > > > > > On Tue, 26 Sep 2017 12:21:52 -0600 > > > > > Ian Lepore <ian@freebsd.org> wrote: > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > On Tue, 26 Sep 2017 11:32:21 -0600 > > > > > > > Brett Glass <brett@lariat.net> wrote: > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > --Brett Glass > > > > > > > =A0The problem isn't FreeBSD related, it's U-Boot related. > > > > > > >=20 > > > > > > > =A0You could test build mainline u-boot just to confirm that > > > > > > > it > > > > > > > isn't > > > > > > > something due to our ports. > > > > > > >=20 > > > > > > If we used to provide working cubox images and we don't > > > > > > anymore, > > > > > > it's > > > > > > hard to call that anything but a freebsd problem. > > > > > =A0There is working cubox images, the last one is from yesterday. > > > > > =A0You even say yourself that you did test it and that it worked. > > > > > =A0Do we even know if the snapshot worked for this board ? > > > > > =A0Brett, 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? > > > >=20 > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > 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!). > > > >=20 > > > > Russ > > > >=20 > > > 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.=A0=A0If the new uboot works only on quad core, that's another > > > regression.=A0=A0It might be possible to extract the u-boot.imx file > > > from a > > > freebsd 10 image to get back to the old one. > > >=20 > > > Ooops.=A0=A0Except it appears those no longer exist. > >=20 > > 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? >=20 > The vendor uboot worked well. =A0The generic mainline, apparently not so > much. =A0It may indicate that the vendor didn't upstream everything. =A0I > haven't worked much with the new imx6 uboot packages because for me > they're completely unusable because they lack support for netbooting. > =A0(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.) >=20 > -- 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=3Ddhcp (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. --=20 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?20170927112413.4fc048082df75f51a4b71eea>