[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bypassing the MMU on the lx chip




I tried using read/write/seeks but I can't seen to do a seek over to the
sram bank @ 0x0800 0000

Is there something else I must do to build the kernel to have mtd access @
0x0800 0000?




                                                                                            
                    Bjorn Wesen                                                             
                    <bjorn.wesen@xxxxxxx.com>             
                    axis.com>            cc:     dev-etrax@xxxxxxx.com                         
                                         Subject:     Re: bypassing the MMU on the lx chip  
                    05/15/01                                                                
                    03:59 PM                                                                
                                                                                            
                                                                                            




On Tue, 15 May 2001, Adam Felson wrote:
> I would want to access it from user mode, running a ramdisk on the 128K
> SRAM would be acceptable.
>
> I noticed several RAM items in the MTD kernel config such as "support for
> ram chips in bus mapping".
> I turned all of them on to play and now see 'mtd3: 02000000 00010000 "Raw
> memory"' in /proc/mtd.
> Does that correspond to /dev/cflash3?   Is it a usable way to access the
> SRAM?

I don't know off-hand what major/minors MTD use or what mtd3 is mapped to,
but yes, you should be able to open and mmap the device node corresponding
to your SRAM and use it from user-mode.

Possibly the device nodes don't exist in the /dev directory per default on
the devboard software - if so you need to figure out the major/minor
numbers and make a node yourself. What you call it is up to you but mtd3
sounds logical doesn't it.

Yes, cflash0 etc. should really be called mtd0, mtd1 etc. I guess, but we
didn't use mtd with our 2.0 port and we wanted to keep the names. It does
not stop aliases existing with the /dev/mtd name structure though

/BW