[Cerowrt-devel] beaglebone green wireless boards now available

[Cerowrt-devel] beaglebone green wireless boards now available

[Dave Taht]

I just got two of 'em and getting usbnet up was a snap. I got 'em
because they have
dual 2.4ghz 802.11n antennas and I figured the wifi would be faster
than the getchip stuff.

(there is no adhoc support. another reason for looking at this board
is to look at the structure of the drivers for make-wifi-fast)

I have long liked the beaglebones as being a well built product, with
some special features like the onboard PRUs nothing else can match.
The cpu is getting a bit long in the tooth tho, and these wireless
ones (no ethernet!) are so new that cases don't exist for them yet.

https://www.amazon.com/Seeedstudio-BeagleBone-Green-Wireless-Bluetooth/dp/B01GKE8F10/ref=sr_1_1?ie=UTF8&qid=1466552623&sr=8-1&keywords=beaglebone+green+wireless

they boot up (pretty fast) with debian jesse, kernel 4.4.9-ti-r25, on
the onboard 4GB emmc flash chip.

I was unaware until this moment that debian jesse appears to be
shipping babeld 1.5.1.

The preinstalled OS has sufficient compiler and onboard flash space to
build a current babeld from git, and I'm happy to report IPV6_SUBTREES
is compiled in by default.

As for whether or not I'll end up going through the same hell I'm
going through elsewhere, too soon to tell.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

[Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Juliusz Chroboczek]

> The preinstalled OS has sufficient compiler and onboard flash space to
> build a current babeld from git, and I'm happy to report IPV6_SUBTREES
> is compiled in by default.

Dave,

It's not the first time that I notice with wonder that you're compiling on
the devel boards.  Are you aware that cross-compiling babeld to armhf is
so easy it's not even funny?

  sudo apt-get install gcc-arm-linux-gnueabihf
  make CC=arm-linux-gnueabihf-gcc

Shncpd is a little bit trickier, since it depends on libbsd.  I think I'll
remove the dependency before relase, but in the meantime you may either
build yourself an armhf libbsd, or install libbsd0:armhf on your system
(which requires setting up a multiarch environment), or set up
a cross-compilation chroot, or simply copy libbsd.so from the target system.

-- Juliusz

Re: [Cerowrt-devel] [Babel-users] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Benjamin Henrion]

On Wed, Jun 22, 2016 at 1:31 PM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> The preinstalled OS has sufficient compiler and onboard flash space to
>> build a current babeld from git, and I'm happy to report IPV6_SUBTREES
>> is compiled in by default.
>
> Dave,
>
> It's not the first time that I notice with wonder that you're compiling on
> the devel boards.  Are you aware that cross-compiling babeld to armhf is
> so easy it's not even funny?
>
>   sudo apt-get install gcc-arm-linux-gnueabihf
>   make CC=arm-linux-gnueabihf-gcc

Well, I have been pushing for those xcompilers 10 years ago, depending
on the distro you use, it is still not in Debian stable:

https://packages.debian.org/search?keywords=gcc-arm-linux-gnueabihf

So if you use Ubuntu, it is there since 12.04LTS:

http://packages.ubuntu.com/search?keywords=gcc-arm-linux-gnueabihf

Otherwise, if you want to avoid the "compile on the target", you could
also run the following qemu+docker trick, even though docker should
not be a requirement, it should be doable with chroot:

docker run -it --rm -v
/usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian
bash

Best,

-- 
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

Re: [Cerowrt-devel] Cross-compiling to armhf

[Juliusz Chroboczek]

> you could also run the following qemu+docker trick,

That's like taking a machine gun to a knife fight ;-)

Just set up a chroot (I like deboostrap, but you could simply copy the
contents of the device's rootfs), and do

  sudo apt-get install qemu-user-static
  sudo cp /usr/bin/qemu-arm-static ~/chroot/usr/bin/
  sudo chroot ~/chroot

and everything should work (but check /proc/sys/fs/binfmt_misc/qemu-arm
first).

-- Juliusz

Re: [Cerowrt-devel] Cross-compiling to armhf

[Benjamin Henrion]

On Wed, Jun 22, 2016 at 3:10 PM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> you could also run the following qemu+docker trick,
>
> That's like taking a machine gun to a knife fight ;-)
>
> Just set up a chroot (I like deboostrap, but you could simply copy the
> contents of the device's rootfs), and do
>
>   sudo apt-get install qemu-user-static
>   sudo cp /usr/bin/qemu-arm-static ~/chroot/usr/bin/
>   sudo chroot ~/chroot
>
> and everything should work (but check /proc/sys/fs/binfmt_misc/qemu-arm
> first).

Do not forget:

mount --bind /dev ~/chroot/dev
mount --bind /dev/pts ~/chroot/dev/pts
mount --bind /proc ~/chroot/proc
mount --bind /sys ~/chroot/sys

But with the docker machine gun it is there.

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Dave Taht]

On Wed, Jun 22, 2016 at 4:31 AM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> The preinstalled OS has sufficient compiler and onboard flash space to
>> build a current babeld from git, and I'm happy to report IPV6_SUBTREES
>> is compiled in by default.
>
> Dave,
>
> It's not the first time that I notice with wonder that you're compiling on
> the devel boards.  Are you aware that cross-compiling babeld to armhf is
> so easy it's not even funny?
>
>   sudo apt-get install gcc-arm-linux-gnueabihf
>   make CC=arm-linux-gnueabihf-gcc


I ended up writing a long rant about this that I will blog one day...
but my short answer to both your suggestions that I cross compile or
install a docker: "You kids, get off my lawn!" :)

I have a tendency to need to compile things vastly more complex than
babel, often more bleeding edge than what is supplied in a repo, and
*knowing* that an apt-get build-dep something; then checking it out
from git head, will actually work with minimal effort, is a joy. The
latest generation of hackerboards are actually "real computers",
because they have a working, on-board compiler and full debian (and
android) support. They would be even more real if the Xwindow drivers
worked worth a damn and I could hook up a keyboard, or a variety of
more obscure languages (:cough: "go", "rust") actually worked, also.

I would love to one day soon be back on a world where I only had to
compile stuff for one architecture, and could spend more time writing
code rather than dealing with ABI differences. I am impressed with the
java port... Although I don't care for java much, it would be nice to
carry these new protocols into android somehow.

> Shncpd is a little bit trickier, since it depends on libbsd.  I think I'll
> remove the dependency before relase, but in the meantime you may either
> build yourself an armhf libbsd, or install libbsd0:armhf on your system
> (which requires setting up a multiarch environment), or set up
> a cross-compilation chroot, or simply copy libbsd.so from the target system.

Compiling natively, I don't have to think about that.

(does a working cross compiler exist for the aarch64 in the c2?)


-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cerowrt-devel] Cross-compiling to armhf

[Juliusz Chroboczek]

> mount --bind /dev ~/chroot/dev
> mount --bind /dev/pts ~/chroot/dev/pts
> mount --bind /proc ~/chroot/proc
> mount --bind /sys ~/chroot/sys

None of this is needed, fortunately.

-- Juliusz

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Juliusz Chroboczek]

> (does a working cross compiler exist for the aarch64 in the c2?)

  apt-get install gcc-aarch64-linux-gnu

Dave, I know you're a grumpy old man, but the Debian folks have done some
remarkable work on cross-compilation, on multiarch, chroots and emulation.

(I wonder why they still insist that we use the morass of complexity
called Debian-installer.  It is so much easier to run deboostrap, generate
a root filesystem, tweak the root filesystem until you're happy, and then
copy it over to the target and be done with it.)

-- Juliusz

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Dave Taht]

On Thu, Jun 23, 2016 at 3:10 PM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> (does a working cross compiler exist for the aarch64 in the c2?)
>
>   apt-get install gcc-aarch64-linux-gnu

d@osx: apt-get install gcc-aarch64-linux-gnu

Not found.

...

One of the bigger mistakes I have made in the last 3 years was
adopting an macbook air as my main laptop - primarily because the
keyboard was tolerable and backlit, it was light on my back, and
everything worked, all the time.

Running a vm for any length of time drains the battery, and the mental
semantic confusion I get from switching keyboard and mouse interfaces
between linux vm and osx, not to mention the added overhead of porting
over the tools I use (notably aquamacs), has led to an enormous
decline in my day to day development activity and a corresponding rise
in using email and other management tools. For years I'd advocated to
others that if they are going to develop on linux, for any platform,
then they should eat, sleep, and breathe linux to do so, and I've hurt
my day to day productivity by trying, only counterbalanced by that I
can try for longer (like a 10 hr airline flight)

It turns out I use absolutely no native osx apps that don't run on
linux; although things like garageband had some initial appeal,
ardour4 proved better. So the only defenses I have for that laptop are
the lightness, keyboard, and battery life. It also serves as a
constant reminder of how limited other OSes are and the uphill battle
on what needs to happen for getting universal fixes on everything.

I have two other linux laptops, both broken. On one, the ethernet is
fried, on the other, the X11 gui environment got so messed up that I
can no longer log in - so both have ended up in the testbed for use as
fq_codel development targets rather than directly in front of me. I
have a chromebook, but my attempt to get a real linux on it ended in
disaster.

> Dave, I know you're a grumpy old man, but the Debian folks have done some
> remarkable work on cross-compilation, on multiarch, chroots and emulation.

Yes they have! It is quite amazing how arm got it's act together,
including and especially all the integration work linaro did. I have a
long story on all the work I did on arm architecture long before armhf
became popular, and the mess that that was, all the way back to 1998
and handhelds.org, the disaster that was the ep9302 FPU, the long slow
EABI changeover that was obsoleted almost overnight by the armhf work
the raspian folk did, and so on.

I do plan to try and reform on this upcoming trip - bringing an air,
and reinstalling that busted laptop from scratch - but even then the
trackpad never worked worth a darn. If I don't manage to reform, I'll
also have an odroid c2 and beaglebone with me that both support native
compilation.


> (I wonder why they still insist that we use the morass of complexity
> called Debian-installer.  It is so much easier to run deboostrap, generate
> a root filesystem, tweak the root filesystem until you're happy, and then
> copy it over to the target and be done with it.)
>
> -- Juliusz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Juliusz Chroboczek]

> the long slow EABI changeover that was obsoleted almost overnight by the
> armhf work the raspian folk did, and so on.

I am pretty positive that armhf predates raspbian.  Let's please give
credit where credit is due.

-- Juliusz

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Dave Taht]

On Thu, Jun 23, 2016 at 3:57 PM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
>> the long slow EABI changeover that was obsoleted almost overnight by the
>> armhf work the raspian folk did, and so on.
>
> I am pretty positive that armhf predates raspbian.  Let's please give
> credit where credit is due.

I note that I *really like arm*, going back a very long ways.
http://the-edge.blogspot.com/2002/06/axioms-one-of-my-axioms-about.html
I remember telling the CTO of palm they were doomed back then... they
had started trying to differentiate models by *color* at that
point....

sure the abi and compiler "were out there" - but getting 20,000
packages converted over and widely into a popular distro and platform,
to me, was the tipping point for wider adoption of the hard float abi,
as something others could build on. I just spent a few minutes
googling for that story, but couldn't find it (what I remember was 3
guys, 3 months, hammering at getting 20,000 packages to all "just
work").

What we had before was a mess of different ABIs, and a whole bunch of
slightly incompatible arm cpu versions - all enough different to
fragment the arm ecosystem. there was no way you could trust one
binary on a different box. Back around this time (2006-2010?) it was
also unclear that arm would accellerate so far past the herd, either,
and there were a ton of other factors, of course that led to where
it's now being considered for supercomputers and looks set to start
unseating intel in many places.

And despite really liking arm, I look forward to entirely new arches
like the risc-v and mill eating its lunch one day. Things like
trustzone, the mali gpu, and other portions of onchip IP commonly
shipped with the chips suck rocks, still. Very few applications are
taking good advantage of the neon vfp code, the onboard caches are way
behind intel's, and so on...

speaking of trustzone - yea! there's a way to use it now.

https://github.com/OP-TEE



>
> -- Juliusz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Jonathan Morton]

> On 24 Jun, 2016, at 01:57, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> 
>> the long slow EABI changeover that was obsoleted almost overnight by the
>> armhf work the raspian folk did, and so on.
> 
> I am pretty positive that armhf predates raspbian.  Let's please give
> credit where credit is due.

Ironically, it was I who demonstrated to the Raspbian folks the benefits of an armhf build for the R-Pi 1, back in the early days of that platform.  It seems like an awfully long time ago now.  :-)

I did it by building Gentoo in armhf mode - *on* my R-Pi 1 - and distributing the ready-built rootfs.  To do this, I simply started from a softfp Gentoo build, and rebuilt it from the ground up using the Stage 1 bootstrap method.  All the tools and support simply worked from that point on.

At the time, ARMv7 distros were already typically built in armhf mode, but ARMv6 machines were usually expected to use softfp (or even softfloat) builds originally intended for ARMv5.  Since the R-Pi was obviously going to be a “platform standard” and would always include an FPU, the effort of producing a proper ARMv6-hf build was justified.

 - Jonathan Morton

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Dave Taht]

On Thu, Jun 23, 2016 at 4:20 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 24 Jun, 2016, at 01:57, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
>>
>>> the long slow EABI changeover that was obsoleted almost overnight by the
>>> armhf work the raspian folk did, and so on.
>>
>> I am pretty positive that armhf predates raspbian.  Let's please give
>> credit where credit is due.
>
> Ironically, it was I who demonstrated to the Raspbian folks the benefits of an armhf build for the R-Pi 1, back in the early days of that platform.  It seems like an awfully long time ago now.  :-)

Yes, it was a group team of hackers going against the prevailing
wisdom of endless backward compatibility, and succeeding due to
technical excellence and demonstrable performance improvements -
that's why that story sticks with me.  I admire anybody that can do
that. :)



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Dave Taht]

while I am wallowing in my formerly productive past....

That crusoe tablet I was working on in 01 and several hybrid devices
(like the predecessor to what became the nokia 770), was so close to
what I'd wanted in a handheld, just 5 years too early, and we needed
multitouch to fix the ui, and steve jobs to tackle the carriers.

I still would have preferred a world where Xwindows had got fixed
(secured), rather than everyone trying to replace it.

Still...  I'm pretty proud of what we started with the
https://en.wikipedia.org/wiki/Motorola_A760

and

https://en.wikipedia.org/wiki/Kerbango

and how maemo came about (not sure if I've published that story)...

And Jim's group had the unobtanium handheld...

http://bayosphere.com/2001/07/26/the-unobtainium-imagining-tomorrows-handhelds/

and *everyone* thought we were crazy. Ahhh... memories.

[Cerowrt-devel] Why we are discussing ARM [was: Cross-compiling to armhf]

[Juliusz Chroboczek]

We've got pretty much off-topic for both of these lists, so I guess
I should explain to folks who are not in the know why we are discussing
ARM.

Historically, much of the Babel/mesh routing/bufferbloat work has happened
on MIPS boxes.  Our elderly Asus 500GP are still rock solid, if a little
slow, and our main workhorse is still the lovely WNDR3700v2, with its two
independent Gigabit Ethernets, its two independent 802.11n 2x2 radios with
support for simultaneous AP and mesh.

MIPS remains my favourite architecture (look, Ma, no condition codes!),
but it has been slowly dying over the last years.  While Imagination
Technologies have been producing new releases of the arch and apparently
new cores, I haven't seen an exciting MIPS chip for ages.  Dave has been
bullying me into looking at ARM boards -- and while the instruction set is
not a pretty sight, the ecosystem is healthy, with chips spanning the
whole range from ridiculously cheap microcontrollers to things that are
marketed as server CPUs (the Intel folks laughing in the background spoils
the effect somewhat, though).  Add to this that the 64-bit ISA is an
almost exact clone of MIPS (except that it still has condition codes, grr,
have those people never written a compiler?).

So here, at Babel Towers, we're seriously considering switching to ARM
when we next have funding for new hardware, and dropping OpenWRT in favour
of stock Debian.  Things that we've been considering:

  CHIP board: https://getchip.com/
  Turris Omnia: https://omnia.turris.cz/en/
  Snickerdoodle board: http://krtkl.com/

Nothing we have found is as nice as the old WNDR3700/3800.  The CHIP is
marvelously cheap (cheap enough to give out to students!) and has flexible
power requirements, but it doesn't have wired Ethernet, and its wifi is
connected over SDIO, with everything that entails.  The Turris Omnia is
badly overspecced, with a price to match.  The Snickerdoodle is promising,
but it's currently vapourware, its WiFi sucks, and when combined with the
dual-Ethernet daughterboard it becomes fairly expensive.

Things that we haven't been considering, Dave's enthusiasm notwithstanding:

  Raspberry Pi: doesn't run armhf userspace, no wifi, eth connected by USB;
  Raspberry Pi v2/v3: requires binary blobs, wifi and eth connected over USB;
  Beagleboard variants: look nice, but no wifi;
  MeshSR: they did almost everything wrong.

So, folks, if anyone has good experiences with cheap ARM boards that have
wifi and Ethernet and work well with a stock Debian userspace, I'm interested.

-- Juliusz

Re: [Cerowrt-devel] Why we are discussing ARM [was: Cross-compiling to armhf]

[Jonathan Morton]

> On 24 Jun, 2016, at 03:02, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> 
>  Raspberry Pi: doesn't run armhf userspace, no wifi, eth connected by USB;
>  Raspberry Pi v2/v3: requires binary blobs, wifi and eth connected over USB;

Actually, the only substantial difference between the first R-Pi and the second is one ARM1176JZF-S core (ARMv6 with an FPU) versus four Cortex-A7s (ARMv7-A with FPU and SIMD).

They can both run armhf userspace, as we were just discussing, and they can both have external wifi attached via USB.  What the first version *can’t* do is run ARMv7 code - which isn’t very much of a difference, honestly.  There is a big performance jump though.

The third, current version gets four Cortex-A53s (which support AArch64 as well as 32-bit code) and includes a built-in wifi radio attached via SDIO.  Otherwise, it’s identical to the second version.  I haven’t got one of these yet.  I’m told that all the official R-Pi distros remain 32-bit for compatibility with the older versions, but that’s not a concern if you’re rolling your own.

They also *all* require a binary blob to bootstrap the chip.  Apparently Broadcom’s SoC architecture puts the GPU - which occupies the lion’s share of the die area - in charge of boot, with the CPU subordinate.  In fact the original R-Pi’s chip was designed as an independent embedded-class GPU, with its ARM core provided as a mere command translator!  Needless to say, the GPU hardware goes woefully underutilised, but is retained in the newer versions to preserve compatibility.

I agree however that none of the R-Pis make good routers at the performance levels we want.  They just don’t have the right kind of I/O: we need direct or PCIe attachment of Ethernet and wifi MACs, not USB and SDIO.

 - Jonathan Morton

Re: [Cerowrt-devel] Why we are discussing ARM [was: Cross-compiling to armhf]

[Juliusz Chroboczek]

> They can both run armhf userspace,

Just to make sure the audience is not confused: the Raspberry Pi 1 cannot
run Debian armhf, which requires ARMv7.  It can run either Debian armel,
which doesn't use floating point, or Raspbian, which is Debian recompiled
for ARMv6 with hardware floating point.

> I agree however that none of the R-Pis make good routers at the performance
> levels we want.  They just don’t have the right kind of I/O: we need
> direct or PCIe attachment of Ethernet and wifi MACs, not USB and SDIO.

Agreed.  Who's going to save us?

-- Juliusz

Re: [Cerowrt-devel] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Eric Johansson]

On 6/23/2016 7:42 PM, Dave Taht wrote:
> while I am wallowing in my formerly productive past....
>
> ...
> Still...  I'm pretty proud of what we started with the
> https://en.wikipedia.org/wiki/Motorola_A760
>
> and
>
> https://en.wikipedia.org/wiki/Kerbango
>

https://en.wikipedia.org/wiki/Wang_Laboratories#Wang_Freestyle

is one of my many crimes against humanity.

Re: [Cerowrt-devel] Why we are discussing ARM [was: Cross-compiling to armhf]

[Eric Johansson]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On 6/24/2016 7:04 AM, Juliusz Chroboczek wrote:
> Agreed. Who's going to save us?

  * kickstart our own,
  * license a design and enhance it to our needs (rpi 4??)
  * work a deal with mikrotek to freeup docs on one of their boards so
    we can replace router os with one of our own. see
    http://www.balticnetworks.com/mikrotik-hap-ac-lite-dual-band-indoor-access-point-built-in-antennas.html. 



[-- Attachment #2: Type: text/html, Size: 923 bytes --]

Re: [Cerowrt-devel] Why we are discussing ARM [was: Cross-compiling to armhf]

[David Lang]

On Fri, 24 Jun 2016, Eric Johansson wrote:

> On 6/24/2016 7:04 AM, Juliusz Chroboczek wrote:
>> Agreed. Who's going to save us?
>
>  * kickstart our own,
>  * license a design and enhance it to our needs (rpi 4??)
>  * work a deal with mikrotek to freeup docs on one of their boards so
>    we can replace router os with one of our own. see
>    http://www.balticnetworks.com/mikrotik-hap-ac-lite-dual-band-indoor-access-point-built-in-antennas.html.

There are a number of mikrotik boards that are listed as having OpenWRT support, 
including one with 9 gig-e ports and 3 microPCI slots that can hold radios

http://routerboard.com/RB493G
http://routerboard.com/RB493AH

Re: [Cerowrt-devel] [Babel-users] Why we are discussing ARM [was: Cross-compiling to armhf]

[Juliusz Chroboczek]

> I'd suggest to look into the Familiy of Olinuxino boards produced by
> Olimex: https://www.olimex.com/Products/OLinuXino/open-source-hardware
> or one of their system-on-module boards.

Ah, right.  I recall looking into them, but found their website confusing
(too many models, difficult to find technical information without reading
the schematics).  Which models exactly are you suggesting we look into?

Do you know how the Ethernet is hooked to the SoC?  I could be wrong, but
I don't think Allwinner SoCs include GMII.

Do they use upstream kernels, or their hacked up tree?

-- Juliusz

Re: [Cerowrt-devel] [Babel-users] Why we are discussing ARM [was: Cross-compiling to armhf]

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Hi Juliusz,

On Sun, Jun 26, 2016 at 07:59:10PM +0200, Juliusz Chroboczek wrote:
> > I'd suggest to look into the Familiy of Olinuxino boards produced by
> > Olimex: https://www.olimex.com/Products/OLinuXino/open-source-hardware
> > or one of their system-on-module boards.
> 
> Ah, right.  I recall looking into them, but found their website confusing
> (too many models, difficult to find technical information without reading
> the schematics).  Which models exactly are you suggesting we look into?

The "Internet cube" project [1,2] uses the LIME and LIME2 boards:

  https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME/open-source-hardware
  https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2/open-source-hardware

I think the only difference is the amount of RAM (512 MB vs. 1 GB) and the
NIC (100M vs. 1G).

The problem is that there is no onboard wifi, so you would have to use USB.

> Do you know how the Ethernet is hooked to the SoC?  I could be wrong, but
> I don't think Allwinner SoCs include GMII.

I suggest you look at the schematics (here for LIME2):

  https://github.com/OLIMEX/OLINUXINO/raw/master/HARDWARE/A20-OLinuXino-LIME2/A20-OLinuXino-Lime2_Rev_G.pdf

Looking quickly, this looks like a SPI interface.  I'm really not a
hardware expert though, so you'd better check yourself.

> Do they use upstream kernels, or their hacked up tree?

I'm told that the kernel in Jessie supports the LIME/LIME2 since a few months.
Before that, the Internet cube people where using the kernel from
jessie-backports.  See also:

  https://wiki.debian.org/InstallingDebianOn/Allwinner#Supported_Platforms

Baptiste

[1] https://labriqueinter.net/
[2] https://internetcu.be/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Cerowrt-devel] [Babel-users] Why we are discussing ARM [was: Cross-compiling to armhf]

[Jonathan Morton]

> On 26 Jun, 2016, at 22:02, Baptiste Jonglez <baptiste@bitsofnetworks.org> wrote:
> 
>> Do you know how the Ethernet is hooked to the SoC?  I could be wrong, but
>> I don't think Allwinner SoCs include GMII.
> 
> I suggest you look at the schematics (here for LIME2):
> 
>  https://github.com/OLIMEX/OLINUXINO/raw/master/HARDWARE/A20-OLinuXino-LIME2/A20-OLinuXino-Lime2_Rev_G.pdf
> 
> Looking quickly, this looks like a SPI interface.  I'm really not a
> hardware expert though, so you'd better check yourself.

It looks like GMII to me.  That’s a good thing.

SPI would be extremely unlikely - it just doesn’t have that sort of bandwidth, and I’ve never heard of it being used to attach Ethernet before.  It appears that some of the pins used for GMII on the AllWinner are shared with one of the SPI interfaces (and a serial UART) - they can be used for one purpose or the other, but not both.  This is quite common practice in the embedded world.

 - Jonathan Morton

Re: [Cerowrt-devel] [Babel-users] Why we are discussing ARM [was: Cross-compiling to armhf]

[Juliusz Chroboczek]

> I suggest you look at the schematics (here for LIME2):

>   https://github.com/OLIMEX/OLINUXINO/raw/master/HARDWARE/A20-OLinuXino-LIME2/A20-OLinuXino-Lime2_Rev_G.pdf

> Looking quickly, this looks like a SPI interface.

To me it looks like it's RGMII -- the pins are multiplexed, they have
multiple functions selectable in software.

Thanks to both of you for the info,

-- Juliusz