booting current from nano-neo/allwinner now failes

[Warner Losh]

On Thu, Aug 2, 2018 at 12:01 PM, Ian Lepore <ian at freebsd.org> wrote:

> On Thu, 2018-08-02 at 18:55 +0100, Warner Losh wrote:
> > On Thu, Aug 2, 2018, 5:39 PM Ian Lepore <ian at freebsd.org> wrote:
> >
> > >
> > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > > On 2 Aug 2018, at 19:26, Warner Losh <imp at bsdimp.com> wrote:
> > > > >
> > > > > Try the latest ubldr
> > > > >  There was a change in the last day that should fix this..
> > > > >
> > > > I thought I had the latest, will try again.
> > > > BTW, I only updated the u-boot, and now it’s trying to boot via
> > > > the
> > > > net!, and the ether is actually working,
> > > > i’ll compile a kernel with nfs root support …
> > > >
> > > > thanks,
> > > >       danny
> > > >
> > > Well, no, it's failing to boot via net, and if it's modern uboot,
> > > it
> > > will always fail. There is a "net device" in ubldr, but when it
> > > tries
> > > to probe, uboot fails to respond, because CONFIG_API no longer
> > > supports
> > > network devices in modern uboot that uses DM (Device Manager).
> > >
> > > The only way to netboot with modern uboot is via UEFI.
> > > Unfortunately,
> > > you don't get the kind of local control that ubldr provided; the
> > > boot
> > > parameters (where to find the root filesystem, etc) must come from
> > > the
> > > dhcp/bootp server. That's a bit of a showstopper for many folks who
> > > don't have that level of control over the dhcp server config.
> > >
> > Is that a UEFI issue. Or our loader.efi needs X, Y or Z?
> >
> > Warner
>
> With ubldr you set a uboot env var (rootpath) and it gets used instead
> of anything coming over the wire from the server (it's important that a
> locally-set value overrides dhcp/bootp values, because the server you
> can't control may deliver insane values).
>
> From what I've heard, the uboot uefi implementation doesn't give you a
> way to save persistent efi vars, so right now there's no way to set a
> local rootpath var. If we had persistent vars, I guess the thing to do
> would be to define a standard freebsd-specific variable to set the
> rootpath.
>

We currently parse command line options (which gives local users a way). If
u-boot doesn't provide a good a way to do that, we can add reading local
files to loader.efi . All the work I've done to make it more friendly to
UEFI Boot Manager should also make it friendlier to these things. So long
as we don't break UEFI boot manager stuff, I'm cool adding more local
control. I also now have a bunch of boards that I'd like to have net-boot
into the 'next thing' image so we can do CI-like testing at my "Todd Creek
FreeBSD Test Labs" so we can do CI-like testing on the dozen or so boards I
have. If I could do it via netboot, that would be best and allow me to
ping-pong SD cards between netboot and test images from the project
snapshots near releases. While I have 100% control over the DHCP env, it's
dnsmasq which is a bit of a pain to setup relative to other systems I've
used...

Warner