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

[Jonathan Morton <chromatix99@gmail.com>]

> 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