This mail is not about sizes but about package selection.
Beagleboard series supports so many different interfaces but to make them work requires some extra work. For example, I've been seeing lot of mail chains to make SPI work on beagleboard. If you can select packages to make the interfaces work without putting much extra effort, it will make life easier for new comers.
I am not sure about the decision to make a single factory image which works on all beagleboard versions. That will make the image bulky and possibly, will break more easily. It is better to provide specialized images for different versions (that differ considerably) and make sure that they *will* run.
You may have a different approach on this but finally, the factory image should be able to demonstrate *all* capabilities of the board, working!
I agree with this point.
Joel,
To get people to provide useful responses, I think you have to provide
something more concrete. Some time back, I think I gave a list of
things I'd like to see. I will naturally forget some. I think what
we want to have is a set of features and associated sizes that can be
rough estimates simply so that we can produce a ranking.
The stuff that I had put in the ramdisk image that is necessary to run
test scripts for each of the interfaces is at the top of the list for
me. Let's try to build up such a list of things that must be proven
to work:
* audio playback/capture
* s-video output
* dvi-d output
* OTG host/device (some useful drivers)
* EHCI host and Ethernet
* serial port
* NAND read/write
* camera
As much that can be provided to make sure that testing those things
can be done in an automated (foolproof) way is desired.
Other on-chip features that should be illustrated:
* Ability to perform 720p video decode
* Ability to program the DSP
* Ability to us NEON operations
* Ability to perform 3D graphics
The expansion connector should also have any useful utilities for
using it, such as some GPIO examples, SPI examples, I2C examples and
serial examples.
There are a handful of projects for which there is some really
interesting BeagleBoard support/utilization:
* GStreamer (including ESC training materials)
* Qt (including ICS/ESC training materials)
* OpenCV
* libfreenect
* C6Run (ELC497/ICASSP training materials)
* MSP430 Chronos watch demo
* Spinning cube texture streaming demo
There are also some utility functions I find especially useful, beyond
i2c-tools, for everyday recovery-type tasks, such as wget, ext2/3
formatting tools, dos formatting tools, partition utilities, etc.
Also, the busybox tar always gives me problems, so a real tar is nice.
Why not look at what it takes to include some
demo/validation/recover/training software for the above and provide
back some estimated sizes?
Additional comment below...
Thank you,
Johnson
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Joel A Fernandes
Sent: Thursday, July 07, 2011 9:05 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Packages and sizes
Hi!
So, One of the things I have been working on recently is improving the
current state of the validation image (such as the one's available for
download on CircuitCo's webpage at
http://www.circuitco.com/support/index.php?title=Circuitco_Support_Wiki)
Our goal is to have an image that anyone can use to validate
functionality of a BeagleBoard, restore it to a factory condition, and
use it to demo common functionality.
Ultimately, we would like to have an image that will work on any
BeagleBoard. Inorder to accomplish this, packages have to chosen with
their sizes carefully considered. The smallest available amount of
space on a BeagleBoard with NAND is 256MB (taking the ubifs
compression into account), so our images should not occupy more space
than this.
A difficulty with calculating space and trying to identify which
packages should go in, is that there are too many little packages of
size 8kb or 12kb that it is unrealistic IMO to look at every package
and decide whether it should go in or not.
What would be a more productive exercise is if we can look at things
collectively at a higher level and get an idea of what is taking space
and how much, and which packages are responsible for dragging in all
the little ones.
One of the things I would like to do in this direction, inorder to get
a better picture, is to parse the dependency tree (possibly from the
dot-output of bitbake -g) and then sum together the package sizes as
we go up the dependency tree (root holds size of all packages in
subtree). The output of this can then be visually representated
similar to: kdirstat.sourceforge.net/screen-shots/kdirstat-main.
I would appreciate any ideas such as the one above on how else we can
do the package size calculation and what tools from your experience
would be useful. I am still planning this out so every small
suggestion will help.
Why not start by simply providing a full listing of the components on
the demo image and provide back the sizes rather than worrying too
much about visualization? Raw data is better than no data.
Regards,
Jason