What's a GL? Never heard of it - all I can think of is OpenGL :-)
I'm using a Sigma Designs 862x media processor. It clocks at 166MHz
to main RAM, has an ARM internally to run Linux, and the intensive
work happens in coprocessors. The NOR is not on the RAM bus, it's on
a "peripheral bus". About the only thing I know about the bus is it's
16 bits wide - I have the schematic, but only the board supplier has
access to Sigma chip documentation.
In our case, RAM is at least 100x faster :-)
I'm not sure if cache is an option with this device - but would it
make a difference anyway? Launching executables like Busybox - those
are much larger than the cache anyway, so launch time is dominated by
bulk streaming copy speed. Thanks for the idea, I'll look into
whether it's possible to access this 'peripheral bus' through the
ARM's cache and see if that speeds up streaming read time.
Interesting, thanks. I'm not sure it's possible to change the way NOR
is being used with this chip, and it'll be a while before it's
economical to replace the board with a new design.
This is all very interesting - I had no prior experience with NOR, so
didn't know that 0.6MB/s was slow. It's fast compared with older
EEPROMs after all, and had imagined that people wanting fast flash
would use NAND.
On looking at the datasheet, I see it's quite a lot faster. I'm
suspecting the Sigma Designs perpheral bus and the way it's wired up
not doing it any favours. We already have the weirdness that we have
to patch the Linux CFI-0002 MTD code: the CPU locks up when polling
the erase status byte, until erase is finished. Unfortunately this is
difficult to change now - I'm programming hardware which is already
out in the field and cannot be redesigned.
Thanks for your thoughts.
-- Jamie
--
