Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Apr 2016 07:58:04 +0200
From:      Milan Obuch <freebsd-arm@dino.sk>
To:        freebsd-arm <freebsd-arm@freebsd.org>
Cc:        Russell Haley <russ.haley@gmail.com>, Ian Lepore <ian@freebsd.org>, Emmanuel Vadot <manu@bidouilliste.com>
Subject:   Re: Orange Pi One
Message-ID:  <20160422075804.4d87304d@zeta.dino.sk>
In-Reply-To: <CABx9NuRK3EXbQNTviBcZ_AgKQuuAsmvTjwMKpvO5S%2Bi8e57ppg@mail.gmail.com>
References:  <20160413232414.3a37907e@zeta.dino.sk> <20160414062820.7b907ba9@X220.alogt.com> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Apr 2016 15:18:32 -0700
Russell Haley <russ.haley@gmail.com> wrote:

> On Thu, Apr 21, 2016 at 3:03 PM, Ian Lepore <ian@freebsd.org> wrote:
> 
> > On Thu, 2016-04-21 at 23:13 +0200, Milan Obuch wrote:  
> > > On Thu, 21 Apr 2016 14:57:43 -0600
> > > Ian Lepore <ian@freebsd.org> 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...

> <humor>
> 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!
> </humor>
> 

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160422075804.4d87304d>