[uClinux-dev] ucLinux and XIP memory savings

Anna Fischer (novero/Bochum) Anna.Fischer at novero.com
Fri Jul 5 03:01:31 EDT 2013

> Subject: Re: [uClinux-dev] ucLinux and XIP memory savings
> Hi Larry,
> Thanks for your response.
> > Subject: Re: [uClinux-dev] ucLinux and XIP memory savings
> >
> > Anna,
> >
> > It is a national holiday in the US, so I am out of the office until
> > Monday when I will be able to send you more details.
> >
> > I tried to use a Lantronix EDS2100 for an RS-232 data-logging
> > application with remote access.  That box has an M68K ColdFire
> > processor, 8MB RAM, 8 MB flash.  I used XIP and any other technique I
> > could find to increase RAM.  The biggest headache was the Linux 2.6
> > power-of-2 buddy system memory allocator.  I guess in the 2.4 kernel,
> > there was a boxcar memory allocator.  That would have been better for
> > such a small memory system.  I had to resort to fixing GCC to try to
> > catch stack overflow problems in standard apps (NTP, for time -- no
> > RTC).  But, I ran out of time to get the system to run reliably -- it
> > kept locking up because of memory allocation failures due to the
> > power-
> > of-2 memory allocation scheme.
> Is this really still true? I had read somewhere that it is possible to
> replace the standard kernel memory allocator under ucLinux with one
> that is better suited to embedded systems, e.g. a block-based memory
> pool type allocator. I cannot find the reference anymore now though.

Actually I have just found that you are right and this was just the case for Linux 2.4 which is completely irrelevant now :-( 

However, the power-of-2 memory allocation is a general problem for ucLinux which is independent of XIP, isn't it? XIP does not make this any worse, does it? I'd say it should be more the opposite as by using XIP we use less RAM in general and therefore memory fragmentation hopefully has a little less impact.


More information about the uClinux-dev mailing list