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