Date: Fri, 22 Apr 2016 10:27:57 -0700 From: Russell Haley <russ.haley@gmail.com> To: Milan Obuch <freebsd-arm@dino.sk> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Emmanuel Vadot <manu@bidouilliste.com>, Ian Lepore <ian@freebsd.org> Subject: Re: Orange Pi One Message-ID: <CABx9NuQu5Sj-rv7MYJCW_YZ4gsmeP8BVR%2BWv7dCoD0S1cdqhgw@mail.gmail.com> In-Reply-To: <20160422180057.0595a46d@zeta.dino.sk> References: <20160413232414.3a37907e@zeta.dino.sk> <20160414064405.202e4eef@zeta.dino.sk> <CABx9NuQWatjAhA1oL8EtUbv5kSbG8qX-KB%2BGBr9PTqVs4fnMNg@mail.gmail.com> <20160418094916.10dc9ae8@zeta.dino.sk> <20160418174918.33d3d19e4105eb737d17b122@bidouilliste.com> <CABx9NuQaFEuZmDtJ=Rie5XC3iQDqTEBX6ZRiWxNfEa_BomTUcA@mail.gmail.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> <CABx9NuRK3EXbQNTviBcZ_AgKQuuAsmvTjwMKpvO5S%2Bi8e57ppg@mail.gmail.com> <20160422075804.4d87304d@zeta.dino.sk> <20160422110523.3ef982fcea334eb84d64e8ac@bidouilliste.com> <20160422180057.0595a46d@zeta.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 22, 2016 at 9:00 AM, Milan Obuch <freebsd-arm@dino.sk> wrote: > On Fri, 22 Apr 2016 11:05:23 +0200 > Emmanuel Vadot <manu@bidouilliste.com> wrote: > > > On Fri, 22 Apr 2016 07:58:04 +0200 > > Milan Obuch <freebsd-arm@dino.sk> 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. It sure does make it easier having everything in ports. It was a literal nightmare as a beginner before Ian started putting u-boot in the ports tree (the single biggest time consumer as I was learning). There is no reason you cannot or should not submit a port as it is an open project, nor is there a requirement for a unified u-boot once it's in the ports tree because, well, it's just there. Although desirable, a single version doesn't make it easier as the dependencies of u-boot are based in hardware and aren't going to change. I think the point was Netboot is an important feature that should be preserved if possible. You could/should submit a port and then add a patch file in a later port version that fixes deficiencies as that's how the ports system is designed (no need to depreciate). Also, there is no reason that the other Allwinner systems can be brought forward to the latest u-boot once it's feature complete. Also, it's much more likely that net boot will be fixed on the pointy end of u-boot, not some random snapshot. My 2 cents Russ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuQu5Sj-rv7MYJCW_YZ4gsmeP8BVR%2BWv7dCoD0S1cdqhgw>