Hi,
Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are:
* Download Size: 64M * Download size with OMAP3 hwpack: 100M * Package count: 260
The list of package currently on the image can be found at:
https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that.
Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms?
Regards, Jamie. -- Linaro Release Manager
- Download Size: 64M
- Download size with OMAP3 hwpack: 100M
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots.
Yes, please :-)
Just for comparison, the current ALIP images, we would like to replace with Linaro in future, are "slightly" smaller:
http://www.arm.com/community/software-enablement/linux.php * Minimal ARMv5T cramfs (30 MB) - with debug symbols, no X11 or optional applications * Minimal ARMv6 cramfs (30 MB) - with debug symbols, no X11 or optional applications * Minimal ARMv7 Thumb-2 cramfs (30 MB) - compiled for Thumb-2 with NEON support * Full ARMv5T cramfs (49 MB) - with X11 and optional applications * Full ARMv6 cramfs (49 MB) - with X11 and optional applications * Full ARMv7 Thumb-2 cramfs (47 MB) - compiled for Thumb-2 with NEON support
The size matters ;-) for us especially in regards of models, which are shipped (downloadable) with default systems "embedded". So the smaller - the better.
Cheers!
Paweł
On Fri, Jan 21, 2011 at 2:33 PM, Pawel Moll mail@pawelmoll.com wrote:
* Download Size: 64M * Download size with OMAP3 hwpack: 100M The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots.
Yes, please :-)
Just for comparison, the current ALIP images, we would like to replace with Linaro in future, are "slightly" smaller:
http://www.arm.com/community/software-enablement/linux.php * Minimal ARMv5T cramfs (30 MB) - with debug symbols, no X11 or optional applications * Minimal ARMv6 cramfs (30 MB) - with debug symbols, no X11 or optional applications * Minimal ARMv7 Thumb-2 cramfs (30 MB) - compiled for Thumb-2 with NEON support * Full ARMv5T cramfs (49 MB) - with X11 and optional applications * Full ARMv6 cramfs (49 MB) - with X11 and optional applications * Full ARMv7 Thumb-2 cramfs (47 MB) - compiled for Thumb-2 with NEON support
the above sizes are with or without kernel? Anyone knows how compression of cramfs compares to tar.gz? e.g. can we compare those sizes directly to our gzipped tarballs?
the above sizes are with or without kernel?
Without.
Anyone knows how compression of cramfs compares to tar.gz? e.g. can we compare those sizes directly to our gzipped tarballs?
I did a quick exercise of uncramfs-ing and tar-gz-ipping the v7 versions back. Results:
49164288 filesystem_bin_alip-ael-armv7-thumb-full-reduced.cramfs 43832142 filesystem_bin_alip-ael-armv7-thumb-full-reduced.tar.gz 30633984 filesystem_bin_alip-ael-armv7-thumb-min-debug.cramfs 25872548 filesystem_bin_alip-ael-armv7-thumb-min-debug.tar.gz
Paweł
Back in November I had prototyped something like this and even called it nano. Here's the post I made to the list about it and using then current hwpack + then current headless how I was able to chop things down considerably.
http://lists.linaro.org/pipermail/linaro-dev/2010-November/001439.html
There was plenty of low hanging fruit and I was able to get the installed size of the rootfs down to 82M, after installing the hardware pack back then added in another ~40M. I do think the measure of size of the image needs to be the install size, not the download size.
For something extra small shouldn't it aim for some power of 2 that could fit into an board flash? 64M/128M installed with hwpack?
I like the idea of an image that is small, and boots extremely quickly. For those that would take linaro as a starting base for their projects, this seems like a good starting base.
And to build on that concept, add ALIP which should also be small as possible, and boot extremely quickly into a graphical environment that includes a browser.
Regards, Tom
"We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
On Fri, Jan 21, 2011 at 7:17 AM, Jamie Bennett jamie.bennett@linaro.org wrote:
Hi,
Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are:
* Download Size: 64M * Download size with OMAP3 hwpack: 100M * Package count: 260
The list of package currently on the image can be found at:
https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that.
Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms?
Regards, Jamie. -- Linaro Release Manager
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, Jan 21, 2011, Jamie Bennett wrote:
Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are:
- Download Size: 64M
- Download size with OMAP3 hwpack: 100M
- Package count: 260
The list of package currently on the image can be found at:
https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that.
Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms?
Could we do with an initrd instead of an image? I mean, busybox + small set of tools is probably enough for validation, and will be quite small.
There is inherent bloat as soon as we add a package manager in the mix
On 21 Jan 2011, at 15:42, Loïc Minier wrote:
On Fri, Jan 21, 2011, Jamie Bennett wrote:
Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are:
- Download Size: 64M
- Download size with OMAP3 hwpack: 100M
- Package count: 260
The list of package currently on the image can be found at:
https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that.
Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms?
Could we do with an initrd instead of an image? I mean, busybox + small set of tools is probably enough for validation, and will be quite small.
There is inherent bloat as soon as we add a package manager in the mix
Right, current thoughts after some IRC discussion are:
* busybox * no package manager * max size of 30mb (without kernel) * some further removal of packages
I think with this in place you will get a ~30mb compress rootfs, we could even go further if necessary.
Loïc Minier
Regards, Jamie. -- Linaro Release Manager
On Friday 21 January 2011 16:50:37 Jamie Bennett wrote:
Could we do with an initrd instead of an image? I mean, busybox + small set of tools is probably enough for validation, and will be quite small.
There is inherent bloat as soon as we add a package manager in the mix
Right, current thoughts after some IRC discussion are:
- busybox
- no package manager
- max size of 30mb (without kernel)
- some further removal of packages
I think with this in place you will get a ~30mb compress rootfs, we could even go further if necessary.
Sounds good, but that does not answer the question of whether it should be an initrd, a file system image, or both.
I think having something available as an initrd image, or at least an option for this, would be extremely valuable because it lets you netboot the kernel+image without the need for NFS or for physically installing the image on the target system.
Arnd
Yes, but isn't initrd slow to copy from the boot media (caches off, simple byte by byte copy)?
Dave
On 21 Jan 2011, at 16:27, Arnd Bergmann arnd@arndb.de wrote:
On Friday 21 January 2011 16:50:37 Jamie Bennett wrote:
Could we do with an initrd instead of an image? I mean, busybox + small set of tools is probably enough for validation, and will be quite small.
There is inherent bloat as soon as we add a package manager in the mix
Right, current thoughts after some IRC discussion are:
- busybox
- no package manager
- max size of 30mb (without kernel)
- some further removal of packages
I think with this in place you will get a ~30mb compress rootfs, we could even go further if necessary.
Sounds good, but that does not answer the question of whether it should be an initrd, a file system image, or both.
I think having something available as an initrd image, or at least an option for this, would be extremely valuable because it lets you netboot the kernel+image without the need for NFS or for physically installing the image on the target system.
Arnd
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Friday 21 January 2011 18:42:55 David Rusling wrote:
Yes, but isn't initrd slow to copy from the boot media (caches off, simple byte by byte copy)?
I hadn't considered this, but I guess this also depends a lot on the boot loader that is being used. Does uboot always run with caches disabled, or is this board specific?
If necessary, we can also find a way to create an image that could be either an initramfs or a real root image, or we could have a script that can convert whichever format we ship to the other one.
Arnd
U-Boot got faster in the last cycle (v2010.12). Cache is now enabled on arm and multiblock reads were added to the mmc driver.
On Fri, Jan 21, 2011 at 2:25 PM, Arnd Bergmann arnd@arndb.de wrote:
On Friday 21 January 2011 18:42:55 David Rusling wrote:
Yes, but isn't initrd slow to copy from the boot media (caches off, simple byte by byte copy)?
I hadn't considered this, but I guess this also depends a lot on the boot loader that is being used. Does uboot always run with caches disabled, or is this board specific?
If necessary, we can also find a way to create an image that could be either an initramfs or a real root image, or we could have a script that can convert whichever format we ship to the other one.
Arnd
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, Jan 21, 2011 at 8:50 AM, Jamie Bennett jamie.bennett@linaro.org wrote:
On 21 Jan 2011, at 15:42, Loïc Minier wrote:
On Fri, Jan 21, 2011, Jamie Bennett wrote:
Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are:
- Download Size: 64M
- Download size with OMAP3 hwpack: 100M
- Package count: 260
The list of package currently on the image can be found at:
https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that.
Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms?
Could we do with an initrd instead of an image? I mean, busybox + small set of tools is probably enough for validation, and will be quite small.
There is inherent bloat as soon as we add a package manager in the mix
Right, current thoughts after some IRC discussion are:
* busybox * no package manager * max size of 30mb (without kernel) * some further removal of packages
I think with this in place you will get a ~30mb compress rootfs, we could even go further if necessary.
I imagine it becomes pretty important to define what use-cases it is intended to cover. What set of tools are important in a verification image? An awful lot of the time all I want is an initrd with busybox. The one I'm currently using weighs in at only 2.1M, and for my purposes I don't want anything larger. (But I'm also do silly fringe things like boot a system without touching any form of storage). :-)
OTOH, I'm beginning to use autotest a lot, and python on the target is a requirement for installing test cases, which kind of blows 2.1M out of the water.
g.
On Friday 21 January 2011 20:02:47 Grant Likely wrote:
Right, current thoughts after some IRC discussion are:
- busybox
- no package manager
- max size of 30mb (without kernel)
- some further removal of packages
I think with this in place you will get a ~30mb compress rootfs, we could even go further if necessary.
I imagine it becomes pretty important to define what use-cases it is intended to cover. What set of tools are important in a verification image? An awful lot of the time all I want is an initrd with busybox. The one I'm currently using weighs in at only 2.1M, and for my purposes I don't want anything larger. (But I'm also do silly fringe things like boot a system without touching any form of storage). :-)
OTOH, I'm beginning to use autotest a lot, and python on the target is a requirement for installing test cases, which kind of blows 2.1M out of the water.
I would guess that 30 MB is about the smallest we can reasonably get from using the Ubuntu packages with glibc. Anything smaller is more a use case for a cross-built mini-distro of the OpenEmbedded/Poky or Buildroot/OpenWRT kind.
My first thought with the 'nano' target was that it should be one of these (probably Poky), while there would still be room for a stripped- down image based on the Ubuntu binaries. Maybe we can rename the 'nano' target to something like 'mini' or 'micro', leaving room in the naming for something smaller. Or we could declare that the even smaller one will be based on 'yocto' anyway, which fits the naming quite well already ;-).
For the ~30 MB nano image, I would suggest to make it still extensible using regular binaries from the Ubuntu archive, or those that are built against the Ubuntu glibc, instead of requiring a cross-compile environment. That makes it still possible to take the nano image and add any test cases that are required for a given test scenario.
Arnd
On Fri, Jan 21, 2011 at 3:42 PM, Loïc Minier loic.minier@linaro.org wrote:
On Fri, Jan 21, 2011, Jamie Bennett wrote:
Currently we are reassessing whether or not the Headless image meets the requirements for a small, fast, useable image for board verification. Just for information the current stats as of 2011-01-21 are:
* Download Size: 64M * Download size with OMAP3 hwpack: 100M * Package count: 260
The list of package currently on the image can be found at:
https://wiki.linaro.org/Platform/Foundations/Specs/HeadlessImage#Package List
The current thoughts are to cut this image down as much as possible whilst still retaining the ability to boot to a command prompt. The new image would be a 'nano' image and would be useful for verifying that the hardware boots. For a more complete console-only image for developers a full-featured developer image would be created. See my other email entitled "Call for opinion: Linaro 'Developer' Image" for that.
Is anyone *really* against this idea and is satisfied with the Headless image in its current state? Opinions? Thoughts? Criticisms?
Could we do with an initrd instead of an image? I mean, busybox + small set of tools is probably enough for validation, and will be quite small.
There is inherent bloat as soon as we add a package manager in the mix
There's also the possibility of using stuff from emdebian to slim the image down.
I don't know too much about that myself, but Wookey knows something about it.
Cheers ---Dave
-
Alexander Sack -
Arnd Bergmann -
Dave Martin -
David Rusling -
Grant Likely -
Jamie Bennett -
John Rigby -
Loïc Minier -
Pawel Moll -
Tom Gall