BBRAM

BBRAM

[Richard Brunelle]

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

Re: BBRAM

[Jörn Engel]

On Tue, 19 November 2002 13:12:56 -0500, Richard Brunelle wrote:
> 
> 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/?

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

Re: BBRAM

[Richard Brunelle]

Thanks for you hints.

Two more questions:

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


Richard Brunelle


Jörn Engel wrote:

>On Tue, 19 November 2002 13:12:56 -0500, Richard Brunelle wrote:
>  
>
>>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/?
>>    
>>
>
>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
>
>  
>

Re: BBRAM

[Jörn Engel]

On Tue, 19 November 2002 14:40:19 -0500, Richard Brunelle wrote:
> 
> -How the parameters to SLRAM are passed?

This depends on your boot loader. For lilo, you can put this into
/etc/lilo.conf:
	append="slram=bbram,exe0000,+0x8000"

> -Is there any provision for pageable memory?

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

(no subject)

[Taeil Um]

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?

Re: (no subject)

[David Woodhouse]

tium@mail.palmpalm.com said:
> raw unchecked node of size 0x64034000 freed from erase block 13 at
> 0x000340c0, but un0 

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

RE: (no subject)

[Taeil Um]

David Woodhouse said:

> 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?

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