bbram access problems

bbram access problems

[Geoffroy Stevenne]

Hi,

We're trying to use BBRAM on a VersaLogic VSBC-6 m-b.  We use the slram
driver and the 2.4.18 kernel.  The problem is that we can't acces the
entire memory of the BBRAM, just the first 64k page.

Other problem: we added to our lilo.conf:

append="slram=BBRAM,0xE0000,+0x10000"

We can write to the BBRAM but we noticed data corruption (not write
operation was done) in this address range.  Is there a way to lock this
memory area?  Is this the right thing to do?

What we need is to mount a filesystem on the entire BBRAM, not just the
first 64k. I can (and wish to) provide more information, test changes,
report bugs, etc. I can read and understand C code but I don't feel
competent in writing drivers on my own.

Thanks for your help,

--
Geoffroy Stévenne
Hellea SPRL

Re: bbram access problems

[Jörn Engel]

On Thu, 12 December 2002 14:05:46 +0100, Geoffroy Stevenne wrote:
> 
> We're trying to use BBRAM on a VersaLogic VSBC-6 m-b.  We use the slram
> driver and the 2.4.18 kernel.  The problem is that we can't acces the
> entire memory of the BBRAM, just the first 64k page.
                                             ^^^
> 
> Other problem: we added to our lilo.conf:
> 
> append="slram=BBRAM,0xE0000,+0x10000"
                              ^^^^^^^^
If you can read hex, you will notice that you told slram to map 64k.
Change the append line in your /etc/lilo.conf.

> We can write to the BBRAM but we noticed data corruption (not write
> operation was done) in this address range.  Is there a way to lock this
> memory area?  Is this the right thing to do?

> append="slram=BBRAM,0xE0000,+0x10000"
                      ^^^^^^^
slram took memory from the first Megabyte. Is this correct? Does you
machine have only 896k of memory plus the bbram? I doubt it. ;-)

> What we need is to mount a filesystem on the entire BBRAM, not just the
> first 64k. I can (and wish to) provide more information, test changes,
> report bugs, etc. I can read and understand C code but I don't feel
> competent in writing drivers on my own.

Figure out, how much memory you have, how much bbram and where the
bbram starts in the address range. Then you can come back or - better
yet - read up what the "slram=" and "mem=" parameters do.
Understanding the problem beats having it solved by someone else. :-)

Jörn

-- 
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then  CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source

Re: bbram access problems

[Tobias Otto-Adamczak]

Hi Geoffroy,

> We're trying to use BBRAM on a VersaLogic VSBC-6 m-b.  We use the slram
> driver and the 2.4.18 kernel.  The problem is that we can't acces the
> entire memory of the BBRAM, just the first 64k page.

Where do you know ?

[I just had a quick look into the VSBC-6 manual, for curiosity]
Do you have r/w access to the "Map and Paging Control Register"  where
BBRAM pages are selected ?

> Other problem: we added to our lilo.conf:
> append="slram=BBRAM,0xE0000,+0x10000"

looks okay.

> We can write to the BBRAM but we noticed data corruption (not write
> operation was done) in this address range.  Is there a way to lock this
> memory area?  Is this the right thing to do?

Locking would be an useful idea if you suspect that other processes try
to access it, too. Is this the case ?

> What we need is to mount a filesystem on the entire BBRAM, not just the
> first 64k.

The standard slram driver does only work with a contiguous region of
ram. But you have only a ram window and a some page select bits in an
I/O register. You have to hack the driver code (slram.c), I think. (I am
no expert.)

Regards
Tobias

Re: bbram access problems

[Tobias Otto-Adamczak]

Jörn Engel, 2002-12-12, 14:45h:

> > We're trying to use BBRAM on a VersaLogic VSBC-6 m-b.  We use the slram
> > driver and the 2.4.18 kernel.  The problem is that we can't acces the
> > entire memory of the BBRAM, just the first 64k page.
>                                              ^^^
> >
> > Other problem: we added to our lilo.conf:
> >
> > append="slram=BBRAM,0xE0000,+0x10000"
>                               ^^^^^^^^
> If you can read hex, you will notice that you told slram to map 64k.
> Change the append line in your /etc/lilo.conf.

I think its correct because that BBRAM (how much is it, anyway ?) is
mapped page-wise into the physical memory space from 0xE0000 - 0xEFFFF
and you have to select pages if you want to access more than the first
64KB.

> > append="slram=BBRAM,0xE0000,+0x10000"
>                       ^^^^^^^
> slram took memory from the first Megabyte. Is this correct? Does you
> machine have only 896k of memory plus the bbram? I doubt it. ;-)

According to the manual, that address looks fine. Geoffroy, it also says
"CMOS setup is used to choose between DRAM and PC/104 for three sections
of memory from 0C0000h to 0EFFFFh." (p.52) Did you do the right settings
?

> Figure out, how much memory you have, how much bbram and where the
> bbram starts in the address range. Then you can come back or - better
> yet - read up what the "slram=" and "mem=" parameters do.
> Understanding the problem beats having it solved by someone else. :-)

Other question: does the slram driver map this area in when it is
already covered by the kernel ?

Regards
Tobias

Re: bbram access problems

[Thomas Gleixner]

On Thursday 12 December 2002 14:05, Geoffroy Stevenne wrote:
> Hi,
>
> We're trying to use BBRAM on a VersaLogic VSBC-6 m-b.  We use the slram
> driver and the 2.4.18 kernel.  The problem is that we can't acces the
> entire memory of the BBRAM, just the first 64k page.
>
> Other problem: we added to our lilo.conf:
>
> append="slram=BBRAM,0xE0000,+0x10000"
>
> We can write to the BBRAM but we noticed data corruption (not write
> operation was done) in this address range.  Is there a way to lock this
> memory area?  Is this the right thing to do?
>
> What we need is to mount a filesystem on the entire BBRAM, not just the
> first 64k. I can (and wish to) provide more information, test changes,
> report bugs, etc. I can read and understand C code but I don't feel
> competent in writing drivers on my own.

from slram.c
NOTE:
  With slram it's only possible to map a contigous memory region. 

So you can't access it with slram, as the BBSRAM is a device with paged 
access. All you have to do, is copy slram.c to bbram.c and add an additional 
parameter, which tells the driver the number of pages.available. Then modify 
the erase / read / write functions to do the page selection depending on the 
address you have to access. 
If you think this is out of your league, then hope, that somebody does this 
for you sometimes, or ask one of the experts to help you for a little fee 
immidiately :)

-- 
Thomas
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: bbram access problems

[Jörn Engel]

On Thu, 12 December 2002 15:09:11 +0100, Tobias Otto-Adamczak wrote:
> [joern's ignorance of braindead pc hardware removed]
> 
> Other question: does the slram driver map this area in when it is
> already covered by the kernel ?

To my knowledge, yes. The driver is unaware of linux memory management
and simply ioremaps physical memory. If the kernel already uses this
area, you are in trouble.
But I think to remember that for i386 architecture the first 1MB of
memory has special treatment. Might be worth a look.

Jörn

-- 
Fantasy is more important than knowlegde. Knowlegde is limited,
while fantasy embraces the whole world.
-- Albert Einstein

Re: bbram access problems

[Geoffroy Stevenne]

Le Thu, 12 Dec 2002 15:40:43 +0100
Thomas Gleixner <tglx@linutronix.de> a écrit:

 
> from slram.c
> NOTE:
>   With slram it's only possible to map a contigous memory region. 
> 
> So you can't access it with slram, as the BBSRAM is a device with
> paged access. All you have to do, is copy slram.c to bbram.c and add
> an additional parameter, which tells the driver the number of
> pages.available. Then modify the erase / read / write functions to do
> the page selection depending on the address you have to access. 
> If you think this is out of your league, then hope, that somebody does
> this for you sometimes, or ask one of the experts to help you for a
> little fee immidiately :)
> 

We should be able to do this.  Thanks for your suggestions and stay
tuned for more feedback!

Thanks,

Geof

Re: bbram access problems

[Geoffroy Stevenne]

Le Thu, 12 Dec 2002 15:40:43 +0100
Thomas Gleixner <tglx@linutronix.de> a écrit:

> from slram.c
> NOTE:
>   With slram it's only possible to map a contigous memory region. 
> 
> So you can't access it with slram, as the BBSRAM is a device with
> paged access. All you have to do, is copy slram.c to bbram.c and add
> an additional parameter, which tells the driver the number of
> pages.available. Then modify the erase / read / write functions to do
> the page selection depending on the address you have to access. 
> If you think this is out of your league, then hope, that somebody does
> this for you sometimes, or ask one of the experts to help you for a
> little fee immidiately :)

Thanks to all! We will code... but I still can't figure how to prevent
other processes to access this memory area.  IANAE on memory locking and
stuff like that, nor in kernel programming in general.

I'll learn :-)

--
Geoffroy