Linux on Palm/Sony PDAs? - Portable

This is a discussion on Linux on Palm/Sony PDAs? - Portable ; Logan Shaw writes: > Pascal Bourguignon wrote: > > > Logan Shaw writes: > > >>By the way, can anyone explain how the memory protection works? > > > It needs some addition hardware: a Memory Management Unit (MMU). The ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 26 of 26

Thread: Linux on Palm/Sony PDAs?

  1. Re: Linux on Palm/Sony PDAs?

    Logan Shaw writes:

    > Pascal Bourguignon wrote:
    >
    > > Logan Shaw writes:

    >
    > >>By the way, can anyone explain how the memory protection works?

    >
    > > It needs some addition hardware: a Memory Management Unit (MMU). The
    > > processor can run in at least two different modes: supervisor and
    > > user.

    >
    > Well, certainly this is how memory protection works on a desktop
    > or server machine. But does it really work this way on the
    > Palm?


    True memory protection is done only in hardware.

    You can simulate in in a virtual machine. So you can have it too
    without hardware if the OS runs user code in a virtual machine. That's
    not the case in 680x0 Palm OS.

    > I looked up some of the specs for the MC68**328 DragonBall
    > processors that are used in the Palms (before OS 5.x), and they
    > do not have an MMU. At least, the product literate doesn't
    > mention it, and in fact it says that the core is a "Static FLX68000
    > CPU -- identical to MC68EC000 microprocessor". Since I have done
    > assembly language programming on the MC68000, I know it doesn't
    > have MMU functions. It does have a privileged and user-mode
    > distinction, but as I recall it was flawed and they reworked it
    > a little bit when they introduced the 68010. Then of course
    > everything was reworked further with the 68020 (when they introduced
    > an external MMU chip) and the 68030 (which had an internal MMU).
    >
    > Anyway, as far as I know, the 68000 doesn't include an MMU and
    > wasn't really designed to work with one. That's why I'm curious
    > how Palm has pulled this off.


    Actually the 68000 allowed for MMU. When the Lisa and the first
    Macintosh appeared, Motorola made segmented memory management units
    that would have been a perfect fit for the Macintosh memory management
    (pointer blocks, handles and resources), and how funny, that's about
    the same memory management we have in PalmOS. Apple decided not to
    include this MMU in the first Macintosh because of cost; Palm decided
    against because of energy. At the same time there was unix
    workstations built on this 68000 chip (there was no other) and they
    had MMUs.


    --
    __Pascal_Bourguignon__
    http://www.informatimago.com/
    Do not adjust your mind, there is a fault in reality.

  2. Re: Linux on Palm/Sony PDAs?

    In article ,
    Reinder Mulder wrote:

    > Only machines that are *very* stable offer that many ways to perform a
    > reset ;-)


    Like, say, Windows and the variety of safe modes?

    - A normal Palm reset is the equivalent of hitting the rest button on
    the PC.
    - A soft Palm reset is like starting up in Safe mode.
    - A hard Palm reset is like reformatting your PC.

    Don't try to tell me you don't need these things in another OS! There
    are few OSes that don't have some variety of safe mode, and the other
    two are built into the hardware.
    when hitting.

    You should be able to get everything working again after a soft reset
    and deleting the offending app. I can only imagine what's been installed
    on that poor Tungsten C in Circuit City...

  3. Re: Linux on Palm/Sony PDAs?

    On Mon, 15 Sep 2003 16:46:22 GMT, Logan Shaw wrote:

    > Jim Anderson wrote:
    >> Actually you missed the Double-soft reset, Extended Hard Reset and Debug
    >> reset.


    > And the half double decaffeinated half-caf reset, with a twist of lemon.


    > I'm really not sure I understand what the double soft reset does
    > differently than a regular soft reset or whether its different
    > behavior was an intentional thing, but maybe it'll come in
    > handy one day...


    > - Logan


    Just like those old high milage motor scooters. The kickstarter does not
    spin the engine long enough for continuous combustion, so before the engine
    stops spinning from the first kick ya gota kick it again. ( 8(|)

    --
    Jim Anderson, Omphaloskepsis apprentice (@)
    ( 8(|) To e-mail me, just pull 'my_finger'
    The more hair you loose, the more head you get.

  4. Re: Linux on Palm/Sony PDAs?

    'Twas Mon, 15 Sep 2003 16:23:33 GMT when all comp.os.linux.portable stood
    in awe as Steven Fisher uttered:

    >Did I say in there that it wouldn't crash? In fact, memory protection
    >guarantees *more* crashes, since the device will crash rather than allow
    >illegal operations.


    Memory protection should crash the misbehaving application, but the OS
    should stay up.
    --
    RB |\ © Randall Bart
    aa |/ admin@RandallBart.spam.com Barticus@att.spam.net
    nr |\ Please reply without spam I LOVE YOU 1-917-715-0831
    dt ||\ http://RandallBart.com/ Ånåheim Ångels 2002 World Chåmps!
    a |/ Multiple sclerosis: http://www.cbc.ca/webone/alison/
    l |\ DOT-HS-808-065 The Church Of The Unauthorized Truth:
    l |/ MS^7=6/28/107 http://yg.cotut.com mailto:s@cotut.com

  5. Re: Linux on Palm/Sony PDAs?

    Randall Bart wrote:

    > Memory protection should crash the misbehaving application, but the OS
    > should stay up.


    When the OS only runs one application at a time, it makes little
    difference as long as the memory was protected.


  6. Re: Linux on Palm/Sony PDAs?

    On Mon, 15 Sep 2003 04:36:23 GMT, Logan Shaw
    wrote:

    >By the way, can anyone explain how the memory protection works?
    >Is it just a matter of most Palm code using 16-bit relative
    >pointers and the protected data being stored more than 32 kilobytes
    >away?


    Not relevant to Palm, but I'll mention that the Psion Epoc PDAs
    (which have a very stable OS) give each process its own virtual
    address space, which is translated into physical ROM and 4k pages
    of RAM addresses by the memory management unit. Read only memory
    is shared, but the writable memory of each process can't be
    accessed by another process. You can of course have multiple
    instances of any of any applications running simultaneously.

    Any RAM page can be allocated to any of a user process virtual
    address space. The kernel server process address space. The RAM
    disk (drive C). DLLs loaded from the non-ROM file system (RAM for
    DLLs is marked read only after being loaded, and appears at the
    same virtual address for all threads that use it). MMU
    translation tables (pretty much unlimited numbers of processes
    and threads). The Free list. As a consequence, RAM is always
    dynamically allocated between user process memory and disk space
    without user intervention.

    Processes have one or more threads, each executing independently
    of any other thread, however threads are not as isolated as
    processes, and can change memory of another thread within the
    same process.

    When an application is launched it creates a new process with a
    single main thread. Its address space includes areas for system
    wide memory (ROM and RAM loaded shared DLLs, which do not support
    writable static data), process wide memory (like the .exe image
    and its writable static data), memory for each thread, for a 12k
    stack (so don't use large automatic C++ variables, or set the
    stack larger), and a default heap. The stack can't be expanded,
    but the heap can grow (to up to 2MB for a Psion 5mx - limit is
    set by the OEM). Since a thread's non-shared heaps are allocated
    into a 256MB virtual address region, there is an implied limit of
    128 threads per process.

    The lack of writable static data in DLLs is because of the
    scarcity of memory. There are about 100 DLLs, and a typical
    major application may use 60. So if 20 applications are running,
    and 10 system servers, then with a 4KB MMU page, you could have
    (20+10)*60*4KB or 72MB for the writable static data! And unlike
    a PC, you don't have virtual memory paged onto a disk.

    Threads are preemptively scheduled by the Epoc kernel, and can
    suspend. The scheduler minimises context switching overheads.
    Switching between a thread in one process and a thread in another
    process is the most time expensive, as the MMU settings must
    change, and hardware caches must be flushed.

    Typically Epoc applications actually use a single thread, and
    rely upon the excellent event handling capabilities of the active
    objects. These active objects implement non-preemptive
    multitasking within the context of a single thread. This does
    mean event handlers need to complete within a few milliseconds
    within a server, or a few seconds within an application.

    This is a bit different to most operating systems, which usually
    use multiple threads to multitask. In Epoc it is better to use
    active objects. You will not be preempted within a thread, so you
    don't need mutexes, semaphores, critical sections or
    synchronisation. The major problem is that your RunL() MUST
    complete.

    What about long running threads? Spreadsheet recalculation, game
    engine calculations, background printing? Either you simulate
    them using active objects, and a chain of pseudo-events, or you
    really do multithread. In Epoc, the first is more efficient.
    The biggest problem comes with porting code with very different
    assumptions.

    How does it all work out in practice? Others have pointed out
    that Epoc is pretty stable, often running several years between
    resets. It is also pretty fast. The first Epoc hardware was
    running on an 18 MHz ARM, and was acceptable. When the hardware
    went to 36MHz, it felt pretty fast.

    --
    Eric Lindsay http://www.ericlindsay.com/guff
    Airlie Beach Qld Australia - Great Barrier Reef entry
    Psion & Epoc site http://www.ericlindsay.com/epoc

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2