[U-Boot-Users] JFFS2 support - was: (no subject)

[C. Michael Sundius]

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

On Mar 31, 2005, at 3:05 PM, Wolfgang Denk wrote:

>
> repl: bad addresses:
> 	C.Michael Sundius <msundius at sundius.com> -- 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!!!!
>
>
> In message <6b2c38e74085edfd4af93cd2f311e7ee at sundius.com> you wrote:
>>
>> 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?
>
> Yes, we are. Some of our customers are.
>
>> in reading the code, it seems
>> as though there are many comments indicating that the support is a
>> "less than elegant" implementation.
>
> Feel free to improve it ...
>
>> that said, does anyone use this feature.. it seems to me that it is
>> very useful to have and many would
>
> Guess why it has been added to U-Boot?
>
>> anyway, if anyone who has some experience with using JFFS2 in concert
>> w/ u-boot could respond,
>
> A precise question is the prerequisite to any useful response.
>
>> btw: the problems I am having seem to be related to reading symbolic
>> links.
>
> 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.
>
>
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