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
next prev parent 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