From owner-freebsd-arm@freebsd.org Thu Aug 2 18:01:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 590EA106E38B for ; Thu, 2 Aug 2018 18:01:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EAFF4740CD for ; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AFC53106E38A; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EA86106E389 for ; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FFA7740CB for ; Thu, 2 Aug 2018 18:01:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 15483535-967e-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 15483535-967e-11e8-904b-1d2e466b3c59; Thu, 02 Aug 2018 18:01:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w72I1Uf2041097; Thu, 2 Aug 2018 12:01:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1533232890.1369.49.camel@freebsd.org> Subject: Re: booting current from nano-neo/allwinner now failes From: Ian Lepore To: Warner Losh Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Date: Thu, 02 Aug 2018 12:01:30 -0600 In-Reply-To: References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 18:01:34 -0000 On Thu, 2018-08-02 at 18:55 +0100, Warner Losh wrote: > On Thu, Aug 2, 2018, 5:39 PM Ian Lepore wrote: > > > > > On Thu, 2018-08-02 at 19:31 +0300, Daniel Braniss wrote: > > > > > > > > > > > > > > > > > > On 2 Aug 2018, at 19:26, Warner Losh 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. -- Ian