Getting JFFS2 to work on Linux 2.4.X

Dec 08, 2005 8 Replies

I am running Linux 2.4.X on my embedded ARM XSCALE 420 processor board. I am trying to get JFFS2 configured, but so far it seems that the code does not sense the flash sectors that are free. I use Redboot to boot my Linux. I am using a single IntelE28F320 flash device on the board and it is mapped into the system memory space. This is a 16 bit device.



Below is the dump of my boot log and my Linux config options. Any tips is appreciated!



Thanks


Trying NPE-B...success. Using NPE-B with PHY 17. Ethernet eth0: MAC address 00:20:4a:ff:ff:15 IP: 192.168.1.222/255.255.255.0, Gateway: 192.168.1.1 Default server: 192.168.1.100



RedBoot(tm) bootstrap and debug environment [ROM] Red Hat certified release, version 2.01 - built 21:29:30, Oct 3 2005



Platform: Company (XScale) BE Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.



RAM: 0x00000000-0x01000000, [0x000219f0-0x00fc1000] available FLASH: 0x50000000 - 0x50400000, 32 blocks of 0x00020000 bytes each. == Executing boot script in 2.000 seconds - enter ^C to abort RedBoot> fis load zImage RedBoot> fis load ramdisk RedBoot> go -n 0xc00000 Uncompressing Linux............................................ done, booting the kernel.



Linux version 2.4.27-uc1 (foo@localhost) (gcc version 3.3.2) #1 Sat Nov



26 20:49:33 PST 2005

CPU: XScale-IXP4xx/IXC11xx revision 1



Machine: Intel IXDP425 Development Platform



Warning: bad configuration page, trying to continue



alloc_bootmem_low



memtable_init



On node 0 totalpages: 4096



zone(0): 4096 pages.



zone(1): 0 pages.



zone(2): 0 pages.



Kernel command line: console=ttyS0,115200 root=/dev/ram0 initrd=0x00200000,4M mem=16M@0x00000000



Calibrating delay loop... 266.24 BogoMIPS



Memory: 16MB = 16MB total



Memory: 10616KB available (1153K code, 239K data, 64K init)



Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)



Inode cache hash table entries: 1024 (order: 1, 8192 bytes)



Mount cache hash table entries: 512 (order: 0, 4096 bytes)



Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)



Page-cache hash table entries: 4096 (order: 2, 16384 bytes)



POSIX conformance testing by UNIFIX



Linux NET4.0 for Linux 2.4



Based upon Swansea University Computer Society NET3.039



Initializing RT netlink socket



Starting kswapd



JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.



pty: 256 Unix98 ptys configured



Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled



ttyS00 at 0xff000003 (irq = 15) is a XScale UART



ttyS01 at 0xff001003 (irq = 13) is a XScale UART



ttyS02 at 0xf1000003 (irq = 6) is a TI16750



ttyS03 at 0xf2000003 (irq = 6) is a TI16750



RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize



cfi_cmdset_0001: Erase suspend on write enabled



Using buffer write method



Creating 5 MTD partitions on "IXP425 Flash":


0x00000000-0x00040000 : "RedBoot"


0x00040000-0x000e0000 : "zImage"


0x000e0000-0x002e0000 : "ramdisk"


0x003e0000-0x003ff000 : "FIS directory"



mtd: partition "FIS directory" doesn't end on an erase block -- force read-only


0x003ff000-0x00400000 : "RedBoot config"

mtd: partition "RedBoot config" doesn't start on an erase block boundary -- force read-only



NET4: Linux TCP/IP 1.0 for NET4.0



IP Protocols: ICMP, UDP, TCP



IP: routing cache hash table of 512 buckets, 4Kbytes



TCP: Hash tables configured (established 1024 bind 2048)



NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.



NetWinder Floating Point Emulator V0.97 (double precision)



RAMDISK: Compressed image found at block 0



Freeing initrd memory: 4096K



VFS: Mounted root (ext2 filesystem) readonly.



Freeing init memory: 64K



Using /lib/modules/2.4.27-uc1/kernel/drivers/ixp400/ixp400.o Module init.



Using /lib/modules/2.4.27-uc1/kernel/drivers/net/ixp425_eth.o ixp425_eth:



Initializing IXP425 NPE Ethernet driver software v. 1.1



ixp425_eth: CPU clock speed (approx) = 0 MHz



[error] ixEthMiiPhyScan : unexpected Mii PHY ID 00221619

ixp425_eth: ixp0 is using the PHY at address 17 Welcome to ____ _ _ / __| ||_| _ _| | | | _ ____ _ _ _ _ | | | | | | || | _ \| | | |\ \/ / | |_| | |__| || | | | | |_| |/ \ | ___\____|_||_|_| |_|\____|\_/\_/ | | |_|



For further information check:

formatting link



Intel(R) IXP400 Access Library v1.4 Integrated



formatting link


# .



@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@



CONFIG_MTD_CFI=y CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=m CONFIG_MTD_REDBOOT_PARTS=y CONFIG_JFFS2_FS=y



Two rather serious problems. Firstly, JFFS2 probably won't work on a 4MB flash device. You've partitioned your one too so it will almost certainly not go.

Secondly, your partition table is crap. The 28F320 device is 4MB and has

128K erase sectors. One of your partitions is a weird size (0x1F000). Partitions need to be a multiple of 0x20000.

Uhm, why? Because of the size? I have jffs2 running just fine on a 64kByte NVRAM chip.

Regards, ae

The OP may be running out of free RAM: JFFS and JFFS2 create largish data structures in RAM to administer the files on Flash.

Tauno Voipio tauno voipio (at) iki fi

I thought I read on the MTD list some time ago that JFFS2 will not work very well on devices less than a certain size, but I just tried it on a

3MB MTD partition and found that it does seem to work fine, although it consumes 24% as overhead.

That sounds like a strange thing to do since JFFS2 reserves erase blocks, although I do not know how it would operate on an NVRAM device.

Any particular reason why you did not use PRAMFS ?

Ignorance ;-) I didn't know it existed. Thanks.

It does not seem to be included in the kernel, yet. At least it's not supported in the 2.6.12-uc0 that shipped with my snapgear-3.3.0.

They might be more reasons: I skimmed through the pramfs "Technical Specification" page - it seems this thing is not mounted on any block or mtd device, but has to be memory-mapped. My NVRAM is on the XScale's expansion bus - it might be not straightforward to use (eg. need to mmap() and to configure the expansion bus - how when there's no device, hence no driver?).

Anybody here using this? Is it stable enough for production?

Regards, ae

It was submitted for inclusion a while ago, though I'm surprised it hasn't made it there yet.

mmap() doesn't look like it will be an option if the device is not memory mapped ?

A good reason to use it is execute-in-place and low RAM overhead.

I mistyped (posting at 1:30AM is not a good idea), I meant ioremap() - to access the bus I need to ioremap() and then use writeb() and readb(). I am afraid I'd need to hack the PRAMFS code to make this work. Am I right?

ae

I'm afraid I don't know much about the code itself, I've never needed to hack it.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required