Hello,

I would like to know what is the current status of the tiny linux
project? (The current goals, status and activeness).
I've found this:

http://elinux.org/Linux_Tiny

but it seems a bit outdated.

I'm adding Thomas to CC, cause he maintains (or used to according to elinux)
a list of relevant patches. What's the status of this?

Also, I would like to know what's the smallest kernel (static and
dynamic memory footprint) that can be achieved
right now (without losing signicant funcionality).

Is it possible to run linux a 1 MB SRAM board (no DRAM) ? (I am
thinking at a ARM7 LPC2294 header board).
I now this might sound crazy, but perhaps with In-Place stuff
and some hacks it could be possible.

I've seen tests with 2 MB but not with 1 MB. Also, I've seen
presentations by Matt Mackall [1] and Thomas Petazzoni [2].
but they're a few years old (ages in kernel time, right? :)

Also, wich is the relevant mailing list? Not sure.

Thanks a lot,
Ezequiel.

[1] http://ols.fedoraproject.org/OLS/Reprints-2004/Reprint-Mackall-OLS2004.pdf
[2] http://www.celinux.org/elc08_presentations/linux-tiny.pdf

On 04/10/2012 08:58 AM, � wrote:

Hello,

I would like to know what is the current status of the tiny linux
project? (The current goals, status and activeness).
I've found this:

http://elinux.org/Linux_Tiny

but it seems a bit outdated.

I'm adding Thomas to CC, cause he maintains (or used to according to elinux)
a list of relevant patches. What's the status of this?

Also, I would like to know what's the smallest kernel (static and
dynamic memory footprint) that can be achieved
right now (without losing signicant funcionality).

Is it possible to run linux a 1 MB SRAM board (no DRAM) ? (I am
thinking at a ARM7 LPC2294 header board).
I now this might sound crazy, but perhaps with In-Place stuff
and some hacks it could be possible.

I've seen tests with 2 MB but not with 1 MB. Also, I've seen
presentations by Matt Mackall [1] and Thomas Petazzoni [2].
but they're a few years old (ages in kernel time, right? :)

Also, wich is the relevant mailing list? Not sure.

The last work on Linux-tiny was by Wu Zhangjin, of tinylab.
The last word I got from Wu was that he had taken a full-time
job, and would not have time to work on Linux-tiny
very much. This was in February.

Wu's last checkin to the linux-tiny gitorious repository
was in October, 2011 (on kernel version 2.6.35).

So, my guess is that the project is dead.

With regard to your other question, I don't know of anyone
running Linux on only 1MB. I have run Linux in about 1.5MB of RAM
but only by "cheating" by putting the kernel into flash and using
Execute-in-place.

I've been thinking of restarting some projects with kernel
size. I've recently been working on supporting 4k stacks with
the Linux kernel (which works for me on ARM).

I think this list or the linux-embedded list on vger
are probably as good as any for discussing such work.

-- Tim

================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On Tue, Apr 17, 2012 at 05:20:22PM -0700, Tim Bird wrote:

With regard to your other question, I don't know of anyone running
Linux on only 1 MB. I have run Linux in about 1.5 MB of RAM but only
by "cheating" by putting the kernel into flash and using
Execute-in-place.

We have been running with about 1 MB when working on the Cortex-M3 and
EFM32 port recently, but it turned out that, even with xip, real work
(more than a booting kernek) was only possible with 4 MB.

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

I'd like to see Linux fit in stuff that this too :
http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/

On 04/18/2012 10:25 AM, Gross, Mark wrote:

I'd like to see Linux fit in stuff that this too :
http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal. For context: linux 0.0.1 was developed on a 4 megabyte
system in 1991. Swap support was added in december of that year so it
could run on a 2 megabyte system.

That's the historical low water mark of linux memory usage, back when
the kernel really didn't do that much. The 0.x kernels were _profoundly_
more stripped down than what we have today, they didn't even implement
full "a normal user is not root" permissions, had no hotplug/kobjects or
reverse mapping support, thread local storage or futexes, nothing like
ipchains/tables... Even the /proc filesystem didn't show up until
0.97.3, and the linux-0.97.3.tar.gz source is only 316k. THAT required
a swap partition to do anything useful in 2 megs.

The smallest amount of memory I ever saw a 32-bit system run in was
IBM's OS/2 run in a little under 2 megs, and that was with the OS in ROM
running a text-mode dedicated app (some weather station reporting thing).

Sure, DOS and early versions of Windows ran in less, but that was 16-bit
code, using not just smaller instructions but smaller constants.
sizeof(int) was 2 bytes, _and_ both leveraged BIOS code in ROM to
provide driver support. Heck, half the time windows 3.1 ran in "real
mode" instead of "protected mode", and until win32c/win32s it used
segment:offset addresses with thunking to de-overlap the segments.
Windows 98 still had its scheduler compiled as 16 bit code, which is
what gutted Pentium Pro sales and led to the initial split between IBM
and Microsoft.

The ELKS port of Linux is a 16-bit version of Linux. If you really want
to play with 2 megabytes of memory or less you could try that, but note
that it's essentially a completely different OS (and basically a toy):

http://elks.sf.net

If you want to run something in 256k ram, glue it onto u-boot.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.

Hi,

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal. For context: linux 0.0.1 was developed on a 4 megabyte
system in 1991. Swap support was added in december of that year so it
could run on a 2 megabyte system.

After some research I came to the same conclusion. I guess I was on
drugs when I tought that,
since even a kernel compiled with almost nothing (not even BUG
support) weights ~1.5 MB.

It seems Linux is not aiming that low after all, however a little
effort to try to un-bloat the current
state of things can't hurt, right?

Thanks,
Ezequiel.

2012/4/24 Ezequiel García <elezegarcia@...>:

Hi,

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal. For context: linux 0.0.1 was developed on a 4 megabyte
system in 1991. Swap support was added in december of that year so it
could run on a 2 megabyte system.

After some research I came to the same conclusion. I guess I was on
drugs when I tought that,
since even a kernel compiled with almost nothing (not even BUG
support) weights ~1.5 MB.

It seems Linux is not aiming that low after all, however a little
effort to try to un-bloat the current
state of things can't hurt, right?

Do you know the state of uCLinux, when those options are enabled it
should be better, no? Or 1.5Mb is with such options?


--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Thanks for the historical context! (I didn't get into linux until the 2.2 days).

so what is the likely minimal HW we think linux "should" be able to boot on and say run a simple shell? What is Linux tiny's target now that 2MB is out of the question?

--mark

Hi,

2012/4/24 Gustavo Sverzut Barbieri <barbieri@...>:

It seems Linux is not aiming that low after all, however a little
effort to try to un-bloat the current
state of things can't hurt, right?

Do you know the state of uCLinux, when those options are enabled it
should be better, no? Or 1.5Mb is with such options?

To avoid confusion: uclinux is basically a linux distribution; it is
made of a linux kernel and a filesystem.
The kernel included in latest uclinux distribution file is 3.x series,
and it is pretty much equally to a vanilla
kernel (as compiled from git).

So, when compiling for m68k (coldfire) with just the bare minimum
options enabled: block layer, console drivers,
romfs, I got a 1.5 MB kernel. I was shocked by the bigness of the
number, but it doesn't seem to be easily
reduced.

And we are not even talking about dynamic footprint, or filesystem requirements!

2012/4/24 Ezequiel García <elezegarcia@...>:

Hi,

2012/4/24 Gustavo Sverzut Barbieri <barbieri@...>:

It seems Linux is not aiming that low after all, however a little
effort to try to un-bloat the current
state of things can't hurt, right?

Do you know the state of uCLinux, when those options are enabled it
should be better, no? Or 1.5Mb is with such options?

To avoid confusion: uclinux is basically a linux distribution; it is
made of a linux kernel and a filesystem.
The kernel included in latest uclinux distribution file is 3.x series,
and it is pretty much equally to a vanilla
kernel (as compiled from git).

Yes, to my understanding ucLinux was merged into vanilla Linux during
2.6 development, but it was the options hidden under a global flag.
These flags would enable remove MMU and other parts. Confirm?

So, when compiling for m68k (coldfire) with just the bare minimum
options enabled: block layer, console drivers,
romfs, I got a 1.5 MB kernel. I was shocked by the bigness of the
number, but it doesn't seem to be easily
reduced.

And we are not even talking about dynamic footprint, or filesystem requirements!

Ouch, too much indeed :-(


--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Yes, to my understanding ucLinux was merged into vanilla Linux during
2.6 development, but it was the options hidden under a global flag.
These flags would enable remove MMU and other parts. Confirm?

I tried that on a 5282 mmu-less board, so... confirmed to the best of
my knowledge :)

Regards,
Ezequiel.

On 04/24/2012 02:35 PM, Ezequiel García wrote:

Hi,

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal. For context: linux 0.0.1 was developed on a 4 megabyte
system in 1991. Swap support was added in december of that year so it
could run on a 2 megabyte system.

After some research I came to the same conclusion. I guess I was on
drugs when I tought that,
since even a kernel compiled with almost nothing (not even BUG
support) weights ~1.5 MB.

I do note that this is inexcusable. The kernel _DID_ once run in 2
megabytes of ram, and 4 should still be a realistic goal for a tiny
linux project of the busybox/toybox plus uClibc userspace kind.
(Admittedly the last 4 meg linux system I saw was a uClinux circa 2006
at CELF, I think it might have been Grant Likely demoing it?

It seems Linux is not aiming that low after all, however a little
effort to try to un-bloat the current
state of things can't hurt, right?

There's plenty of low hanging fruit, yes. But I think linux-tiny is
actually going about it all wrong. My rant on the subject is here:

http://www.mentby.com/rob-landley/what-happened-to-linux-tiny.html

If I had spare time (not at present) I could look at u-boot and this:

http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/

And I'd assemble a catalog of hello world kernels with the standard code
to switch into protected mode (set up page tables, turn on the cache,
etc) and then print "hello world" via early_printk(). And then porting
chunks of linux to this in a granular way, with appropriate cleanups,
would be something other people could help with. :)

I'd probably browbeat the device tree guys into helping me because this
should be entirely device tree based from day 1. Pretty much the FIRST
thing you add after "hello world" is a device tree parser, because that
tells you how much memory you've got and where it is. :)

Thanks,
Ezequiel.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.

On 04/24/2012 02:47 PM, Gross, Mark wrote:

Thanks for the historical context! (I didn't get into linux until the
2.2 days).

Computer history is a hobby of mine. You might like this:

http://landley.net/history/mirror/linux/linux-history.html

I went through the archives and picked out posts I found interesting
from the first year or so here:

http://landley.net/history/mirror/linux/1991.html
http://landley.net/history/mirror/linux/1992.html

And here's an interview with Linus from the end of 1992:

http://www.abc.se/~m9339/linux/linuxdoc/linuxnews03a.html

so what is the likely minimal HW we think linux "should" be able to
boot on and say run a simple shell? What is Linux tiny's target now
that 2MB is out of the question?

2 megs isn't out of the question, but working in 2 megs would require
running the kernel out of rom, with a filesystem in rom, using binflt
binary format. Which would be crazy slow, but has been done.

Running Linux is a more conventional configuration: kernel with
initramfs plus busybox statically linked against uClibc: 4 megs is a
reasonable target. I dunno if it _does_ that today, but it should be
achievable.

8 megs is a pretty comfortable system, shouldn't require too much
customization.

16 megs is luxury, you should be able to run a graphical display in
that. (Your real limit's going to be your framebuffer; 1024x768x256
colors is most of a megabyte. Now add in double-buffering and the sheer
amount of data you sling around gets big fast.)

But the interesting thing is: these are all solved problems. Twenty
years ago 4 megs was a reasonably powerful machine (Linus spent a couple
thousand dollars buying his computer), and 16 megs was a high-end
workstation. Since then we've gone to much higher resolution with more
colors and 3D acceleration, and our low-end networking is 2 orders of
magnitude faster so the buffering required is enormous, and so on. The
features were added for a REASON. But we DO know how to make systems fit
in smaller memory footprints because we've _done_ it, we just have to
comb through the archives and understand how this used to work.

Yes, the computer science discipline is maturing to the point where
software archaeology actually serves a purpose. :)

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.

On 04/24/2012 12:22 PM, Rob Landley wrote:

On 04/18/2012 10:25 AM, Gross, Mark wrote:

I'd like to see Linux fit in stuff that this too :
http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal.

Call me a glutton for punishment. I have a background project to see if
Linux running in 1M is possible. The budget for some items:
256K kernel
256K library
64k shell
128k multi-call utility

In general, this would require (as Rob points out), reverting a lot
of features that have crept into Linux, and substituting smaller
code for some pieces.

I've run Linux in as small as 2.5 meg (but with kernel and app XIP).
In the early days, I had a web server running in 4 meg (but with swap).

However, this is probably something I'll never find time to do...
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On 04/24/2012 02:33 PM, Rob Landley wrote:

There's plenty of low hanging fruit, yes. But I think linux-tiny is
actually going about it all wrong. My rant on the subject is here:

http://www.mentby.com/rob-landley/what-happened-to-linux-tiny.html

I've read through this and agree completely. You can only get back
to these sizes with an additive approach rather than a subtractive
approach. As the kernel continues growing, the subtractive approach
becomes less and less tractable.

And I'd assemble a catalog of hello world kernels with the standard code
to switch into protected mode (set up page tables, turn on the cache,
etc) and then print "hello world" via early_printk(). And then porting
chunks of linux to this in a granular way, with appropriate cleanups,
would be something other people could help with. :)

That would be, IMHO, the right way to proceed.

I'm interested in coming up with different mechanisms for
allowing the specification of feature and code dependencies at compile-time,
so that the abundance of corner-case code that we carry around today,
that never gets executed, disappears completely. The current CONFIG and
pre-processor stuff is fragile, and because it's so ugly, it doesn't
allow the fine granularity needed to do a completely additive system
properly.

I'd probably browbeat the device tree guys into helping me because this
should be entirely device tree based from day 1. Pretty much the FIRST
thing you add after "hello world" is a device tree parser, because that
tells you how much memory you've got and where it is. :)

With device tree, you've probably blown your memory budget right
there. :-) Using device tree just invites code that is not used
on your target.
-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On Tue, Apr 24, 2012 at 7:02 PM, Tim Bird <tim.bird@...> wrote:

On 04/24/2012 12:22 PM, Rob Landley wrote:

On 04/18/2012 10:25 AM, Gross, Mark wrote:

I'd like to see Linux fit in stuff that this too :
http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal.

Call me a glutton for punishment.  I have a background project to see if
Linux running in 1M is possible.  The budget for some items:
256K kernel
256K library
64k shell
128k multi-call utility

In general, this would require (as Rob points out), reverting a lot
of features that have crept into Linux, and substituting smaller
code for some pieces.

I've run Linux in as small as 2.5 meg (but with kernel and app XIP).
In the early days, I had a web server running in 4 meg (but with swap).

However, this is probably something I'll never find time to do...

As said in this mail thread, it all boils down to "is it worth?" question.

Recently the embedded space got beefy. Phones and tablets are like
desktop computers. Even network routers, tvs and cameras got bumps.

Yet, some industrial systems still remain using low end hardware. And
recently things like ARM Cortex-M4 worked on the bottom line of 32bits
systems. Anyone knows of efforts to run Linux on such low end systems?

--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

On 04/24/2012 03:13 PM, Gustavo Sverzut Barbieri wrote:

On Tue, Apr 24, 2012 at 7:02 PM, Tim Bird <tim.bird@...> wrote:

On 04/24/2012 12:22 PM, Rob Landley wrote:

On 04/18/2012 10:25 AM, Gross, Mark wrote:

I'd like to see Linux fit in stuff that this too :
http://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-retrobsd-for-duinomite/

Linux in under 2 megabytes of RAM, even when running from ROM, is not a
realistic goal.

Call me a glutton for punishment. I have a background project to see if
Linux running in 1M is possible. The budget for some items:
256K kernel
256K library
64k shell
128k multi-call utility

In general, this would require (as Rob points out), reverting a lot
of features that have crept into Linux, and substituting smaller
code for some pieces.

I've run Linux in as small as 2.5 meg (but with kernel and app XIP).
In the early days, I had a web server running in 4 meg (but with swap).

However, this is probably something I'll never find time to do...

As said in this mail thread, it all boils down to "is it worth?" question.

Recently the embedded space got beefy. Phones and tablets are like
desktop computers. Even network routers, tvs and cameras got bumps.

If you think of things like "smart dust" running Linux, then
it might be worth it. I don't know about you, but I don't want
to require more than 1M of ram on my dust computers. ;-)

The other reason it might be worth it is purely for speed. A really
small system can fit in cache better (indeed the entire system might fit
in cache on a modern processor). This should help with performance,
at the expense of fancy algorithms for things like scheduling,
memory management and networking.

Yet, some industrial systems still remain using low end hardware. And
recently things like ARM Cortex-M4 worked on the bottom line of 32bits
systems. Anyone knows of efforts to run Linux on such low end systems?

ARM has worked on running Linux on the Cortex-M3:
http://www.linux-arm.org/LinuxKernel/LinuxM3
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

(resent after error in sending address)
On 04/18/2012 06:18 AM, Robert Schwebel wrote:

On Tue, Apr 17, 2012 at 05:20:22PM -0700, Tim Bird wrote:

With regard to your other question, I don't know of anyone running
Linux on only 1 MB. I have run Linux in about 1.5 MB of RAM but only
by "cheating" by putting the kernel into flash and using
Execute-in-place.

We have been running with about 1 MB when working on the Cortex-M3 and
EFM32 port recently, but it turned out that, even with xip, real work
(more than a booting kernek) was only possible with 4 MB.

This is likely to get suddenly more relevant in the next year or ten, when microcontrollers able to run linux arrive.
That is - a system in one chip, not requiring RAM or ROM soldered on.
They don't - yet - exist.

http://search.digikey.com/us/en/products/LPC4330FBD144,551/568-9450-ND/2840463 - for example - has 264K of RAM.
It's not going to be that long till linux becomes available in one-chip form.

And then comes this state being stable for some years, as the price drops from ~$15 to $1.

At the moment, you can get a 32 bit few tens of MHz processor for $1.
This is faster by some margin than the 386/20 I started linux on.
But at the moment, it has 4K of RAM.

To those that haven't made a PCB - having it all in one device eases a _lot_ of the interconnections headaches - meaning the cost to make a one-off device drops from a few hundred dollars for several prototypes
to $10ish.

On 04/24/2012 03:06 PM, Ezequiel García wrote:

Hi,

2012/4/24 Gustavo Sverzut Barbieri <barbieri@...>:

It seems Linux is not aiming that low after all, however a little
effort to try to un-bloat the current
state of things can't hurt, right?

Do you know the state of uCLinux, when those options are enabled it
should be better, no? Or 1.5Mb is with such options?

To avoid confusion: uclinux is basically a linux distribution; it is
made of a linux kernel and a filesystem.
The kernel included in latest uclinux distribution file is 3.x series,
and it is pretty much equally to a vanilla
kernel (as compiled from git).

So, when compiling for m68k (coldfire) with just the bare minimum
options enabled: block layer, console drivers,
romfs, I got a 1.5 MB kernel. I was shocked by the bigness of the
number, but it doesn't seem to be easily
reduced.

Different processors have different machine code, some of which is more
space-efficient than others.

My Aboriginal Linux project cross compiles the same ~7 packages to a
dozen different targets (with the goal of getting a native development
environment you can run under qemu). I post binaries at
http://landley.net/aboriginal/bin and here are the sizes of a few files
from the root-filesystem tarballs under different architectures:

456432 root-filesystem-armv5l/bin/busybox
209600 root-filesystem-armv5l/bin/make
335484 root-filesystem-armv5l/lib/libuClibc-0.9.32.1.so
539015 root-filesystem-armv5l/usr/tools/bin/gcc

354308 root-filesystem-i586/bin/busybox
179216 root-filesystem-i586/bin/make
273640 root-filesystem-i586/lib/libuClibc-0.9.32.1.so
475934 root-filesystem-i586/usr/tools/bin/gcc

358996 root-filesystem-i686/bin/busybox
187952 root-filesystem-i686/bin/make
281832 root-filesystem-i686/lib/libuClibc-0.9.32.1.so
474169 root-filesystem-i686/usr/tools/bin/gcc

448708 root-filesystem-m68k/bin/busybox
220264 root-filesystem-m68k/bin/make
424756 root-filesystem-m68k/lib/libuClibc-0.9.32.1.so
489885 root-filesystem-m68k/usr/tools/bin/gcc

659504 root-filesystem-mips/bin/busybox
304204 root-filesystem-mips/bin/make
464632 root-filesystem-mips/lib/libuClibc-0.9.32.1.so
579962 root-filesystem-mips/usr/tools/bin/gcc

476852 root-filesystem-powerpc/bin/busybox
222124 root-filesystem-powerpc/bin/make
341680 root-filesystem-powerpc/lib/libuClibc-0.9.32.1.so
487931 root-filesystem-powerpc/usr/tools/bin/gcc

388252 root-filesystem-sh4/bin/busybox
202036 root-filesystem-sh4/bin/make
310628 root-filesystem-sh4/lib/libuClibc-0.9.32.1.so
210712 root-filesystem-sh4/usr/tools/bin/gcc

482168 root-filesystem-sparc/bin/busybox
228876 root-filesystem-sparc/bin/make
358432 root-filesystem-sparc/lib/libuClibc-0.9.32.1.so
524888 root-filesystem-sparc/usr/tools/bin/gcc

464544 root-filesystem-x86_64/bin/busybox
215808 root-filesystem-x86_64/bin/make
364992 root-filesystem-x86_64/lib/libuClibc-0.9.32.1.so
634843 root-filesystem-x86_64/usr/tools/bin/gcc

Note how the sizes are all over the place for the same tools built in
the same configuration by the same compiler version, just for different
targets. I put both i586 and i686 in there to show how much variation
you can get between minor architecture variants.

Also, what format is that kernel in? If it's vmlinux, that's A) not
compressed B) has some ELF overhead.

And we are not even talking about dynamic footprint, or filesystem requirements!

True. There's probably a lot that can get chopped out of there.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.

On Wed, 2012-04-25 at 00:59 +0100, Ian Stirling wrote:

(resent after error in sending address)
On 04/18/2012 06:18 AM, Robert Schwebel wrote:

On Tue, Apr 17, 2012 at 05:20:22PM -0700, Tim Bird wrote:

With regard to your other question, I don't know of anyone running
Linux on only 1 MB. I have run Linux in about 1.5 MB of RAM but only
by "cheating" by putting the kernel into flash and using
Execute-in-place.

We have been running with about 1 MB when working on the Cortex-M3 and
EFM32 port recently, but it turned out that, even with xip, real work
(more than a booting kernek) was only possible with 4 MB.

This is likely to get suddenly more relevant in the next year or ten,
when microcontrollers able to run linux arrive.
That is - a system in one chip, not requiring RAM or ROM soldered on.
They don't - yet - exist.

http://search.digikey.com/us/en/products/LPC4330FBD144,551/568-9450-ND/2840463
- for example - has 264K of RAM.
It's not going to be that long till linux becomes available in one-chip
form.

Existing full systems like the 700MHz Raspberry Pi run desktop Linux,
have 256 _MB_ of RAM on-package (POP) and sell retail for $25, complete
with SD, USB, Ethernet, HDMI, audio, floating point, and a GPU.

On the other end, we have stuff like the NXP LPC1114, which puts a
stand-alone 50MHz ARM Cortex M0 uC with 32K of RAM/Flash in a 5mm²
device for $1.33 each. DIP form-factor if you want.

So I think the industry's well within range of making single package
Linux-capable devices with sufficient RAM, flash, CPU, and basic
peripherals like oscillator, USB, and I²C/SPI in a 8mm² package for $5
today. In fact, the engineering effort for an ARM licensee to do that is
significantly less than you'd spend trying to cut Linux's memory
footprint in half. Ergo, the days of projects like Linux-tiny are behind
us.

--
Mathematics is the supreme nostalgia of our time.