> 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. _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
