BBRAM

Hi, I have a question concerning a BBRAM from ST, the M48Z512A.

I'm using the BBRAM mapped at 0xE0000 on a single board computer from VersaLogic. This BBRAM is pageable through access of a special register on the single board computer. I want to map the BBRAM as part of the file system.

As I understand MTD is appropriate for this purpose, am I right?

If yes, what are the options in the kernel configuration I need to enable to let the system access the device?

My guess is CONFIG_MTD_MTDRAM with the appropriate position set to 0xE0000. In this case, what type of device should I see in /dev/?

Thanks.

Richard Brunelle

I've been quite happy with the slram driver. The following options should be enough:
CONFIG_MTD
CONFIG_MTD_CHAR
CONFIG_MTD_BLOCK
CONFIG_MTD_SLRAM

In the case of a monolithic kernel, you have to append something like this:
slram=BBRAM,0xE0000,+0x8000
First parameter is the device name, second is the device start, third is the device end or device length (length starts with +).

You have to make sure that the vm doesn't claim the same memory, though. Maybe you also need something like mem=8M.

David, there is some Documentation floating around, but not in /usr/src/linux/Documentation, where most people would expect it. What would I have to do to change that? Commit to cvs? Bitkeeper tree? Patch to you/Linus/Marcelo?

Jörn

The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown

Thanks for you hints.

Two more questions:

-How the parameters to SLRAM are passed?
-Is there any provision for pageable memory?

Richard Brunelle

This depends on your boot loader. For lilo, you can put this into /etc/lilo.conf:

	append="slram=bbram,exe0000,+0x8000"

No, none. The slram driver needs absolute control over the memory area, it uses. If the kernel mm code also uses it, e.g. hands it out on kmalloc() calls, you're screwed.

Jörn

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

Hi All !
I recently ported JFFS2-MTD-NAND with samsung 16bit NAND flash. it woks well except power fail case.

i turned it off while writing on NAND flash. and i found my board died with a bellow "Kernel OOPS"

------------kernel oops------------------------------------------------------------------------------------------------------------- raw unchecked node of size 0x64034000 freed from erase block 13 at 0x000340c0, but un0

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0514000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: ffffffff
CPU: 0
pc : [<c009e49c>]    lr : [<c003e3d8>]    Not tainted

sp : c1cffc58 ip : c1cffc04 fp : c1cffca0
r10: c07f5488 r9 : 003d1600 r8 : 00000000
r7 : c063ffff r6 : c1c2f8cc r5 : c0650270 r4 : 0000000d r3 : c015f4c0 r2 : 00000001 r1 : 00000001 r0 : 0000007c
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 217F Table: C0514015 DAC: 00000015

Backtrace: 

Function entered at [<c009e3e8>] from [<c009c180>]
r8 = C021FD20 r7 = C1C2F8CC r6 = C1C2F8CC r5 = C021FD20 r4 = C0005E64
Function entered at [<c009c0e4>] from [<c00a2c84>]
r6 = C0652DC0 r5 = C0680C58 r4 = C0635350
---------------------------------------------------------------------------------------------------------------------------------------------
The "Kernel OOPS" may related to "jffs2_mark_node_obsolete" function.

Anybody did have same experience?

Your output is corrupted.

Please reproduce with CONFIG_JFFS2_FS_DEBUG=1 and show the messages from the beginning of the mount.

What's on the flash at offset 0x340c0? Not a node of length 0x64034000 and with a valid CRC32 in the header, I'll bet. What compiler are you using?

--
dwmw2

Yes You'are right!
And i found it was my fault.
When i change "nand.c" code for support 16bit NAND FLASH memory, i had a mistake. and it was the reason of previous KERNEL OOPS!.

Thanks a lot for your concerns!

-------
tium