Re: Problem with FB

["Diego A. Fons" <diegofons@apexar.com>]

Nicolas Ferre escribió:

>Diego A. Fons :
>  
>
>>Nicolas Ferre escribió:
>>
>>    
>>
>>>Diego A. Fons :
>>> 
>>>
>>>      
>>>
>>>>Hi,
>>>>
>>>>First of all i'm not sure if it is the correct list for posting this 
>>>>mail, if it's not, please tell me wich list is the correct one.
>>>>
>>>>I'm working on an embedded device (a Ronetix pm9261 board with an 
>>>>AT91SAM9261 cpu), i could build the linux kernel version 2.6.19.7 
>>>>with framebuffer support and it works fine. The problem is when i run 
>>>>any command that uses net services, i.e. when i run sftp the sreen 
>>>>moves and it kept like this, the offset (0,0) is in position (100,0) 
>>>>(it's just an example, i don't know thw correct values) and i'm not 
>>>>able to correct it. It occurs every time i run a net comand. The 
>>>>display i'm usin is a LCD and the driver is sidsab.c.
>>>>  
>>>>        
>>>>
>>>Strange behavior is not it ;-)
>>>
>>>I have seen this before and it was due to a bad timing setup of the
>>>dm9000 chip select.
>>>
>>>-    at91_sys_write(AT91_SMC_CYCLE(2), AT91_SMC_NWECYCLE_(0) | 
>>>AT91_SMC_NRDCYCLE_(16));
>>>+    at91_sys_write(AT91_SMC_CYCLE(2), AT91_SMC_NWECYCLE_(16) | 
>>>AT91_SMC_NRDCYCLE_(16));
>>>
>>>Is you have the first configuration, try with the second and it should
>>>fix your problem.
>>>
>>>Hope that it helps. Tell us if it works.
>>>
>>>Regards,
>>> 
>>>
>>>      
>>>
>>Thanks for replying!
>>
>>I search the line you describes and i could find something similar in 
>>the initialization routine (attach) this is the similar line:
>>
>>at91_sys_write(AT91_SMC_CYCLE(2), \
>>                       (       AT91_DM9000_NWE_CYCLE |
>>                               AT91_DM9000_NRD_CYCLE));
>>
>>The macros are:
>>
>>#define AT91_DM9000_NWE_CYCLE           (32 << 0)
>>#define AT91_DM9000_NRD_CYCLE           (32 << 16)
>>
>>Did you refer to that? or i have to look another place?
>>    
>>
>
>Definitely yes. (sorry I should have said that is was in board-xxxx9261.c
>kind of files).
>
>In this case AT91_DM9000_NWE_CYCLE is... 32 ! So my patch does not apply
>(we had to set it to 16 instead of 0 on our sam9261ek eval board).
>
>I think that ronetix is running the sam9261 at a higher speed than we do on
>the Atmel sam9261ek : you should then reconsider the dm9000 timings (though they
>seem to have adapted theirs already...).
>
>Tell us if you find the proper ones (or if it is another reason).
>Regards,
>  
>
Hi, Nicolas,

(by the way, do you speak spanish? I ask you because of your name)
I was changing the timings values but it seems to get worse, with a set 
of values the screen moves with every ftp command thet sftp sends!
Now the values are (it doesn't work either):

#define AT91_DM9000_NWE_SETUP           (8 << 0)
#define AT91_DM9000_NCS_WR_SETUP        (4 << 8)
#define AT91_DM9000_NRD_SETUP           (8 << 16)
#define AT91_DM9000_NCS_RD_SETUP        (4 << 24)

#define AT91_DM9000_NWE_PULSE           (16 << 0)
#define AT91_DM9000_NCS_WR_PULSE        (32 << 8)
#define AT91_DM9000_NRD_PULSE           (16 << 16)
#define AT91_DM9000_NCS_RD_PULSE        (32 << 24)

#define AT91_DM9000_NWE_CYCLE           (36 << 0)
#define AT91_DM9000_NRD_CYCLE           (36 << 16)

#define AT91_DM9000_TDF                 (1 << 16)

I test it with lower and higher values and nothing (with 1 and 127).

Can you tell me how is it possible that the DM9000 timings interfere 
with the frame buffer? is it possible that other device gets interfered 
and i'm not seeing it?

Regards,
Diego A. Fons.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/