Re: Re: u-boot & uImage on M5282LITE

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information 
X-SpamDetect: ****: 4.612000 No experience needed!=1.0, X-Verify-SMTP present=0.6, Aspam=3.0
X-SpamDetect-Info: ------------- End ASpam results -----------------

Hi Allon,

Thanks as always for your quick reply!

On Tue, 1 Apr 2008 11:25:02 -0400
Allon Stern <[email protected]> wrote:

> 
> On Apr 1, 2008, at 12:18 AM, Loren A. Linden Levy wrote:
> 
> > Sorry guys I am having a really hard time figuring out where to start
> > attacking this problem. I have a generic character driver that is in
> > my uClinux image now but I don't really know where/how to attach to
> > the FPGA. In the RTOS code we seem to be using chip selects like:
> >
> > MCF5282_CS1_CSAR = 0x3000; /* set the base address 0x3000,0000 */ >
> > MCF5282_CS1_CSCR = MCF5282_CS_CSCR_PS_32 | MCF5282_CS_CSCR_AA |  
> > MCF5282_CS\ _CSCR_WS(0xF);
> >
> > Which by looking at the MCF programmers manual I think is a
> > description of a new chip select (CS1) address register and control
> > register. I just don't really have a clue how this translates into
> > something in uClinux. Thanks again for all your help.
> 
> I'm getting close to this point myself.
> 
> First let me state that I have no experience (yet) with doing this on  
> the coldfire. My explanation here may be flawed - I'm still figuring  
> this out myself on this chip. I have done simiar things on the OMAP,  
> so I draw from that.
> 
> How to attach to the FPGA? Where is it in memory? Where do you want  
> it? Which chip select does it use?
> Ever done this sort of thing before?

Never done this sort of thing before...but sort of know where I want
it etc.

> Each memory-mapped device on the bus shares the same address/data  
> lines. Not all of the address lines go through - this saves on lots  
> of lines that would otherwise be ignored in 99% of uses. Instead, the  
> CPU asserts a chip-select line whenever you are accessing the memory  
> range occupied by the device. Some devices have programmable chip- 
> selects, others, you have to use the memory range tied to a specific  
> chip select. This chip select then goes to the address decode logic  
> of the device on the bus, to let it know when it is being accessed.
> 
> Looks like you're using CS1, at least in the example above.

Right I want to use CS1 and CS2.

> Chapter 12 of the MCF5282 manual describes the chip select registers  
> (I'm referring to MCF5282UM Rev 2.3)

I found this manual as well and it is starting to make some sense.

> The CF allows you to set the base address and size of a device on a  
> chip-select.

Right. Question here in my device driver if I set CSAR2=0x3001 as my
base address which space in memory do I want to use check_mem_region()
on to make sure I can grab that space.

> when you initialize your driver, or better yet - when you initialize  
> your hardware in your boot loader or kernel, you can configure the  
> chip selects for your device.

Why better in boot loader? My driver gets loaded at boot time for my
linux kernel. I run the fpga_init code from the driver in mem.c in
char drivers.
 
> So, let's say you use the example above.
> CSAR1 is being set to 0x3000. Pg 12-6 of the UM states "Base address.  
> Defines the base address for memory dedicated to chip select CS[1].  
> BA (base address) is compared to bits 31-16 on the internal address  
> bus to determine if chip select memory is being accessed."
> 
> This means that when your code accesses memory in the range  
> 0x3000nnnn, then the CPU asserts CS1 during the bus cycle. This  
> causes the chip with CS1 wired to it's chip-enable input to be selected.
> 
> You can further modify this with CSMR1. Setting up CSMR1 allows you  
> to mask address bits - you can use this to make the chip selected for  
> a larger address space than 16 bits. For example, if you set CSMR1  
> bits 31-16 to 0x00FF, then you've just asked for CS1 to be asserted   
> for accesses in the range 0x30nnnnnn.
> 
> CSMR1's low bits also let you set write-protection on the range, or  
> DMA stuff, or memory protection stuff (I think), or most importantly,  
> whether the whole chip select configuration (CSAR, CSMR, CSCR) is  
> valid or not. The chip select you have set up won't be asserted  
> unless you set the valid bit (0) in CSMR1.

Wow you should have been in charge of writing the manual.

> You now have the memory location set up. Great.
> 
> But each device on the memory bus may have different timing  
> requirements. That's what CSCR is for. This register lets you set the  
> number of wait states, auto-acknowledge, port size (8, 16, 32 bit  
> data width), byte enable, etc. Whoever programmed the FPGA should be  
> able to answer any questions on how this register should be set. If  
> that person is you, then I think you need to sit down with yourself.  
> Have a beer - you're more likely to talk freely that way.

Sorry I left out the CSCR in my previous mail I have it set too.
Actually it is not, I'm calling him today ;).

> To reiterate, there are THREE (not two, as you give in the example  
> above) registers which control the way the memory bus works for each  
> chip select --
> CSAR - controls what address range will assert CS when accessed
> CSMR - further refines the address range, and controls a few other  
> access things
> CSCR - controls the memory timings for that CS.
> 
> Got it?

Yep.

 
> I hope this helps you. It helped me figure out what I need to do next :)




-- 
 -- 
---------------------------------------------
Loren A. Linden Levy
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: [email protected]
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH8mcllZX6YS+3ZksRAsZVAJ9b8m4QTAwZn0Fi9gl+svQe22P17ACggmm/
vYS/vdo+7hP980oCtzS/wiI=
=1FsD
-----END PGP SIGNATURE-----