booting current from nano-neo/allwinner now failes

[Warner Losh]

On Thu, Aug 2, 2018 at 1:25 PM, Emmanuel Vadot <manu at bidouilliste.com>
wrote:

> On Thu, 02 Aug 2018 12:01:30 -0600
> 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.
>
>  There is no problem with u-boot and persistent var.
>  Quoting u-boot note :
>  * NOTE: with current implementation, no variables are available after
>  * ExitBootServices, and all are persisted (if possible).
>
>  The problem that I see with loader.efi and u-boot efi is that we use
> GetNextVariableName a lot and this isn't implemented in u-boot
> currently.
>  And also something weird is happening :
>
> OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v LoaderDev
> cfee69ad-a0de-47a9-93a8-f63106f8ae99 0x6
> LoaderDev=\x2fVenHw\x28e61d73b9\x2da384\x2d4acc\
> x2daeab\x2d82e828f3628b\x29\x2fMAC\x2802816069b08d\x
> 2c0x1\x29\x00
> OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v
> LoaderDev
> OK
>

I'll take a look at this. I know even in normal UEFI land there's issues
with efi-show.

Warner