From owner-freebsd-arm@freebsd.org Fri Apr 22 05:58:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 685BBB18722 for ; Fri, 22 Apr 2016 05:58:09 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECFA51866; Fri, 22 Apr 2016 05:58:08 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 22 Apr 2016 07:58:05 +0200 id 00F4BC5D.5719BD6D.0001255B Date: Fri, 22 Apr 2016 07:58:04 +0200 From: Milan Obuch To: freebsd-arm Cc: Russell Haley , Ian Lepore , Emmanuel Vadot Subject: Re: Orange Pi One Message-ID: <20160422075804.4d87304d@zeta.dino.sk> In-Reply-To: References: <20160413232414.3a37907e@zeta.dino.sk> <20160414062820.7b907ba9@X220.alogt.com> <20160414064405.202e4eef@zeta.dino.sk> <20160418094916.10dc9ae8@zeta.dino.sk> <20160418174918.33d3d19e4105eb737d17b122@bidouilliste.com> <20160418210108.4047c526@zeta.dino.sk> <20160419092012.0ad4ad2d@zeta.dino.sk> <20160419093408.2f6d8d6472b09298f1e08ecb@bidouilliste.com> <20160419095358.351c74b3@zeta.dino.sk> <1461075584.1232.13.camel@freebsd.org> <20160419170932.3fe2b709@zeta.dino.sk> <20160421220125.00286858@zeta.dino.sk> <20160421224541.daec4614d2e5c88959a3d8e2@bidouilliste.com> <1461272263.1191.23.camel@freebsd.org> <20160421231326.1bf9a11f@zeta.dino.sk> <1461276209.1191.26.camel@freebsd.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 05:58:09 -0000 On Thu, 21 Apr 2016 15:18:32 -0700 Russell Haley wrote: > On Thu, Apr 21, 2016 at 3:03 PM, Ian Lepore wrote: > > > On Thu, 2016-04-21 at 23:13 +0200, Milan Obuch wrote: > > > On Thu, 21 Apr 2016 14:57:43 -0600 > > > Ian Lepore wrote: > > > > > > > On Thu, 2016-04-21 at 22:45 +0200, Emmanuel Vadot wrote: [ snip ] > > > > > For the u-boot port, do not submit it. Uboot > 2015.04 > > > > > cannot be compiled with CONFIG_API and net support, this > > > > > means no netboot. I also have some port here : > > > > > https://github.com/evadot/u-boot-freebsd-port > > > > > I use the orangepi-pc port for my orangepi-one (orangepi-one > > > > > config > > > > > is commited in -HEAD uboot only). > > > > > > > > > > > > > Did you mean 2016.04? I'm doing netbooting on other (non > > > > -allwinner) > > > > boards with 2015.07 and 2015.10. > > > > > > > > If there is an older mainline uboot that does work right, or a > > > > vendor > > > > fork in a github repo, we can just use that in the port, > > > > there's no special reason to track the tip of the mainline > > > > uboot tree in our ports. > > > > > > > > -- Ian > > > > > > > > > > In my port I used 2016.01, AFAIK minimum with orangepi support. I > > > did not find any vendor uboot tree. Frankly I see not much use for > > > netboot for this kind of board - you must prepare micro SD with > > > SPL, uboot, ubldr, kernel and binaries, for netboot you would > > > need SPL and uboot... this still means micro SD. For any > > > practical purpose I can imagine boot from SD/MMC is just enough. > > > > > > Milan > > > > Nope, netbooting is not a feature to easily throw away. You may not > > need it, but imagine someone using a board as a distributed > > computing component. They might have a rack with literally > > thousands of units, and they're not going to want to update each > > sdcard individually; they'll have sdcards with just u-boot and > > ubldr that rarely need updating, and everything else will be nfs. > > > Just to explain better what I wrote and why: - what Emmanuel wrote sounds to me like 'if it does not have netboot ability it is worthless' and thus should be not made public (maybe not correct undestanding, somewhat exaggerated etc.) - this is something I am opposed to - even u-boot supporting only boot from SD is much much better than no u-boot at all. At least if you *really* need netboot functionality you have something working to base your work on. - I do not feel netbooting is not usefull, it can help tremendously when you can't easily swap boot media, imagine MMC soldered on board... but in this particular case, I mean developing for Orange Pi One board, it is only *convenience* thing, not hard *requirement* I hope I clarified my position with this and no flame war will arise :) Actually I have an idea where should I (or someone more motivated than I in this functionality) begin looking for solution of this problem, it is a bit deeper in uboot I would like to go to for now. Do we agree it is still worth publishing/submitting to ports tree even with some missing functionality? At least it could be documented there and that's it. > I'm merely playing with the SDIO driver and the need to move the sd > card back and forth is very tedious. I don't imagine REAL kernel > development being any fun without netboot. > I agree, just would emphasize 'tedious', and not meaning 'impossible'. > Userland application development has also been nearly unbearable > having to move SD cards back and forth as well. Small things are > okay, but when I have to compile anything or add libraries and > dependencies it's very tedious. I can't wait to get and NFS rootfs > working for my hummingboard (I suppose I could just set up NFS for my > application, but I have other motives). > Well, as soon as network driver is working in kernel, you should be able to use nfs for rootfs. For userland development it should help a bit... > > With the amazing rate at which you are progressing on your port, I > imagine that you are actually a robot so you can switch sd cards very > fast so that it's not an issue for you. Tee Hee! > > Oh, I am not progressing that quick :) and believe me, I am not a robot. I am just lazy, sometimes, to think too hard, because, you know, thinking suffers :) and not everyone is comfortable with it. I hope we will continue working on this board so it could be used for as many purposes as anyone can think of. Thanks for all the help from the team. Regards, Milan