Re: Re: u-boot & uImage on M5282LITE

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.

On Tue, 04 Mar 2008 10:34:34 +1000
Greg Ungerer <[email protected]> wrote:

> Hi Allon,
> 
> Allon Stern wrote:
> > On Feb 27, 2008, at 5:52 PM, Loren A. Linden Levy wrote:
> >> Hi Allon et. al,
> >> So we are planning on using this board as a clock and slow controller
> >> for a new detector in our experiment. I need to be able to talk to an
> >> FPGA on the board that this will be connected to set thresholds
> >> etc. Is there a way to do this in uClinux, I have an example in RTOS
> >> Quadros, so I think I know what the memory addresses are. Thanks for
> >> any input and or references.
> >>
> >> Alex
> > 
> > Almost certainly.
> > You'll probably want to write a device driver to expose the 
> > functionality of your FPGA to the uClinux world.
> > I just managed to get interrupts working on my board. It's important to 
> > note that the IRQ lines broken out on the board are NOT what I would 
> > have expected; they're actually GPIOs that can be set up as level or 
> > edge triggered IRQs using the EPORT module.
> > 
> > And you have to unmask the interrupt in the interrupt controller 
> > registers as well. Why this isn't done when you register an IRQ in linux 
> > I have no idea. Anyone with more knowledge, please speak up :)
> 
> The one sticking point I had in the early days was handling
> the auto-vectored interrupts that some devices on M68k/ColdFire
> use. So where you program the device with the vector it will
> use (in other words it is completely software settable).
> 
> It is probably the case we could handle this more easily now
> with appropriate request_irq() flags, but I haven't revisited
> this recently.
> 
> Regards
> Greg
> 
> 
> 
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Dude       EMAIL:     [email protected]
> Secure Computing Corporation                PHONE:       +61 7 3435 2888
> 825 Stanley St,                             FAX:         +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
> ---
> [email protected]              Send a post to the list.
> [email protected]        Join the list.
> [email protected]    Join the list in digest mode.
> [email protected]     Leave the list.
> 


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

iD8DBQFH8beDlZX6YS+3ZksRAvqAAJ9YWcwkA2L88G/hvDNrqnW21az/vACfQ6b0
XKyDsEsM8zAJ4UDyZWCgPRM=
=Em1L
-----END PGP SIGNATURE-----