public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: C. Michael Sundius <msundius@sundius.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] JFFS2 support - was: (no subject)
Date: Thu, 31 Mar 2005 16:32:54 -0800	[thread overview]
Message-ID: <0ee5768feeb4609b1a0f3ec58d88e7bb@sundius.com> (raw)
In-Reply-To: <20050331230548.5AECAC108D@atlas.denx.de>

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@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@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 

  reply	other threads:[~2005-04-01  0:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-31 22:32 [U-Boot-Users] (no subject) C. Michael Sundius
2005-03-31 22:52 ` Scott McNutt
2005-03-31 22:56   ` C. Michael Sundius
2005-03-31 23:11     ` Wolfgang Denk
2005-03-31 23:05 ` [U-Boot-Users] JFFS2 support - was: " Wolfgang Denk
2005-04-01  0:32   ` C. Michael Sundius [this message]
2005-04-01  6:40   ` [U-Boot-Users] " Martin Egholm Nielsen
     [not found] <20050403205152.76E58C108D@atlas.denx.de>
2005-04-07 19:16 ` [U-Boot-Users] " C Michael Sundius
  -- strict thread matches above, loose matches on Subject: below --
2005-05-04 23:51 Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0ee5768feeb4609b1a0f3ec58d88e7bb@sundius.com \
    --to=msundius@sundius.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox