Hello,
 
Does YAFFS2 work on boards which use HIGHMEM? I have a PowerPC board
that comes in 1G and 2G variants. YAFFS works just fine on the 1G board
and works just fine on the 2G board if I boot with mem=1G (HIGHMEM
starts above 1G on this board). Everything but YAFFS work just fine on
the 2G board when the full 2G is used, so there isn't a HIGHMEM issue on
the board. 

YAFFS works well enough on these boards to allow using a root file
system on NAND. However, when I try a simple write to a YAFFS partition
on a 2G board configured to use the full 2G, I get the following crash.
I don't seem to be the only one with this issue. My board is based on a
dual-core 8641D PowerPC. Mathias Fuchs reported exactly the same problem
on a 1G 44O board. The posting can be found with a google search for the
item "HIGHMEM on 440EPx board with 1GB of RAM".  On Matthias' board
HIGHMEM started at 768M. When Matthias reconfigured his kernel so that
he could use the full 1G as low memory, his YAFFS problems went away.
 

# mount -t yaffs2 /dev/mtdblock4 /mnt
# cd /mnt
# cp -a /etc .

------------[ cut here ]------------
Kernel BUG at 8013cd0c [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1] 
PREEMPT SMP NR_CPUS=2 
Modules linked in:
NIP: 8013CD0C LR: 8013CD0C CTR: 8003E24C
REGS: 8fb53a00 TRAP: 0700   Not tainted  (2.6.20)
MSR: 00029032 <EE,ME,IR,DR>  CR: 24422428  XER: 00000000 
TASK = 842652d0[626] 'cp' THREAD: 8fb52000 CPU: 0
GPR00: 8013CD0C 8FB53AB0 842652D0 00000012 6419EFF8 F0266C8C 3F664DCF
00000000
GPR08: 00000610 00000000 10000000 8FB52000 38526268 10024A08 80400000
00001000
GPR16: BD37E368 8FB53C38 8FB53C3C 00000000 00000000 00000000 8FB53BC0
00000000
GPR24: 00000000 00000001 00000000 84272980 00000000 004C2000 8FB53BC0
BD318000 
NIP [8013CD0C] nandmtd2_WriteChunkWithTagsToNAND+0xe8/0xf0
LR [8013CD0C] nandmtd2_WriteChunkWithTagsToNAND+0xe8/0xf0
Call Trace:
[8FB53AB0] [8013CD0C] nandmtd2_WriteChunkWithTagsToNAND+0xe8/0xf0
(unreliable) 
[8FB53B10] [8013ACDC] yaffs_WriteChunkWithTagsToNAND+0x90/0x140
[8FB53B30] [80133C64] yaffs_WriteNewChunkWithTagsToNAND+0x3d4/0x538
[8FB53B70] [80135BE0] yaffs_WriteChunkDataToObject+0x94/0xe8
[8FB53C30] [80136304] yaffs_WriteDataToFile+0x214/0x2e0 
[8FB53C90] [8012FE04] yaffs_commit_write+0x120/0x2bc 
[8FB53CD0] [800513D8] generic_file_buffered_write+0x3cc/0xa2c
[8FB53D90] [80052E48] __generic_file_aio_write_nolock+0x314/0x5bc
[8FB53E00] [80053158] generic_file_aio_write+0x68/0x10c 
[8FB53E30] [80078F88] do_sync_write+0xc0/0x134 
[8FB53EF0] [80079628] vfs_write+0xf4/0x1bc 
[8FB53F10] [8007A210] sys_write+0x4c/0x90 
[8FB53F40] [80011458] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff69874
    LR = 0x10008670
Instruction dump:
80010064 38210060 7c0803a6 4e800020 3c608038 386378bc 4bee9125 0fe00000
48000000 3c608038 38637908 4bee9111 <0fe00000> 48000000 7c0802a6
9421ff90 



Some other info:

-- part of boot log

Creating 4 MTD partitions on "mvme7100-flash":
0x00000000-0x01000000 : "Linux Kernel + INITRD"
0x01000000-0x07e00000 : "Linux JFFS2 Filesystem"
0x07e00000-0x07f00000 : "Bootloader Block B"
0x07f00000-0x08000000 : "Bootloader Block A"
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd5 (Samsung NAND 4GiB
3,3V 8-bit) 
Scanning device for bad blocks 
Using static partition definition 
Creating 2 MTD partitions on "mvme7100-nand":
0x00000000-0x40000000 : "Linux"
0x40000000-0x80000000 : "Linux"


# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 01000000 00040000 "Linux Kernel + INITRD"
mtd1: 06e00000 00040000 "Linux JFFS2 Filesystem"
mtd2: 00100000 00040000 "Bootloader Block B"
mtd3: 00100000 00040000 "Bootloader Block A"
mtd4: 40000000 00040000 "Linux"
mtd5: 40000000 00040000 "Linux"

Partitions mtd0->mtd3 are in NOR flash. Partitions mtd4 and mtd5 are in
NAND flash.

The flash part is Samsung K9KAG08U0M SLC flash. We use 4G and 8G
variants. 
I have also had exactly the same problem using Samsung K9LBG08U0M MLC
flash 
in 8G and 16G variants (no surprise). These flash parts have a 4K page
size 
and 128 byte spare area.

I have these problems using a Linux 2.6.20 kernel with a YAFFS snapshot
from 
8/15/2008, and also from another snapshot from sometime ago - yaffs
versions below.

cat /proc/yaffs
YAFFS built:Aug 19 2008 10:45:21
$Id: yaffs_fs.c,v 1.63 2007/09/19 20:35:40 imcd Exp $
$Id: yaffs_guts.c,v 1.52 2007/10/16 00:45:05 charles Exp $

Any ideas on how I can fix this problem would be appreciated.

Thanks,

ap