Re: Inquiring about your Linux 2.6.17.1 port to XUP

Re: Inquiring about your Linux 2.6.17.1 port to XUP

[Ameet Patil]

Hi Neil,
    Please help yourself! Everything in 
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/ is for public 
access! And yes! You are right... 
http://www.cs.york.ac.uk/rtslab/demos/amos/ is not for public.
Do post your comments or bugs (if any) on the linux embedded ppc mailing 
list (linuxppc-embedded@ozlabs.org).

cheers,
-Ameet

Neil Steiner wrote:
> Dear Sirs:
> 
> I came across a link to 
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/ on comp.arch.fpga, 
> but noticed that http://www.cs.york.ac.uk/rtslab/demos/amos/ requires 
> login access, and so I wasn't sure whether or not your Linux 2.6.17.1 
> files where intended for public consumption.
> 
> I don't have a pressing need for a 2.6 kernel, and have instead been 
> following directions from the University of Washington 
> (http://www.cs.washington.edu/research/lis/empart/xup_ppc_linux.shtml) 
> and Brigham Young University 
> (http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm) for a 2.4 
> kernel, but seeing the link to your site did pique my curiosity.
> 
> My question then is simply whether I may refer to your files if they 
> prove to be useful, or if they were supposed to be restricted.
> 
> Neil

Gofast float point and 405ep

[Stelios Koroneos]

Greetings !

Has anyone used the Gofast float point lib instead of the gcc one with the
405?
If yes have you measured significant differences in performance ?

I need to do considerable floating point operations (dtmf detection, echo
cancelation etc) and i was wondering if there are any speed improvents

Stelios

System ACE driver - for 2.6 kernel - need help to understand xsa_thread

[agnel juni]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]


Hello all
 
 I am trying to understand the parameters that are sent through "cur_req" function used in funtion xsa_thread in System ACE driver.
 
 In xsa_thread function in the System ACE driver , 
 
 In 2.4 kernel:
 --------------------
 while ((stat = cur_req(&SysAce, sector,
                                        CURRENT->current_nr_sectors,
                                        CURRENT->buffer)) == XST_DEVICE_BUSY)
                         xsa_short_delay();
 
  
 Where as in 2.6 kernel this is changed to 
 ---------------------------------------------------------------
 
  for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
                         xsa_device.req_done = 1;
                         while ((stat = cur_req(&SysAce, sector,
                                         2,
                                         buffer)) == XST_DEVICE_BUSY)
                                 xsa_short_delay();
 #endif
 
 Ameet , could you help me understand the impact of the parameters, especailly the 3rd paramter which is hardcoded in 2.6 kernel.It would be great if you could clarify this in regard to 'mount' command.
 
 Thanks in advance
 Junita
 
 
 
 
 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

[-- Attachment #2: Type: text/html, Size: 2932 bytes --]

Re: System ACE driver - for 2.6 kernel - need help to understand xsa_thread

[Ameet Patil]

Hi Junita,
    Its a hack really! When I was developing/porting the SysAce driver 
to 2.6 I tried to maintain the code as is from the 2.4 kernel driver. In 
doing so I found that there is a slight difference between the two 
kernels. i.e. I am not sure why, but the sysace device can only handle 
requests for 2 sectors at a time. This was fine in the 2.4 as the kernel 
always requested 2 sectors. However, in 2.6 I found that this is 
different: the requests are 8 secs. or more. I tried to fix this in vain 
by changing several parameters of the driver during initialization. 
Anyway, due to several issues I didn't try hard to fix it at that time.

Hence this hack: No matter how many sec. req. I get from the kernel, I 
use a loop to req. only 2 secs. at a time. The xsa_device.req_done is 
used as a flag and reset in the XSA IRQ IIRC.

If you find a better approach, please do update me. Hope this helps!

cheers,
-Ameet

agnel juni wrote:
> 
> Hello all
> 
> I am trying to understand the parameters that are sent through "cur_req" 
> function used in funtion xsa_thread in System ACE driver.
> 
> In xsa_thread function in the System ACE driver ,
> 
> In 2.4 kernel:
> --------------------
> while ((stat = cur_req(&SysAce, sector,
>                                        CURRENT->current_nr_sectors,
>                                        CURRENT->buffer)) == XST_DEVICE_BUSY)
>                         xsa_short_delay();
> 
>  
> Where as in 2.6 kernel this is changed to
> ---------------------------------------------------------------
> 
> for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
>                         xsa_device.req_done = 1;
>                         while ((stat = cur_req(&SysAce, sector,
>                                         2,
>                                         buffer)) == XST_DEVICE_BUSY)
>                                 xsa_short_delay();
> #endif
> 
> Ameet , could you help me understand the impact of the parameters, 
> especailly the 3rd paramter which is hardcoded in 2.6 kernel.It would be 
> great if you could clarify this in regard to 'mount' command.
> 
> Thanks in advance
> Junita
> 
> 
> 
> ------------------------------------------------------------------------
> Find out what India is talking about on - Yahoo! Answers India 
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. 
> Get it NOW 
> <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com> 
>