| 1 |
On Mon, Jun 26, 2017 at 12:28 PM, Mart Raudsepp <leio@g.o> wrote: |
| 2 |
> Ühel kenal päeval, E, 26.06.2017 kell 10:32, kirjutas R0b0t1: |
| 3 |
>> If you want to use Gentoo on an embedded device you should be ready |
| 4 |
>> to set up crossdev and a crossroot for it. |
| 5 |
> |
| 6 |
> That's for sure, except... RPi3 is NOT an embedded device in any |
| 7 |
> traditional sense of the word and I don't really like the term extended |
| 8 |
> to such machines. Embedded is what I'd call a Cortex-M maybe, not some |
| 9 |
> general purpose Cortex-A quad core 64bit "beast" with full USB/HDMI and |
| 10 |
> OpenGL support. It runs circles around the first desktop machine I |
| 11 |
> installed Gentoo on. It is roughly equal to your low end cheap Atom |
| 12 |
> type laptops as far as CPU performance is concerned. It just has a slow |
| 13 |
> I/O and less RAM than we consider the norm these days. |
| 14 |
> |
| 15 |
|
| 16 |
The BCM2837 is a phone processor. If phones are not an embedded device |
| 17 |
then I'm not sure what is. The RAM for the device is |
| 18 |
package-on-package (i.e. high integration) and save the video outputs |
| 19 |
most of the desktop-like ports (like the Ethernet port) are obtained |
| 20 |
via hardwired connection to a USB adapter. The slow IO, limited |
| 21 |
memory, and lack of general purpose communication interfaces besides |
| 22 |
USB is what keeps it from being a good general purpose computer. |
| 23 |
|
| 24 |
(Arguably the BCM2837 is intended for devices less complex than |
| 25 |
phones, or precisely the kind of thing people call an "embedded |
| 26 |
device.") |
| 27 |
|
| 28 |
> I see no reason to crossroot for it unless that's ones desire in itself |
| 29 |
> (for example when it works, it might be worth the time save for mass |
| 30 |
> testing of stuff, e.g initial arch team work), or you really need it |
| 31 |
> for some working linker memory limitations when trying to do some |
| 32 |
> desktop stuff (browser engines, rust). For headless cases, not worth |
| 33 |
> the hassle whatsoever imho. Yes, gcc itself will take half a day or |
| 34 |
> whatnot, but hey, it's just taking you some 3-5W chugging along. |
| 35 |
> |
| 36 |
|
| 37 |
Following from the above, the devices were never meant to self-host |
| 38 |
their OS and are very bad at doing so. All large projects I know of |
| 39 |
lease time on powerful ARM servers to produce their packages because |
| 40 |
doing it on the devices most people use the packages on is extremely |
| 41 |
painful. |
| 42 |
|
| 43 |
This situation really echoes the difference seen between content |
| 44 |
producers and consumers when using desktops and phones. If you need a |
| 45 |
device to run a simple server or act as a gateway then using |
| 46 |
precompiled packages is fine, but if you're expecting to develop for |
| 47 |
the device you need a separate computer to do most of your compilation |
| 48 |
on. |
| 49 |
|
| 50 |
Once you get a toolchain, though, compiling simple programs on your |
| 51 |
device is fast enough to be reasonable. Things like GCC can take |
| 52 |
nearly three days even on the Raspberry Pi 3. |
| 53 |
|
| 54 |
> crossdev sure, if you think with the limited I/O a distcc host can help |
| 55 |
> out. |
| 56 |
> |
| 57 |
> But sure, it can be educational, so have at it if you want; when it |
| 58 |
> works, it'll get your packages done faster if you have a beefy x86_64. |
| 59 |
> |
| 60 |
> |
| 61 |
> Mart |
| 62 |
> |
| 63 |
|
| 64 |
My personal recommendation is that an interest in the ARM architecture |
| 65 |
be pursued by purchasing an ARM server (or desktop). Anything else is |
| 66 |
a waste of time and money. Some of them are starting to become |
| 67 |
affordable, e.g. https://softiron.com/products/overdrive-1000/. |
| 68 |
|
| 69 |
R0b0t1. |
Archives