(no subject)

Hi,

sorry to be a pest, A while ago I posted a message asking about support for JFFS2 within U-boot.

I didn't get a response so I'm wondering if anyone uses this feature? in reading the code, it seems
as though there are many comments indicating that the support is a "less than elegant" implementation.
(to be more specific they say have a paper bag ready in case you have to puke :]

that said, does anyone use this feature.. it seems to me that it is very useful to have and many would
want it.. on the other hand I know that the JFFS2 people have moved forward and don't support older
kernels and thus maybe this code is out of date.. or (more likely) my kernel is out of date.

anyway, if anyone who has some experience with using JFFS2 in concert w/ u-boot could respond,
I would be very grateful

btw: the problems I am having seem to be related to reading symbolic links.

thanks for you help

C Michael Sundius
Solico Group LLC
232 Nevada St
San Francisco, CA 94110
msundius at sundius.com
(415)608-0121

Hi Michael,

I use it ... on several boards ... MPC8270 & Nios-II ... with Bluecat Linux (PPC) and uClinux (Nios-II).

It works ... without fuss or problems for me :-)

Regards,
--Scott

scott,

what kernel do you use? what version of jffs?

C Michael Sundius
Brown Bear Realty
303 Cortland Ave
San Francisco, CA 94110
(415)608-0121
realtor at sundius.com

repl: bad addresses:
C.Michael Sundius <[email protected]> -- no at-sign after local-part (Sundius)

FIX YOUR MAILER!!!!

No. This is useless. Don't ask for a list of 50 different kernel versions with 30 different versions of MTD code which are all wokring in any combination.

Provide some useful, reproducable information yourself.

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."

repl: bad addresses:
C.Michael Sundius <[email protected]> -- no at-sign after local-part (Sundius)

Please configure your mailer correctly. If you use special chars in the name ('.') you are supposed to quote it.

AND PLEASE PROVIDE A USEFUL SUBJECT!!!!

Yes, we are. Some of our customers are.

Feel free to improve it ...

Guess why it has been added to U-Boot?

A precise question is the prerequisite to any useful response.

Can you be a _bit_ more explicit? What is your test case? What works,

and what does  not  work?  Are  you  on  NOR  or  NAND  flash?  Which
architecture?  How  did  you create the JFFS2 filesystem? How did you

install it? Which version of the Linux kernel is this? Which version of MTD code is in your Linux kernel tree?

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Teenagers are people who express a burning desire to be different by
dressing exactly alike.
There are some strings. They're just not attached.

Sorry about the lack of subject. my bad. I intended to tack on the subject
of my prior message.

as for my question, I'll reprint my original post:

----------------------------------------
I am using the 2.4.20 kernel and U-boot version 1.1.2. It seems as
though
while my kernel can read the jffs2 filesystem fine. u-boot seems to have some
trouble when reading (ls) of symbolic links..

This is pretty serious since we use busybox and that makes use of lots of links for
all of the common user/shell commands.

has anyone else seen this problem? is there a patch that fixes this? Is it because
the version of jffs2 that u-boot was made to work with is different than the one
that I have in my 2.4.20 kernel?
--------------------------------

more specifically, I see 3 behaviors:
1) when I do "ls", and the function comes upon a symbolic link, it tries to follow the link. the link
name comes out fine, but the target of the link is garbage (and thus sometimes crashes u-boot -
likely a buffer overrun when printing the name)

2) ls also sometimes prints the contents of a directory twice so if bin had files:

	a, b, c, d

it would print:

	# ls
		a
		b
		c
		a
		b
		c
		d
I am not sure if this is related to the fact that my file system has 
lots of symbolic links (I use busybox)
or b/c of some other problem w/ the jffs structure (which I may or 
maynot have botched in some way)

3) when I do FSLOAD command, it seems to intermitantly go off into the weeds and crash u-boot.
I have not quite qualified this behavior yet. but I'm working on it.

I don't doubt its something that I'm doing wrong or screwing up.. I *never* doubt *that*.. but initially I was just
looking for verification that this code is being used is in generally working order (dispite what the comments
say).

one thing I also didn't mention our hardware has 2 variants one that uses regular nor flash, and others use nand flash which are not mapped in to memory.
and thus -i am just realizing- code (like that that looks for the target of a sym link in
the func dump_inode() ) that reads data from the device and then assumes is a pointer to the device
instead of a pointer to a buffer might be incorrect:

		                unsigned char *src = (unsigned char *) (&i[1]);

if i is an inode that was read by get_node_mem(), might crash if the flash is not a memory mapped device.
problem is, that we're seeing this problem on the board w/ the memory mapped device..

well if I do find that this is a problem and if I find others I'll update you all ...

well, thanks for any help you can give.
Mike

C Michael Sundius
Solico Group LLC
232 Nevada St
San Francisco, CA 94110
msundius at sundius.com
(415)608-0121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4799 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050331/f215237d/attachment.bin

Hi,

Hear!

I am, as well - with ppc-kernel 2.4.20 patched with a newer mtd-code, though.
However, I know that in U-Boot version 1.1.2 and prior there is a "bug" writing jffs2-images if the device has bad blocks.

:-)

I haven't tried that, sorry...

// Martin