Getting JFFS2 to work on Linux 2.4.X

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

Reply to
dchou4u
Loading thread data ...

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.
Reply to
Geronimo W. Christ Esq

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

Regards, ae

Reply to
Andrzej Ekiert

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
Reply to
Tauno Voipio

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 ?

Reply to
Geronimo W. Christ Esq

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

Reply to
Andrzej Ekiert

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.

Reply to
Geronimo W. Christ Esq

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

Reply to
Andrzej Ekiert

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

Reply to
Geronimo W. Christ Esq

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.