This paper compares several virtual memory designs, including combinations
of hierarchical and inverted page tables on hardware managed and
software-managed translation lookaside buffers (TLBs).
we are on the uCLinux forum. So I supposed the main interest is on
non-MMU systems (even thoug
On Thu 19 Jun 2008 08:42, Greg Ungerer pondered:
> But all processors running with virtual memory will have to
> deal with a TLB, and the extra cycle costs associated with
> TLB misses. As well as the work required to create and manage
> the page tables.
http://www.engr.umd.edu/~blj/papers/asplos
Hi Josef,
Wolf, Josef wrote:
rwarner wrote:
Have you seen this paper on why an mmu might not be wanted in
a embedded system?
http://www.linuxdevices.com/articles/AT2598317046.html
also in .pdf @
http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf
I've also thought that the memory
This paper states that this issue is caused by the (ARM specific) cache
on the logical address space.
What should be expected for other architectures? How is cache designed
on PPC and intel platforms? Are there differencies to expect?
I might be wrong, but AFAIK, ARM is the only architectu
rwarner wrote:
> Have you seen this paper on why an mmu might not be wanted in
> a embedded system?
>
> http://www.linuxdevices.com/articles/AT2598317046.html
> also in .pdf @
> http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf
>
>
> I've also thought that the memory page swapping t
I used to program FPGAs (one board had 36 large ones :-), but I'm
working an a dedicated CPU now because of unit cost in a price
sensitive project.
Seems OK, but I feel that the ratio is decreasing.
I have the impression that all FPGAs are either _much_ more expensive
than a CPU ($100s comp
Michael Schnell wrote:
> Thanks a lot for telling us your experiences.
>
> I feel very happy that I chose an FPGA and not a dedicated hardware CPU,
> so I can decide at any time if I want an MMU or not. :)
Yes, FPGAs are nice in that way. I like being able to add
special instructions and coproc
Thanks a lot for telling us your experiences.
I feel very happy that I chose an FPGA and not a dedicated hardware CPU,
so I can decide at any time if I want an MMU or not. :)
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailma
Greg Ungerer wrote:
> >Another is some handy programs (with no alternative) like iptables
> >don't work, because they depend heavily on loading shared libraries at
> >runtime. (Or does that work?)
...
> It wasn't that hard to rework. Look at the code in
> uClinux/dist/iptables. At the top of the
Hi Jamie,
Jamie Lokier wrote:
Andrew Kohlsmith (lists) wrote:
On April 17, 2008 12:43:37 pm Jamie Lokier wrote:
Video streaming i would consider a large scale system. Why was a non
MMU processor selected for a video streaming application?
Price and availability of a chip that did good video
Andrew Kohlsmith (lists) wrote:
> On April 17, 2008 12:43:37 pm Jamie Lokier wrote:
> > > Video streaming i would consider a large scale system. Why was a non
> > > MMU processor selected for a video streaming application?
> >
> > Price and availability of a chip that did good video (HDTV even), a
On April 17, 2008 12:43:37 pm Jamie Lokier wrote:
> > Video streaming i would consider a large scale system. Why was a non
> > MMU processor selected for a video streaming application?
>
> Price and availability of a chip that did good video (HDTV even), and
> we didn't know the no-MMU penalty at
rwarner wrote:
> Video streaming i would consider a large scale system. Why was a non
> MMU processor selected for a video streaming application?
Price and availability of a chip that did good video (HDTV even), and
we didn't know the no-MMU penalty at the time.
We did compare with some other d
Jamie Lokier wrote:
rwarner wrote:
For headless systems and ones semi-stagnant in memory
allocation/reallocation an MMU-less system has many advantages.
However, what they also do is run an "ssh" command every 30 seconds to
report home. That's enough to start the fragmentation problems.
This i
rwarner wrote:
> >>For headless systems and ones semi-stagnant in memory
> >>allocation/reallocation an MMU-less system has many advantages.
>
> >However, what they also do is run an "ssh" command every 30 seconds to
> >report home. That's enough to start the fragmentation problems.
> This is in
Stanislav Meduna wrote:
rwarner wrote:
You are aware that the ARM Ltd site has MMU based kernels with XIP?
What core/processor are you using?
# cat /proc/cpuinfo
Processor : ARM7TDMI rev 0 (v4l)
BogoMIPS: 20.28
Features: swp 26bit
CPU implementer : 0x41
CPU architecture:
Jamie Lokier wrote:
Yes, i some instances it is necessary. I worked on an avionics platform
that used 4K page sizes, so it was constantly paging in and out memory
for execution. The interesting thing was i also used a non-MMU OS on
the same processor PPC750 and noted the non MMU OS executed m
rwarner wrote:
You are aware that the ARM Ltd site has MMU based kernels with XIP? What
core/processor are you using?
# cat /proc/cpuinfo
Processor : ARM7TDMI rev 0 (v4l)
BogoMIPS: 20.28
Features: swp 26bit
CPU implementer : 0x41
CPU architecture: 3
CPU variant : 0x00
rwarner wrote:
> >Perhaps. The biggest problem with not having an MMU is memory
> >fragmentation. Basically, you can't keep allocating large contiguous
> >segments, but you need that to run ordinary executables and other
> >things.
> >
> >On my application, I need to keep about 8MB free out of 32
Stanislav Meduna wrote:
Jamie Lokier wrote:
Have you seen this paper on why an mmu might not be wanted in a
embedded system?
Perhaps. The biggest problem with not having an MMU is memory
fragmentation. Basically, you can't keep allocating large contiguous
segments, but you need that to run
Jamie Lokier wrote:
Have you seen this paper on why an mmu might not be wanted in a embedded
system?
Perhaps. The biggest problem with not having an MMU is memory
fragmentation. Basically, you can't keep allocating large contiguous
segments, but you need that to run ordinary executables and
Jamie Lokier wrote:
rwarner wrote:
Michael Schnell wrote:
I suppose due to hardware improvements, in the future even small systems
will have MMUs, so I thinks there is not too much priority on these
nommu issues. The NIOS will definitively get one, optionally , too, but
in the moment I don't
rwarner wrote:
> Michael Schnell wrote:
> >I suppose due to hardware improvements, in the future even small systems
> >will have MMUs, so I thinks there is not too much priority on these
> >nommu issues. The NIOS will definitively get one, optionally , too, but
> >in the moment I don't consider
Michael Schnell wrote:
I suppose due to hardware improvements, in the future even small systems
will have MMUs, so I thinks there is not too much priority on these
nommu issues. The NIOS will definitively get one, optionally , too, but
in the moment I don't consider to switch to that as the
Michael Schnell wrote:
> >Even PC-relative references have this problem, not just absolutes.
>
> Right you are, but I don't think the compiler generates PC-relative
> addresses to locations in the data-segment.
It does. Look at the GOTPC relocs used by ARM, for example.
-- Jamie
___
Even PC-relative references have this problem, not just absolutes.
Right you are, but I don't think the compiler generates PC-relative
addresses to locations in the data-segment.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http:
Michael Schnell wrote:
> >You forgot that the text segment may contain
> >references to data or bss.
> Ah, I did not suppose that there would be such absolute references,
> which would mean that that loader needs to modify the content of the
> text segment according to where it allocates the dat
That doesn't work. What do you do about relocations in the code which
point to addresses in the data segment?
I did not assume that this method would be used. I see now. Thanks !
Normal (non-XIP) code references data through addresses in the
instructions directly, because that is faster an
You forgot that the text segment may contain
references to data or bss.
Ah, I did not suppose that there would be such absolute references,
which would mean that that loader needs to modify the content of the
text segment according to where it allocates the data segment. I assumed
the data s
Michael Schnell wrote:
> >That's because code/data position independence requires the compiler
> >to generate special code, and support from the linker, but loadable
> >modules don't require any compiler support - they are easy.
> >
> The load address of the code segment of a loadable module is n
Am Mittwoch, den 16.04.2008, 16:32 +0200 schrieb Michael Schnell:
> > That's because code/data position independence requires the compiler
> > to generate special code, and support from the linker, but loadable
> > modules don't require any compiler support - they are easy.
> >
> The load addres
That's because code/data position independence requires the compiler
to generate special code, and support from the linker, but loadable
modules don't require any compiler support - they are easy.
The load address of the code segment of a loadable module is not known
at compile time. Thus it
Michael Schnell wrote:
> Thanks for the explanation.
>
> I did come to this conclusion when thinking about the issue :).
>
> What I find astonishing, is that some (seemingly many) non-MMU
> architectures don't support XIP (completely position independent code
> segment) and don't support using
Thanks for the explanation.
I did come to this conclusion when thinking about the issue :).
What I find astonishing, is that some (seemingly many) non-MMU
architectures don't support XIP (completely position independent code
segment) and don't support using a common code segment when starting
Hi Bob,
Bob Brusa wrote:
I am looking into the question: How many resources (flash and RAM) are
required to run a (typical) uClinux-system?
This depends on a lot of things, so it is hard to give any
reasonable answer. As a data point I have built uClinux systems
that had 1MB of RAM and 1MB of
Hi Michael,
Michael Schnell wrote:
Some architectures can do execute in place (XIP), some can't. (I did not
yet find out the exact reasons.)
Generally you need to be able to do the following for what
we call "XIP" in uClinux:
1. compiler can generate position independent code(*)
2. compiler
Am Montag, den 14.04.2008, 16:16 +0200 schrieb Michael Schnell:
> Some architectures can do execute in place (XIP), some can't. (I did not
> yet find out the exact reasons.)
>
> RAM usually is a lot faster than Flash, so XIP might be not desirable.
>
> -Michael
XIP isn't necessarily for flash o
Michael Schnell wrote:
> Some architectures can do execute in place (XIP), some can't. (I did not
> yet find out the exact reasons.)
>
> RAM usually is a lot faster than Flash, so XIP might be not desirable.
However, XIP is possible in RAM too. If RAM is fast but you don't
have a lot of it, or
Some architectures can do execute in place (XIP), some can't. (I did not
yet find out the exact reasons.)
RAM usually is a lot faster than Flash, so XIP might be not desirable.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailm
Bob Brusa schreef:
Hi
I am looking into the question: How many resources (flash and RAM) are
required to run a (typical) uClinux-system? At some places I read, that
each piece of software that is part of (uC)linux is loaded from disk,
decompressed and executed in RAM. On the other hand: From m
Hi
I am looking into the question: How many resources (flash and RAM) are
required to run a (typical) uClinux-system? At some places I read, that
each piece of software that is part of (uC)linux is loaded from disk,
decompressed and executed in RAM. On the other hand: From my previous
(int
41 matches
Mail list logo
