Re: [UCLINUX] question about embedded cpu without MMU
On Wed, 25 Aug 1999, Wang Yong wrote: do u have some idea on how to port linux to chips without virtual mode MMU such as PPC401GF? how to implement memory protection and multi-task, both seem so hard on chips withour address translation? Since the PPC is already supported in Linux2.0, it will actually be easy to port uClinux to a PPC without MMU. Let us know if you need help. I was told 3com's palm pilot has got a 68328 without MMU. Does anyone know something about the solution from uclinux for 68328? ... you also need to either relocate all loaded text or compile it as position independent code (since you can't put all segments at their original VMA's). we relocate, i think uclinux uses PIC. All Linux which runs without MMU is actually called uClinux (that's what makes it different), and as far as I know all derived from the main line uClinux code base. But yes, there are 3 general approaches. The cleanest is Position Independant Code. This is useful, you get execute in place with this, but RAM is getting really cheap (even for embedded systems) these days, so this is less and less of an issue. PIC also helps to some extent with shared libs. Only the 68k port of uClinux has this as far as I know, unless i960 has it... The second approach is relocation, and using a Global Offset Table is a way to localize the relocation to a smaller piece of memory. With full relocation, you can't share anything, with a GOT you can still share .text. The GOT also gives you shared libs. The m68k port of uClinux will likely go this way, it's easier on the compiler (smaller patches) then the current PIC method, slower (1 extra longword access almost all the time) but on 68k removes a nasty 16 bit offset limit. Using a GOT on 68k will also elimiate any changes for the ColdFire port as well, BTW. The last approach is handles. Compiler Glue. Call it a soft MMU I guess. Store "tags" in the upper bits of pointers and let the compiler generate code to sort out what base register to use _at run time_. Don't go there :-) so to recap, the kernel itself is _comparatively_ easy to remove MM from, compared to the problems you'll get with shared libraries, ill-behaved programs, buggy programs, and programs that want to use fork() and MM. /Bjorn Wesen -- Cheers, Jeff / VE3DJF [EMAIL PROTECTED] http://www.cgocable.net/~jdionne Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper. Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper. -- To unsubscribe from this list, send a message to [EMAIL PROTECTED] with the command "unsubscribe linux-embedded" in the message body. For more information, see http://waste.org/mail/linux-embedded.
Re: [UCLINUX] question about embedded cpu without MMU
In message [EMAIL PROTECTED] Bjorn Wesen writes: : you can forget memory protection, but multitasking has nothing to do with : MM so that is no problem. the problem is how to implement the unix : semantics of fork(), and other MM tricks like demand loading and sharing : of text/data that support the multitasking model. mmap becomes nearly impossible as well, which eliminates shared libraries (or at least the sharing that libraries do when shared). : linux itself works fine without MM (since the kernel is mostly linearly : mapped anyway) but fork() can only make a new thread, not a new MM, so the : child will share data with the parent. you need to take this into : consideration when writing applications for uclinux (and other MMU-less : linuxes) as well as that there are limitations in the MM API (mmap et al) Yes. Exec also becomes interesting... I did try to get NetBSD running on a Vr4650 once, but with only base and bounds I gave up as producing a system that was too un-unix-like to be useful. Warner -- To unsubscribe from this list, send a message to [EMAIL PROTECTED] with the command "unsubscribe linux-embedded" in the message body. For more information, see http://waste.org/mail/linux-embedded.
Re: [UCLINUX] question about embedded cpu without MMU
Hello Jeff, Donald Jeff Dionne wrote: The second approach is relocation, and using a Global Offset Table is a way to localize the relocation to a smaller piece of memory. With full relocation, you can't share anything, with a GOT you can still share .text. The GOT also gives you shared libs. The m68k port of uClinux will likely go this way, it's easier on the compiler (smaller patches) then the current PIC method, slower (1 extra longword access almost all the time) but on 68k removes a nasty 16 bit offset limit. Using a GOT on 68k will also elimiate any changes for the ColdFire port as well, BTW. Do you plan to remove PIC support from m68k port then? Frankly speaking, I would like to see both methods available. My current board has 2MB of FLASH and 2MB of DRAM only, and the useful application code will just fit there. You should remember that in consumer electronics bill_of_material = price = bill_of_material * 4; Thus, even $5 more of components make quite a difference on the final price of the device. I would really like the "relocation type" to be include in the file header so that both approaches could be supported in the future. Regards, Vladimir -- +--++--+ | | | | | :|::|: | phone 408-525-9707 Vladimir Gurevich |:|||: :|||:| fax 408-527-1713 Software Engineer | .:|||:..:|||:. | NUBU/DIAL | CiscoSystems | e-mail [EMAIL PROTECTED] || location SJ-7-2 Cube D1-12 | http://www.cisco.com | +--++--+ -- To unsubscribe from this list, send a message to [EMAIL PROTECTED] with the command "unsubscribe linux-embedded" in the message body. For more information, see http://waste.org/mail/linux-embedded.
Re: [UCLINUX] question about embedded cpu without MMU
On Mon, 30 Aug 1999, Donald Jeff Dionne wrote: it could in short order (just a day). The real reason I've not bothered is I'm not sure it's a huge win. uClinux libc is 200k+ and growing. All the binaries for a normal complete uClinux are less than that in total. Perhaps there is a lot of wasted space in we use glibc, which is enormous. well, it's about 1.3 MB stripped. a statically linked application grows from 8 kb to 120 kb for example, so sharing is really important. glibc is (supposedly) multithread safe, so it's possible to let different processes run as threads inside glibc. is the uClinux libc complete, in the sense that normal linux programs on the net compile cleanly on it ? i've always felt that glibc is really bloated, but since there is no maintenance anymore for the older libc's.. it would be interesting to see some figures on the program / libc partitioning for the statically linked executables you put in a typical uclinux system. like, sash alone is 70 kb program + 400 kb library code :) -bjorn -- To unsubscribe from this list, send a message to [EMAIL PROTECTED] with the command "unsubscribe linux-embedded" in the message body. For more information, see http://waste.org/mail/linux-embedded.
Re: [UCLINUX] question about embedded cpu without MMU
we use glibc, which is enormous. well, it's about 1.3 MB stripped. a statically linked application grows from 8 kb to 120 kb for example, so sharing is really important. glibc is (supposedly) multithread safe, so it's possible to let different processes run as threads inside glibc. K. I didn't even consider it an option. is the uClinux libc complete, in the sense that normal linux programs on the net compile cleanly on it ? i've always felt that glibc is really bloated, but since there is no maintenance anymore for the older libc's.. uClinux "uC-libc" is maintained (just like the kernel) by us. Rt-Control provides commercial support for uClinux, so you know that it's not going away. It's design goals are different than glibc, small is the order of the day, but it is none the less complete enough to compile a good many things. When we find something that does not compile, it gets updated :-) it would be interesting to see some figures on the program / libc partitioning for the statically linked executables you put in a typical uclinux system. like, sash alone is 70 kb program + 400 kb library code :) ls -l /bin -rwxr-xr-x 1 004948 Jan 01 1970 df -rwxr-xr-x 1 004480 Jan 01 1970 free -rwxr-xr-x 1 006212 Jan 01 1970 hexdump -rwxr-xr-x 1 00 10656 Jan 01 1970 httpd -rwxr-xr-x 1 00 14084 Jan 01 1970 lissa -rwxr-xr-x 1 006164 Jan 01 1970 loattach -rwxr-xr-x 1 009640 Jan 01 1970 ls -rwxr-xr-x 1 00 41336 Jan 01 1970 mount -rwxr-xr-x 1 00 20416 Jan 01 1970 ping -rwxr-xr-x 1 00 35236 Jan 01 1970 pppd -rwxr-xr-x 1 00 11204 Jan 01 1970 ps -rwxr-xr-x 1 008280 Jan 01 1970 rootloader -rwxr-xr-x 1 00 23284 Jan 01 1970 sh -rwxr-xr-x 1 004236 Jan 01 1970 shutdown -rwxr-xr-x 1 00 14700 Jan 01 1970 slattach -rwxr-xr-x 1 00 16712 Jan 01 1970 telnetd -rwxr-xr-x 1 005116 Jan 01 1970 version These are static linked, right off a uCsimm. -bjorn -- Cheers, Jeff / VE3DJF [EMAIL PROTECTED] http://www.cgocable.net/~jdionne Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper. Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper. -- To unsubscribe from this list, send a message to [EMAIL PROTECTED] with the command "unsubscribe linux-embedded" in the message body. For more information, see http://waste.org/mail/linux-embedded.
