[LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

[STR .]

> This is the 2nd RFC to port the PC Engines APU2 board to LEDE. The last
RFC can be found at
http://lists.infradead.org/pipermail/lede-dev/2016-October/003326.html
Nice!

> Default Packages:
>  - lm-sensors - Temp Monitoring
Does lm-sensors report all 4 core temps or just 1? 

> Changes added from the last RFC:
> - Removed hwclock package as it's included in busybox
Can we add '--inode support' to busybox's df? Currently there's no way to
tell inode usage.
The current busybox binary feels so gimped, I built it with every feature
enabled and it worked with no issues.

> Changes rejected from the last RFC:
> - add usb-serial-kmod - The goal of this port is to add support for all
sold hardware via PC Engines. As they do not sell 2G/3G/4G PCI-E modems,
this will not be included.
I'm disappointed at this decision. The board has 3 mini-PCI, 1 for mSATA
only. Who buys this SoC to not populate the slots?
I understand most owrt/lede targets have huge restrictions on RAM and disk
space but the APU2 isn't one of them and IMHO shouldn't be painted with the
same brush.
This cannot attract new APU2 owners to LEDE outside of those who can rebuild
the features they need.

This minimal approach suits low powered arm/mipsel SoCs but seems out of
place on a fairly beefy machine like an APU which supports virtualization.
Your suggestions will gimp the OS on the APU to worse than that of a
https://omnia.turris.cz/en and this is probably why I think they're going
with a debian derivative instead of owrt.
I haven't kept up with the Turris project since I got an apu2 instead.


> If there are any comments, suggestions, or visible improvements please let
me know/reply with some patches.
I am currently travelling and will test the lm-sensors issue as described in
http://lists.infradead.org/pipermail/lede-dev/2016-October/003374.html when
I'm back.