Date: Thu, 2 Aug 2018 13:02:47 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Daniel Braniss <danny@cs.huji.ac.il>, "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: booting current from nano-neo/allwinner now failes Message-ID: <CANCZdfqjgWyRWQ8uOouUpKhOjpqttQ4bDMAJUezXVcCPTwJZ0Q@mail.gmail.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, Aug 2, 2018 at 12:01 PM, 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: > > > > > > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > > > > > > > > > > > > > > > > > > > On 2 Aug 2018, at 19:26, Warner Losh <imp@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=E2=80=99s trying to boot= via > > > > the > > > > net!, and the ether is actually working, > > > > i=E2=80=99ll compile a kernel with nfs root support =E2=80=A6 > > > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqjgWyRWQ8uOouUpKhOjpqttQ4bDMAJUezXVcCPTwJZ0Q>