nanogui: Speed Issues on a slow CPU
Subject:
Re: [nanogui] Speed Issues on a slow CPU
From:
Amadeus ####@####.####
Date:
3 Oct 2007 19:21:35 +0100
Message-Id: <200710032020.49684.amadeus@iksw-muees.de>
Alan,
glad to hear from you!
On Mittwoch, 3. Oktober 2007, Alan Cox wrote:
> > system, with 32 MByte of this memory is a bit slower than usual.
>
> I couldn't find info on this to see what its performance hit was
The speed of a burst read is 120ns for 16 bit. Not much...
I have not investigated into running apps in thumb mode.
> or
> if you have put a small graphics accelerator library on the ARM7
No. The video memory is exported as a framebuffer to the ARM9 running
nano-X in 16bit RGB mode.
> Do you have gprof running on the system yet - embedded can have such
> strange bottlenecks that gprof can reveal a lot - and you only need
> the profiling side on the DS. You can do the analysis with cross
> tools on a PC.
I will look into gprof.
> "No. Because the NDS has no MMU, DSLinux has no virtual memory, so it
> cannot swap at all."
>
> Thats not totally true - you can swap entire apps to/from secondary
> storage if you have any kind of segmentation (eg FCSE on
> some ARM although the granularity is a bit high..) and/or PI code.
Hmm.. swapping entire apps may be possible. The current state is that
the kernel and a minimal userland (busybox) are occupying 2 MBytes of
the internal RAM (XIP), and the other 2 MBytes are free for
applications.
> You've also presumably got protection ranges ?
Yes. We use them for access control to the special memory regions of the
DS.
> "Why doesn't DSLinux support reading from or writing to a CF"
>
> if you've got specs for the CF interface and a tester thats probably
> easy to fix now.
Where have you found that? It's outdated. With the incorporation of the
DLDI interface (http://dldi.drunkencoders.com) we have access to most
SD/CF based hardware on the DS.
There is one SERIOUS problem in this area I have not found a solution
for: as soon as FAT16 with 32 KByte cluster size is used (needed for
the common 2 GByte SD cards), DSLINUX has problems to handle them.
There are data aborts while directory traversal. I have not heard from
any other embedded system having this problem, and it looks rather
strange to me.
regards
Amadeus
--
We're back to the times when men were men
and wrote their own device drivers.
(Linus Torvalds)
