[yocto] RFC: User configurable recipe features

[William Mills]

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,
>