Date: Thu, 2 Aug 2018 21:25:30 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: booting current from nano-neo/allwinner now failes Message-ID: <20180802212530.e1339aaddf64f316e38f9fe6@bidouilliste.com> In-Reply-To: <1533232890.1369.49.camel@freebsd.org> References: <F926A7B8-F908-449C-9563-61CEB4C2CBAF@cs.huji.ac.il> <CANCZdfrYus9O0H1oXF8-66fvSjxozdHfO9ZZsc7NEmrc1EJCzQ@mail.gmail.com> <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> <CANCZdfqznVB9pBTHpa19irtd79Fu%2BsGYe3SYgb%2BQcnMSwfNXkA@mail.gmail.com> <1533232890.1369.49.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 02 Aug 2018 12:01:30 -0600 Ian Lepore <ian@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@freebsd.org> wrote: > >=20 > > >=20 > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > >=20 > > > >=20 > > > > >=20 > > > > >=20 > > > > > On 2 Aug 2018, at 19:26, Warner Losh <imp@bsdimp.com> wrote: > > > > >=20 > > > > > Try the latest ubldr > > > > > =A0There was a change in the last day that should fix this.. > > > > >=20 > > > > 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 ? > > > >=20 > > > > thanks, > > > > =A0=A0=A0=A0=A0=A0danny > > > >=20 > > > 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). > > >=20 > > > 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. > > >=20 > > Is that a UEFI issue. Or our loader.efi needs X, Y or Z? > >=20 > > Warner >=20 > 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). >=20 > 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=3D\x2fVenHw\x28e61d73b9\x2da384\x2d4acc\x2daeab\x2d82e828f3628b\x= 29\x2fMAC\x2802816069b08d\x 2c0x1\x29\x00 OK efi-show -g cfee69ad-a0de-47a9-93a8-f63106f8ae99 -v LoaderDev OK=20 > -- Ian >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=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?20180802212530.e1339aaddf64f316e38f9fe6>