On 10/12/2011 12:59 PM, Darren Hart wrote:
On 10/11/2011 04:49 PM, Tim Bird wrote:
On 10/10/2011 11:41 AM, Darren Hart wrote:
As part of working on meta-tiny, I've come across a need (want?) to
present users with the ability to select some set of features in a local
configuration file that will impact the build of the image and a set of
recipes.
Can you tell me more about meta-tiny? this is the first I've heard
about this (sorry if discussion went by on the mailing list and I
missed it), and I'm very interested.
I'm currently doing some size-related work for Sony (including
some work to support 4K stacks).
Perhaps while I have the attention of a few interested parties, it would
be a good time for a poll. I'm interested in your motivation for smaller
images.
I am not on the front line but here is my take.
Are you building SoC's with memory on die and needing to keep the memory
footprint down to save precious die real-estate?
no.
However we sometimes run the full fileystem from DDR so there is no
flash per say. (Full filesystem image gets transfered at boot time).
Board with N devices, all with DDR and ethernet and nothing else. Don't
use NFS for latency/performance consistency issues.
Are you looking at creating mass-market products and saving a few
pennies on the flash storage translates to real money, so you want to
minimize the physical size?
Yes.
We still see flash size == to RAM size or 1/2 RAM.
32 MB RAM, 16 MB Flash
64 MB RAM, 32 MB flash
We had one EVM w/ 8 MB SPI flash and we fit a fairly decent headless
system into that. Not sure if that was customer driven or bad EVM
definition. Fortunity that EVM also had a MMC/SD card reader for the >
8MB use case.
Of course once you go above a certain size (128/256 MB), people go
MMC/SD and then minimums go way up. 1 GB is probably as cheap as 512MB.
We have not seen the situation Tim talked about with RAM < NVMEM (at
least not for several years)
If you start getting into the oversize microcontroller area then you
start getting very small. However you are also probably only a kernel,
uclibc, a very cut down busybox and one or two custom apps.
Are you concerned with boot time, and have connected larger image sizes
with longer boot times?
That is a nice benefit but not the main objective.
Better use case for seep cases is a partitioned NVMEM configuration with
small faster flash (32MB-256MB parallel NAND) and slower larger storage
(1+ GB SD Card etc).
With this config do you:
* treat the NAND as a dynamic FS cache
* use it to store the "core" os (/ but not /usr or /opt)
* use it to store only readahead like data
Is there another motivating factor for your interest in small images?
Thanks,
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
