Hi! First of all: Please don't top-post like this on mailing lists :)
On Sun, May 3, 2020 at 10:40 AM Philip Prindeville <philipp_s...@redfish-solutions.com> wrote: > > I’m not convinced that would be necessary, or that this proposal would create > any new circumstances. > > An example is that certain architectures are supported by MUSL and others by > uClibc, or eglibc, etc. That in turn means that some functionality is > available and others not, because not all packages compile against all > architectures and runtimes, etc. > > The schism of “fat” vs. “skinny” device in some cases might be an > architectural issue, as some processors or SoCs don’t have the physical > ability to address more than N megabytes of memory, so they are > architecturally constrained. It’s common for 32-bit processors to have under > 4GB of memory and in some cases substantially less than 4GB. > > Likewise ARM64 and x86_64 processors can almost guarantee platforms having at > least 1GB and usually more. That will be changed soon. SoC vendors like Qualcomm and Mediatek are stripping their mobile SoCs for router solution. Nowadays there are several armv7/armv8 SoCs for routers (e.g. ipq806x ipq40xx mt7622 mt7629). Home routers don't really need a ton of memory and flash space so router vendors are likely to keep using limited flash/ram even though SoC supports more. They typically come with 128M/256M ram and 16M NOR/128M NAND. An extreme example: TP-Link sells mediatek tp1900ac (a stripped-down mt7629 armv7 soc with a tp-link badge :P) routers with 4M flash and 32M ram. This kind of "fat packages" separation has to be a per-target one like current SMALL_FLASH property, and we either need some clever package feed setup or more storage space and buildbot demand. -- Regards, Chuanhong Guo _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
