Anna, >> 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?
I did not write any code myself. I had two chronic problems: running out of memory in large enough chunks to connect an SSH session (cat /proc/buddyinfo) and program crashes, due I believe to stack overflows. I fixed the compiler to catch stack overflows and I patched BusyBox to enable printing fatal termination messages to stderr so "echo 1 >/proc/sys/kernel/print-fatal-signals" would produce a register dump when an illegal instruction exception occurred (a tell-tale sign of stack corruption). The memory shortage was the biggest headache. uClinux appears to have custom versions of common applications that have been cut down to fit in a memory-constrained system. NTP is clearly not one of them (the code is pretty sloppy with memory use). Not having an MMU makes it that much harder to figure out that stack overflow is the problem. Maybe my patched GCC will make that easier now for people that are using M68K processors, like ColdFire. I don't think XIP makes debugging uClinux code any harder, unless you plan to use gdb and you want to patch the running code (i.e., insert breakpoints). I should think you could twiddle the XIP bit for the one executable you were working on if you need to do that. I think there is a utility to manipulate uCLinux flat binary header bits, but I don't remember what it is called. > Thanks, > Anna I will send you off-list copies of my documentation for my uClinux work and my GCC fixes. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov
_______________________________________________ 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
