A pair of stupid questions, I hope

My manufacturing people want a test that responds yes or no to the question "is this sector locked?"

This seems like it should be pretty easy, but where and how do I determine that? Is it something that is stored in the mem_region? There are lock and unlock ioctls but it's not obvious to me how to query if a sector is locked? What is the proper way to do this?

then 4M flash.. It's looking more and more like we're going to move from 2MB to a 4MB flash. Supposedly the 4MB is banked and it's some Toshiba part that isn't listed in the code as supported yet. Do we already support anything like that? It looks easy enough to add support for a new part and I'm eager to give it a try but I don't know about this convoluted banking thing. Any advice?

thanks,
Ian

To unsubscribe, send "unsubscribe mtd" to [email protected]

Yeah, we should support that, but we currently don't have an API for it, and obviously that means there's no code to do it for any of the currently supported chipsets. Fairly trivial to do though. I'm not feeling inventive tonight. Propose an API extension and if it offends my sensibilities I'll have to think of something myself.

If it's a NOR part it ought to be fairly trivial. If it's NAND, supporting the part itself shouldn't be too hard, but JFFS2 doesn't work safely on it yet. JFFS should, although I haven't tried it myself. And obviously you can't boot from NAND flash unless you have an external ROM or NOR flash somewhere for the CPU power-up vector.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

I'll ask the guys who need it. I suspect the proposal would be an ISLOCKED
ioctl that takes a region as an argument and returns a 0 or 1. I'm a flash
novice though, is this something that should go in to one of those region structures?

That simplifies it because we will be booting off this flash. Thanks for the feedback though, I'll ping our hardware guys and make sure we're heading down the right path.

Ian

To unsubscribe, send "unsubscribe mtd" to [email protected]

I was thinking of the internal API - what method do we add to the struct mtd_info, and how generic can we make it? Aren't there other similar per-block data which we may want to query on some chips?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

Hi there

Has anybody managed to get a root FS with JFFS2 to work?

I followed the mtd howto and I have a root partition(with the necessary files) and
all I get is: "Kernel panic: I have no root and I want to scream" message.

first I tried to use "rdev zvmlinux /dev/mtdblock1", but the kernel ignored that an did a NFS mount as usual. I then specified on the kernel commad line: root=/dev/mtdblock1 and the I got the kernel panic above.

Any Ideas?

Jocke

To unsubscribe, send "unsubscribe mtd" to [email protected]

Does it still happen with CONFIG_DEVFS_FS=n?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

yes, I dont have devFS support compiled into the kernel.

Jocke

-----Original Message-----
From: David Woodhouse [mailto:[email protected]]On Behalf Of David Woodhouse
Sent: Wednesday, April 18, 2001 18:51
To: [email protected]
Cc: [email protected]
Subject: Re: JFFS2 as root FS

Does it still happen with CONFIG_DEVFS_FS=n?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

Hmmm. And do you have an entry for 'mtdblock' in the big array in init/main.c?

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

Sure! But as you say that you followed the HOWTO, and since I wrote the HOWTO,
I guess that something in my procedures tripped you up that worked ok for me :)

Hmm, what kernel version are you using? I've never seen that message (I've seen Kernel panic: Unable to open root..blah blah..)

Wait, wait, wait. What do you mean by this? This is *a problem* right here.

Why is it doing a NFS mount? Please describe your config and what you are trying to do.
"usual" kernels don't NFS mount their root fs!

Well, the kernel may not be able to understand the "mtdblock1" device by name unless you patched
the init/main.c file to list a conversion table from mtdblockxx to a *device number*.

These are some.

Vipin

To unsubscribe, send "unsubscribe mtd" to [email protected]

Don't know, I will have to check when I get back to work(I am home now)

Jocke

To unsubscribe, send "unsubscribe mtd" to [email protected]

----- Original Message -----
From: "Vipin Malik" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: den 18 april 2001 19:11
Subject: Re: JFFS2 as root FS

Dont think so, I think it's me :-)

I using a 2.4 kernel I pulled from Cort Dougan's PPC tree a few weeks ago. Can't remeber which version rigth now, I will have to check when I get back to work tomorrow. Should I change to the latest official kernel(2.4.3)?

I am using an RPX CLLF board with a PPC869T. I found a config under arch/ppc/defconfigs
(If my memory don't fail me)

In that config there were an automount(??) option enabled and a Root fs on NFS option also
enabled. I will disable them and se what happens.

Well, this I have not done. Cant remember I saw that in the mtd howto, is that patch
included in later kernels?

Other questions i have:

Is mkfs.jffs2 Endian safe? I mean can I run mkfs.jffs2 on an Intel PC and
then copy it to my RPX board?

Is there a way to disable compression in JFFS2?

I have also noted that sym links in JFFS2 have zero size, a bug?

To unsubscribe, send "unsubscribe mtd" to [email protected]

I don't know. Never played with a non-x86 kernel (well if you don't count the dragonball kernel variant).
I wouldn't think that you would need to update to the latest one, but i'll let someone who know's reply.

Make sure that you have the latest sources from CVS patched in though. You don't want to be playing with the
default mtd/jffs stuff that came with the kernel.

I don't think that just enabling these options actually *does* mount root over nfs. It just allows
it. (Disclaimer: I've never mounted root over nfs myself so take this with a pinch of salt).

You don't need to apply the patch if you stick with the rdev stuff, as that uses device numbers to
tell the kernel what root is.

You may have to dive into the kernel sources and put prink's to see that your kernel thinks root device is
that it's trying to mount. That'll tell you where the problem lies in the first place.

If it doesn't say something like 31:1 (for /dev/mtdblock1) then your rdev command did not take. Investigate that then.

If your root device is correct then investigate why it could not mount it. You did run lilo after you did rdev?

There *are* people using mtd/jffs on PPC. See the list archives for some issues that people have had and their possible solutions.

Hmm, you'r not trying to mount jffs as root before you can manually mount it as a "regular" partition under full manual control?
If you have endian issues, they should pop up at that time. Debugging endian issues and root mounting problems is not a good plan.

Not that I know of. I think it's in the to-do list. Ask David W.

David?

Vipin

To unsubscribe, send "unsubscribe mtd" to [email protected]

----- Original Message -----
From: "Vipin Malik" <[email protected]>
To: "Joakim Tjernlund" <[email protected]>
Cc: <[email protected]>
Sent: den 18 april 2001 22:19
Subject: Re: JFFS2 as root FS

the

for

necessary

(I've

ago.

back

the

let

yeah, I have the latest sources.

are

on

over

a

hmm, there has to be something in my config which takes precedence over rdev, otherwise
the kernel would try to mount mtdblock1 instead of doing a NFS mount. The kernel
does a BOOTP request to find its IP address, maybe that also implies to mount a NFS root
instead of mtdblock1?

by

is

that

would be nice to try this patch to see if things start to work. Do how this patch
looks?

your

You

Currently I let the RPX firmware boot the kernel via tftp. Is that whats causing my problems?
I have not tried LILO since I think it can only handle x86. Can it do PPC as well(with a JFFS2 root FS)?

and

issues

it as

No, I have mounted it manually first and then copied required files more or less by hand.
I tried mkfs.jffs2, but it didn't work for me. Maybe I am doing something wrong?
I did this: mkfs.jffs2 -d <path to my root fs dir> -o rootfs.image -e 0x40000
then on RPX: eraseall /dev/mtd1; cp rootfs.image /dev/mtd1(or was it mtdblock1?)

that gave me lots of errors when mounting JFFS2 on /dev/mtdblock1 (don't have the error messages handy now)

Does mkfs.jffs2 handle dev files & sym links correctly?

endian

heh, not a very good plan at all :-)

David, is it possible?

Jocke

To unsubscribe, send "unsubscribe mtd" to [email protected]

Hi!

We had the same problem with root nfs instead of jffs(1). The problem disappeared as soon as we removed the nfs root feature from the kernel config. I dont know where the problem exactly is, but this is a (ugly) solution.

Hope that helps
Florian

To unsubscribe, send "unsubscribe mtd" to [email protected]

Hi again

By adding /dev/mtdblock1 to init/main.c I managed to make Linux recognize my root FS on mtdblock1 :-)

Now I am having some other problems :-(
First it takes about 1 min 30 sec to mount my root FS. Is that expected? I was hoping for a much shorter
mount time, 10-20 sec
The root partition is 15 MB and df reports:

Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mtdblock1 15104 6580 8524 44% /mnt/mtdblock1

After the root FS is mounted, linux gets stuck right after message:
"Freeing unused kernel memory: 48k init"

I think that the next step is to run /sbin/init but that never happens.

Jocke

Below is my console log

PlanetCore Boot Loader v1.02
Copyright 2000 Embedded Planet. All rights reserved. DRAM available size = 16 MB
wvCV
DRAM OK

loaded at:     00210000 0021C57C
relocated to:  00180000 0018C57C
board data at: 001801B8 001801D4
relocated to:  00200100 0020011C
zimage at:     0024E583 002C725B
avail ram:     002C8000 01000000

Linux/PPC load: root=/dev/mtdblock1 rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.3-pre6 ([email protected]) (gcc version 2.95.2 19991030 (2.
95.3 prerelease/franzo)) #79 Thu Apr 19 10:35:54 CEST 2001
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 rw
Decrementer Frequency = 180000000/60
Calibrating delay loop... 47.82 BogoMIPS
Memory: 14640k available (1004k kernel code, 376k data, 48k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
pty: 256 Unix98 ptys configured
block: queued sectors max/low 9648kB/3216kB, 64 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:26:1b
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
loop: loaded (max 8 devices)
RPX Lite or CLLF flash device: 1000000 at ff000000
RPX: Found 4 x16 devices at 0x0 in 32-bit mode
Amd/Fujitsu Extended Query Table v1.2 at 0x0040
number of CFI chips: 1
0: offset=0x0,size=0x8000,blocks=8
1: offset=0x40000,size=0x40000,blocks=63
mtd: Giving out device 0 to RPX App 0xff000000
mtd: Giving out device 1 to RPX User space1,
mtd: Giving out device 2 to RPX CLLF boot firmware
mtd: Giving out device 3 to RPX User Space2, Empty
mtd: Giving out device 4 to RPX Diag & Utils
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024) Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 192.168.1.38, my address is 192.168.1.150
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. mtdblock_open
ok
mtdblock: read on "RPX User space1" at 0x400, size 0x400
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 48k init

<< here I power cycle the board >>

A
PlanetCore Boot Loader v1.02
Copyright 2000 Embedded Planet. All rights reserved. DRAM available size = 16 MB

To unsubscribe, send "unsubscribe mtd" to [email protected]

Hallo!

Did you try to mount the flash again under linux? We had a problem with the endianess some time ago and run into the same trouble as you did. Mounting took a long time and after that the flash was completely empty. Files cound be moved onto it, but as soon as you re-mounted the flash it was empty again. Try if this happens to you too.

I know its a wild guess but maybe it helps!

Happy hacking
Florian

To unsubscribe, send "unsubscribe mtd" to [email protected]

Hi, it's me again :-)

I have tried to mount the FS again and the files are still there. It still takes 1 min and 30 sec to mount it and sometime when I do a ls the system hangs
for 10-20 sec before the output from ls is seen. Is this normal?

Maybe I should change my kernel, but to which? Linux 2.4.3? Or maybe a later kernel from the PPC tree?

Also, when I boot the kernel it stops and ask for a kernel cmdline. Usually I press
return here and the boot continues with my default values. How can I make the kernel bypass
this and start without any questions asked?

Jocke

-----Original Message-----
From: Florian Schirmer / TayTron [mailto:[email protected]]
Sent: Thursday, April 19, 2001 15:02
To: [email protected]; 'Vipin Malik'
Cc: [email protected]
Subject: Re: JFFS2 as root FS

Hallo!

Did you try to mount the flash again under linux? We had a problem with the endianess some time ago and run into the same trouble as you did. Mounting took a long time and after that the flash was completely empty. Files cound be moved onto it, but as soon as you re-mounted the flash it was empty again. Try if this happens to you too.

I know its a wild guess but maybe it helps!

Happy hacking
Florian

To unsubscribe, send "unsubscribe mtd" to [email protected]

That's very very slow. I don't know why it's being so slow for you.

Your CPU isn't particularly fast, but that shouldn't really make _that_ much difference.

Can you set CONFIG_JFFS2_FS_DEBUG=1 and set default_loglevel to 8 in kernel/ printk.c, then log the messages that it produces? I'd like to see if anything untoward is happening.

If it's really just being slow, then maybe you're going to need one or two of the features on the wishlist implemented - checkpointing and prepopulating inodes on mount.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

Maybe the flash access timing is awfully slow? Default values for such things are often the slowest.

Nicolas

To unsubscribe, send "unsubscribe mtd" to [email protected]

Just for reference, my AMD SC520 -100MHz (a 100MHz 486+) with a 8MB, 57% full JFFS2 f/s takes ~19 seconds to mount.
The flash is connected on a 32bit bus. Even if it takes 700us (for max wait states on my system) per quad word read (32bits), the entire flash can be read in 1.46 seconds.

Even if your flash is connected x8 wide, your flash read times should not be more than 10-12seconds.

Obviously, as my flash read time is only ~2 seconds of my 19s fs mount time, the processor speed plays quite a significant role in the mount process.

To test this theory, I upped the speed to 133MHz and then it took ~15seconds to mount.
The increase in clock speed was 33%, the mount was (19-15)/15 = 26% faster. However, if I remove the "constant" portion of the two mounts- the flash read which is not any faster, then the increase in
mount speed = ((19-1.46) - (15-1.46))/ (15 - 1.46) = 29.5% faster, almost linear with the increase with clock speed!
(This also tells me that the code is executing primarily out of cache).

If you say, that your system takes ~90seconds to mount. Let's say that your flash read time is ~10 seconds (for 16MB), then if all else is ok, your processor should be ~80/17.5 = 4.5 times slower than mine. This assumes equal amount of processing. But your processor is doing about (6580/4636 = 140%) more
processing than mine. Assuming linear overhead, then the new factor is ~57/18 = 3.1X slower. (your flash usage is 6580 blocks, mine is 4636 blocks).

Now you say that you are using a MPC869T. I did not find a 869T on the web. I presume that you meant 860T. At what MHz?

The 860T is claimed to have a performance of ~66 Dhrystone MIPS at 50MHz. I downloaded Dhrystone 2.1 and that give me 51 mips at 100Mhz (and 67.7at 133MHz).

However, my 486 has a 16KB combined cache and a 66MHz SDRAM bus. The FLASH is not cached, so the entire cache can be used for the instruction execution. The 860T has only 4KB of instruction cache. Under some circumstances (when the code fits in the cache in my processor and not in yours), the SC520 will behave like a 100MHz machine while the PPC will be limited to the bus clock speed. What is you bus clock speed (and your core clock speed).

If your BUS clock is ~25-33 MHz, it's not unbelievable that your processor runs ~2-3X slower, specially if your processor core is running at <50MHz. Also remember that execution from cache is significantly faster than execution from EDO DRAM on the bus.

Something to think about. Of course it could be something completely different, like a bug in David's code ;)

Vipin

To unsubscribe, send "unsubscribe mtd" to [email protected]

Wow, that was an impressive analysis!

Regarding my HW, it is a PPC860T and it is running at 50MHz(48 to be exact since the ext. clock is 8MHz
and the multiplier 6). The bus is supposed to run at the same speed, 48 MHz,(how do I check that?)
The Flash is on a 32 bit bus(4 in x8 mode), erase sector is 256KB.

hmm, mounting my fs should be quicker than 90 seconds.

Jocke

----- Original Message -----
From: "Vipin Malik" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; "Nicolas Pitre" <[email protected]>; "David Woodhouse" <[email protected]>
Sent: den 19 april 2001 18:44
Subject: Re: JFFS2 as root FS

I

full

wait

be

time,

~15seconds

faster.

read

your

~57/18

web. I

I

is

will

clock

To unsubscribe, send "unsubscribe mtd" to [email protected]