[Q] TinyLinux project status (resend)

[Q] TinyLinux project status (resend)

[Ezequiel García]

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

[Celinux-dev] [Q] TinyLinux project status (resend)

[Ezequiel García]

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.

[Celinux-dev] [Q] TinyLinux project status (resend)

[Ezequiel García]

Hi,

2012/4/24 Gustavo Sverzut Barbieri <barbieri@profusion.mobi>:
>> 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!

[Celinux-dev] [Q] TinyLinux project status (resend)

[Ezequiel García]

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

[Celinux-dev] [Q] TinyLinux project status (resend)

[Thomas Petazzoni]

Hello,

Le Wed, 25 Apr 2012 15:14:09 -0500,
Rob Landley <rob@landley.net> a ?crit :

> Query: is there any way to set up a nommu system with:
> 
> A) stock vanilla upstream packages (kernel, uClibc, busybox)
> B) running under qemu
> 
> I've had a todo item to add a nommu target to Aboriginal Linux but every
> time I do so I poke at making i386 nommu and it just doesn't seem to
> want to do that. (Can't imagine why...)

With a few Qemu patches and kernel patches, I'm able to boot into
userspace a Coldfire system under the Qemu Coldfire emulation. However,
the system crashes as soon as the first userspace program exits (the
kernel thinks I'm killing init, I haven't had the time to investigate
this). The kernel configuration and Qemu patches have been posted at
http://lists.busybox.net/pipermail/buildroot/2012-April/052581.html.

I have also been able to boot an ARM noMMU kernel for the AT91x40 SoC
under SkyEye. This time, the userspace works fine. I haven't had the
time to clean up this, and it requires patches to both the kernel and
SkyEye to work properly. If you're interested, I'll give you these
patches and configs when I'm done with the cleanup.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Celinux-dev] [Q] TinyLinux project status (resend)

[Thomas Petazzoni]

Hello Greg,

Le Thu, 26 Apr 2012 09:56:23 +1000,
Greg Ungerer <gerg@snapgear.com> a ?crit :

> I couldn't see any kernel patches linked here. Did you need any,
> or have you posted them somewhere else?

The kernel patch is at
http://lists.busybox.net/pipermail/buildroot/2012-April/052585.html,
hidden inside a Buildroot patch.

I haven't posted it anywhere else because it's a hack to workaround a
Qemu problem: the 5208 apparently has support for separate supervisor
and userspace stack pointers (through two different registers), but
Qemu doesn't emulate that. So I think it's a flaw in Qemu emulation
rather than a kernel problem, but it was easier for now to workaround
it by just adding one "select COLDFIRE_SW_A7".

> Nice to see that it can run under QEMU!

Well, as I said, it actually doesn't run very well: if I use /bin/sh as
init=, then I can run *one* command, and the kernel crashes :-)

So we can say it boot all the way to userspace, but userspace isn't
very useful :)

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Celinux-dev] [Q] TinyLinux project status (resend)

[Thomas Petazzoni]

Le Thu, 26 Apr 2012 20:13:08 +1000,
Greg Ungerer <gerg@snapgear.com> a ?crit :

> > I haven't posted it anywhere else because it's a hack to workaround a
> > Qemu problem: the 5208 apparently has support for separate supervisor
> > and userspace stack pointers (through two different registers), but
> > Qemu doesn't emulate that. So I think it's a flaw in Qemu emulation
> > rather than a kernel problem, but it was easier for now to workaround
> > it by just adding one "select COLDFIRE_SW_A7".
> 
> Ah, ok. I only put the dual stack pointer support in a year or 2 back.
> And it is only supported on the more modern ColdFire's, guess the QEMU
> support is for the simpler parts :-)

Well, either Qemu pretends to emulate a 5208 and it should support the
dual stack pointer thing, or it shouldn't pretend to emulate a 5208.

Am I correct in my understanding is that the 5208 hardware does support
dual stack pointers?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com