From owner-freebsd-arm@freebsd.org Fri Apr 22 16:01:01 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 ECFC2B18FF4 for ; Fri, 22 Apr 2016 16:01:01 +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 67C881075; Fri, 22 Apr 2016 16:01:00 +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 18:00:57 +0200 id 00F4BCA0.571A4AB9.0001610E Date: Fri, 22 Apr 2016 18:00:57 +0200 From: Milan Obuch To: freebsd-arm Cc: Emmanuel Vadot , Ian Lepore Subject: Re: Orange Pi One Message-ID: <20160422180057.0595a46d@zeta.dino.sk> In-Reply-To: <20160422110523.3ef982fcea334eb84d64e8ac@bidouilliste.com> References: <20160413232414.3a37907e@zeta.dino.sk> <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> <20160422075804.4d87304d@zeta.dino.sk> <20160422110523.3ef982fcea334eb84d64e8ac@bidouilliste.com> 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 16:01:02 -0000 On Fri, 22 Apr 2016 11:05:23 +0200 Emmanuel Vadot wrote: > On Fri, 22 Apr 2016 07:58:04 +0200 > Milan Obuch wrote: > > > 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. > > > > This is not really what I meant. > > Currently all the allwinner uboot port depend on one master > (cubieboard) and there is no reason for this to change because then > we will have multiple copies of the patches etc ... The > u-boot-cubieboard port is tied to one u-boot version (2015.04), for > some board we need to update this but, as said before, u-boot > > 2015.04 for allwinner cannot be compiled with api net support. We > cannot break existing build that use the u-boot net api > functionality. That's why I have (for now) my own ports. What I > really need to do is to definitivelly fix this uboot api net problem. > Well, I am not against it, use one base would be fine, but there is simply no support for Allwinner H3 based boards in any mainline uboot before 2016.01-rc3. It is documented on http://linux-sunxi.org/H3 page this way. We could use maybe (I think it is) vendor provided uboot from GitHub as documented on http://www.orangepi.org/Docs/Building.html page. I see no possibility to derive either (easily) from u-boot-cubieboard port, neither do I feel it has any real benefit. Also, I see no harm in publishing port and after some time deprecate it, when the same or better functionality is present in new port. But I like an idea of having ports repository as a central point where something is searched. It is known and easier to find than some random site of any random developer. That's all. Regards, Milan