linux-kernel - Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Sep 2008 17:34:21 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Jared Hulbert <jaredeh@...il.com>
Cc:	Greg Ungerer <gerg@...pgear.com>, Linux-kernel@...r.kernel.org,
	linux-embedded@...r.kernel.org,
	linux-mtd <linux-mtd@...ts.infradead.org>,
	Jörn Engel <joern@...fs.org>,
	tim.bird@...sony.com, cotte@...ibm.com, nickpiggin@...oo.com.au
Subject: Re: [PATCH 00/10] AXFS: Advanced XIP filesystem

Jared Hulbert wrote:
> >> > What kind of NOR you using?  That is not what I measure with fast
> >> > synchronous burst NOR's.
> >>
> >> I think the "fast" in "fast synchronous" gives it away :-)
> >>
> >> I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
> >
> > By the way, what speeds do you get on fast synchronous burst NORs - and
> > which chips are those?
> 
> I am only familiar with the Numonyx product line up.
> 
> If you are using a GL, you'll probably find our P33 a good fit and at
> competitive prices to GL as I understand it.  That's I think 50Mhz.

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.

> A rule of thumb is to say that copying to RAM will reduce this value
> less than 50% because RAM should be at least a little faster than NOR.

In our case, RAM is at least 100x faster :-)

> Nevertheless, If you can't use a simple calculation like this to
> explain the numbers then you have a poorly configured bus timings or
> have your cache off.

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.

> So, If you are only getting 0.6MB/s out of your NOR..... You're
> using it wrong.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/