[OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from others... (resending)

[Philip Prindeville]

> On May 2, 2020, at 10:00 PM, Chuanhong Guo <gch981213 at gmail.com> wrote:
> 
> 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_subx at 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.
> 

128M RAM + 128M Flash sounds reasonably capable.  At least not as hamstrung as some examples we’ve seen in the past, or the TP1900AC which you site.

I see your point, however: yes, we’ll end up with a schism of some “capable” ARMv8 boxes and some “lobotomized” ARMv8 boxes like the TP1900AC which would necessitate either having a “skinny” feed for all boxes so that we don’t need a 2nd feed, or having skinny/regular variants.

Maybe the variant packaging is the way to go, since only a small percentage of the packages will need to have variants anyway.  Certainly not worth doubling the number of builds we do…

Given that the BOM cost of another 256MB of DRAM is about $3 (I’m assuming it’s DDR2?), I don’t understand why a manufacturer would ship a box that’s almost obsolete as quickly as it hits the store shelves… but that’s a different conversation.

-Philip


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel