> Subject: Re: [uClinux-dev] ucLinux and XIP memory savings > > Anna, > > >> 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? > > Yes. There was a non-power-of-2 user memory allocator in Linux 2.4 (a > uClinux project?). That was never ported to 2.6 or later. When I > looked at the code, I came to the conclusion that too many places in > the kernel rely on the power-of-2 allocations. I could be wrong, and > something like a Fibonacci-based buddy memory allocator might work, as > long as the smallest memory allocation unit is at least the page size. > It is an interesting academic exercise, made a bit irrelevant by the > cheap ARM SoCs I've started using. I don't have enough lifetimes to > pursue all the things that interest me. :) > > > 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. > > This was my result. At work I have my notes for the development effort > on the Lantronix EDS2100. I employed every technique I could find to > free RAM for use by the programs I needed for my application.
Have you experienced other limitations when using XIP? I assume that, for example, it can be harder to debug XIP code? Thanks, Anna _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
