From owner-freebsd-arm@freebsd.org Thu Aug 2 19:33:44 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 A9A5C104D637 for ; Thu, 2 Aug 2018 19:33:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 3FED4785B3 for ; Thu, 2 Aug 2018 19:33:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 03BDB104D633; Thu, 2 Aug 2018 19:33:44 +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 BD9CD104D62F for ; Thu, 2 Aug 2018 19:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 504FC785AE for ; Thu, 2 Aug 2018 19:33:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id l14-v6so3029797iob.7 for ; Thu, 02 Aug 2018 12:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7XSIcuxhz5G3gqQ43O5y6X3zPiHx9N7wCga8GTTCUIE=; b=pLihvylumFJXPQeV0hho/8ZMaQZgM1ZYWdn3AXAczKqeHFR5OwnQdzg44qdPrNeYeh Kl0wUtwJKlXM6OhA0M7t6IbdHOMhDaHMzOr0EF/yHh5qwqZd4newIXea7AiJ4YiePYKp sZcET155sAgKh+bPHbaZlFFjN3IbIddDzNCTCHvmbPS62SB4ttN74W2BTo6DqV3UBJ5n GRgdyqDRb2zeQGVwC2c/1JtbyNRNitVlRTedn18MYB2kWIifpypjirXJpkV6dR2ChBtL bsz25Cl8yo8chdogdkGdmKgJxB1SS4vV6CxHR5LtnSVHgtO5snR8MCecz1+oiCi1HRzW Z1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7XSIcuxhz5G3gqQ43O5y6X3zPiHx9N7wCga8GTTCUIE=; b=IGYaXOrn03tPywhjp7acpKf7kFxkF7PY2bp3MhMTp7t2JylDQgf2K/T+gMaK18NqC3 TXB69Hv3qQPrfRBLCZpF/2k0mpORYuYw69OLmCtzEoH/fGAn4F87h/BFf2AKk9Ct1Z78 7XbbyIrcoI8bowu2FjYTrrUUrBZYFtivcpQZC9M9TimFgF97MzDEI8eq3Alc0mUnVB/m Fwl6aLoaYunRHe/5+DIFzJWx5ZR29oKWSQSulk8lXI251zkb9u6ZbOH2pHedxree8jqA JcJz6+pm2+AcWimsQH/ui1riF79mmpUpipxTvSu8ccDuoDHbxLRV3cvUUGUHeBHL6diV ddwg== X-Gm-Message-State: AOUpUlEgJBZ5vgwscgYarMoMJvrMVnJJB5UsFRmE9oUKPMsMbHOzdzaO cTJfiY8a1ZKBeDUr/t+GXuKISOo4hPd3kOxLpIK3nozKTS3FnA== X-Google-Smtp-Source: AA+uWPwfR7K5wvmRURhq+QHT/6SdY2WAOyFmepoG650SKj109zAzuMQq6SB3Jilk6DgSsMnpU0sev1lY1rcSfncbviE= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr3553290ioa.299.1533238422572; Thu, 02 Aug 2018 12:33:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:4485:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 12:33:41 -0700 (PDT) X-Originating-IP: [86.153.210.77] In-Reply-To: <20180802212530.e1339aaddf64f316e38f9fe6@bidouilliste.com> References: <48C92770-DFCE-45D6-B92E-FD5202585AE9@cs.huji.ac.il> <1533227944.1369.37.camel@freebsd.org> <1533232890.1369.49.camel@freebsd.org> <20180802212530.e1339aaddf64f316e38f9fe6@bidouilliste.com> From: Warner Losh Date: Thu, 2 Aug 2018 13:33:41 -0600 X-Google-Sender-Auth: j0yXykJps0USYR7afA8qhn3bM50 Message-ID: Subject: Re: booting current from nano-neo/allwinner now failes To: Emmanuel Vadot Cc: Ian Lepore , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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 19:33:45 -0000 On Thu, Aug 2, 2018 at 1:25 PM, Emmanuel Vadot wrote: > On Thu, 02 Aug 2018 12:01:30 -0600 > Ian Lepore wrote: > > > 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. > > 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