On Mon, 15 Sep 2008, Jared Hulbert wrote:
I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
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
NAND is significantly faster when writing than NOR, read speed is of the
same magnitude, possibly slower in many cases.
Right.
Specifically, read bandwidth is on the same order of magnitude.
However the read latency of NAND is a couple orders of magnitude
higher (100ns vs 20,000ns) so it
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
I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
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 :-)
S29_GL_128N
I think the fast in fast synchronous gives it away :-)
Yes, I suppose it does.
I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
I think you should get more like an order of magnitude higher Get
an expert to look at your timings in the bootloader. Make sure things
On Fri, Aug 22, 2008 at 11:43 AM, Jamie Lokier [EMAIL PROTECTED] wrote:
Jamie Lokier wrote:
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
I found what's wrong.
The size of an AxFS image created by mkfs.axfs is always n*4096+4 bytes large.
So when it wants to check the magic value in the last 4 bytes, the block layer
tries to read a whole 512-byte sector, which fails for loop-mounted images.
If you test on real FLASH,
On Tue, 2 September 2008 09:44:19 -0700, Jared Hulbert wrote:
How is one expected to read those last 4 bytes of a loopbacked file?
Are they unreadable? We can add the padding. I am just wondering if
this is a bug or a known limitation in the loopback handling or if
there is a different
How is one expected to read those last 4 bytes of a loopbacked file?
Are they unreadable? We can add the padding. I am just wondering if
this is a bug or a known limitation in the loopback handling or if
there is a different safer way of reading block devs with truncated
last blocks.
On Tue, 2 Sep 2008, Jared Hulbert wrote:
However, there still are weird things going on, like `find' not seeing all
files and directories, or just aborting, and `ls -lR' showing actual file
contents in its output.
Do you see this behavior for all builds for just the PS3?
The `find' issue
On Fri, 22 Aug 2008, Jared Hulbert wrote:
The version in SVN seems to be slightly older than the one you submitted?
Oops. Okay I must have neglected to sync at the very end. Thanks.
I forgot, there is also a git repo at
git://git.infradead.org/users/jehulber/axfs.git
Which
Hi Jared,
Jared Hulbert wrote:
That would be enough I think. If you could manually select
which files are contiguous-and-uncompressed that would be
useful for some too here.
So If you don't have an MMU when do you call -fault? Does the
noMMU code just loop through -fault()ing all the
On Fri, 22 Aug 2008, Will Marone wrote:
Geert Uytterhoeven wrote:
I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing
new
code ;-).
When mounting the image, I got the crash below:
| attempt to access beyond end of device
| loop0: rw=0, want=4920, limit=4912
|
On Fri, 22 Aug 2008, Jared Hulbert wrote:
The version in SVN seems to be slightly older than the one you submitted?
Oops. Okay I must have neglected to sync at the very end. Thanks.
I forgot, there is also a git repo at
git://git.infradead.org/users/jehulber/axfs.git
Which
Geert Uytterhoeven wrote:
From your good relationship with the s390 developers, I had hoped you would
have done some tests on s390 ;-)
Haha, we let you sort out the endianess issues first and then take the
easy path :-). We have'nt tried it yet so far.
--
To unsubscribe from this list: send
On Fri, 2008-08-22 at 09:51 -0700, Jared Hulbert wrote:
Can you run mkfs.axfs on the same trivial directory on both ia32 and
PPC64 and then get me the resulting images?
git.infradead.org is a big-endian box, and I know you have an account
there...
--
David Woodhouse
Hi Jamie,
Jamie Lokier wrote:
Greg Ungerer wrote:
Sort of. It actually just uses a single -read to bring in
the entire file contents. There is a few limitations on the use
of mmap() for non-mmu. Documentation/nommu-mmap.txt gives
more details. With no MMU it does rely on being able to
Hi Jared,
On Wed, 20 Aug 2008, Jared Hulbert wrote:
I'd like to get a first round of review on my AXFS filesystem. This is a
simple
See http://axfs.sourceforge.net for more info.
The version in SVN seems to be slightly older than the one you submitted?
Which platform(s) do you use
On Friday 22 August 2008, Geert Uytterhoeven wrote:
I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
code ;-).
When mounting the image, I got the crash below:
| attempt to access beyond end of device
| loop0: rw=0, want=4920, limit=4912
| Unable to handle
The version in SVN seems to be slightly older than the one you submitted?
Oops. Okay I must have neglected to sync at the very end. Thanks.
I forgot, there is also a git repo at
git://git.infradead.org/users/jehulber/axfs.git
Which platform(s) do you use for testing?
ARM, x86
I gave
Jared Hulbert wrote:
On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier [EMAIL PROTECTED] wrote:
Greg Ungerer wrote:
One thing for sure is that many people who do non-MMU setups
are interested in XIP to get the space savings. These are very
often small devices with very constrained RAM and
Geert Uytterhoeven wrote:
I gave AxFS a try on PS3 (ppc64, always use big-endian 64-bit for testing new
code ;-).
When mounting the image, I got the crash below:
| attempt to access beyond end of device
| loop0: rw=0, want=4920, limit=4912
| Unable to handle kernel paging request for data at
Jared, nice work!
I've also read your paper from the linux symposium
(http://ols.fedoraproject.org/OLS/Reprints-2008/hulbert-reprint.pdf)
A few questions:
- how does this benchmark compared to cramfs and squashfs in a NAND-only system
(or is it just not a good plan to use this with NAND-only
Jared Hulbert wrote:
I'd like to get a first round of review on my AXFS filesystem.
I like the general approach of it. It's much more flexible than the
ext2 extension I've done, and the possibility to select XIP vs.
compression per page is really really neat. I can imagine that people
will
On Thursday 21 August 2008 20:25, Carsten Otte wrote:
Jared Hulbert wrote:
I'd like to get a first round of review on my AXFS filesystem.
I like the general approach of it. It's much more flexible than the
ext2 extension I've done, and the possibility to select XIP vs.
compression per page
Jared Hulbert wrote:
The biggest improvement is in the way AXFS allows for each page to be XIP or
not. First, a user collects information about which pages are accessed on a
compressed image for each mmap()ed region from /proc/axfs/volume0. That
'profile' is used as an input to the image
I like the general approach of it. It's much more flexible than the ext2
extension I've done, and the possibility to select XIP vs. compression per
page is really really neat. I can imagine that people will prefer this over
the ext2 implementation on s390. It is unclear to me how the secondary
Hi Jared,
Jared Hulbert wrote:
How does it fare with no MMU? Can the profiler and image builder lay
out the XIP pages in such a way that no-MMU mmaps can map those regions?
No complaint if not, it would be a nice bonus though.
Sorry. I don't believe it will work on no-MMU as is. That said
That would be enough I think. If you could manually select
which files are contiguous-and-uncompressed that would be
useful for some too here.
So If you don't have an MMU when do you call -fault? Does the
noMMU code just loop through -fault()ing all the pages in an mmap()?
One thing for
29 matches
Mail list logo
