nanogui: Speed Issues on a slow CPU
Subject:
Re: [nanogui] Speed Issues on a slow CPU
From:
Alan Cox ####@####.####
Date:
3 Oct 2007 19:31:14 +0100
Message-Id: <20071003193558.55758fc7@the-village.bc.nu>
> The speed of a burst read is 120ns for 16 bit. Not much...
> I have not investigated into running apps in thumb mode.
That may help, also putting the blitter functions into assembler and
using the ability to lock them into cache. This is where stuff like gprof
timing can reveal the true hotspots.
> 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.
Thats pretty tight. I'd assumed you were able to use the full 32MB as
well.
> 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.
I've not seen similar reports at all, but I don't know how many people
are using FAT16 on such devices on a PC in Linux.
Alan
