[Buildroot] Problem with FB

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.

Thank you for your time and i'll be waiting any suggestions.

Regards,
Diego A. Fons.

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,
-- 
Nicolas Ferre



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

Nicolas Ferre escribió:

Diego A. Fons :
 

quoted

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?

Regards,
Diego A. Fons.

Diego A. Fons :

Nicolas Ferre escribió:

quoted

Diego A. Fons :
 

quoted

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,
-- 
Nicolas Ferre



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

Nicolas Ferre escribió:

Diego A. Fons :
 

quoted

Nicolas Ferre escribió:

   

quoted

Diego A. Fons :


     

quoted

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/

Diego A. Fons :

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?

Well they both use the SDRam/EBI interface (in fact the ARM926 and the LCD) 
and they may be in conflict some time to get the internal AHB bus (H matrix).
The idea is that one or the other master takes the bus for too long.

What can help us is if you can also check if the fifo underflow UFLWIS 
bit (#4) rises during LDC use.

So, if the LCD is interrupted during a data burst from sdram, it can have 
difficulties to resume its transfer. You can try to lower the configured burst 
length on the LCD : 
ATMEL_LCDC_DMA_BURST_LEN = 4 (so the register field must be written with 0x3) 
instead of 8.

Another option will be to keep the burst length and increase the slot cycle 
in the Matrix interface (from 16->32 or 64). It is the preferred one. This is 
done in the AT91bootstrap but you can do it for testing using a jtag ice.

Keep me informed, Cheers,
-- 
Nicolas Ferre



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

Nicolas Ferre escribió:

Diego A. Fons :

quoted

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?

Well they both use the SDRam/EBI interface (in fact the ARM926 and the 
LCD) and they may be in conflict some time to get the internal AHB bus 
(H matrix).
The idea is that one or the other master takes the bus for too long.

What can help us is if you can also check if the fifo underflow UFLWIS 
bit (#4) rises during LDC use.

So, if the LCD is interrupted during a data burst from sdram, it can 
have difficulties to resume its transfer. You can try to lower the 
configured burst length on the LCD : ATMEL_LCDC_DMA_BURST_LEN = 4 (so 
the register field must be written with 0x3) instead of 8.

Another option will be to keep the burst length and increase the slot 
cycle in the Matrix interface (from 16->32 or 64). It is the preferred 
one. This is done in the AT91bootstrap but you can do it for testing 
using a jtag ice.

Keep me informed, Cheers,

Good news!... kind of :(

I was working in this problem and i was able to get a solution but it is 
not a good practice.
First of all i have to add a line in the at91_add_device_lcdc function 
(ah! i made this tests using kernel 2.6.21):

File: arch/arm/mach-at91/at91sam9261_devices.c
Function: at91_add_device_lcdc()
Line: at91_set_A_periph(AT91_PIN_PB0, 0);

This line enables the Vertical Sync of the LCD, i don't know why it is 
not set by default, so i didnt' have any vertical signal so the display 
didn't work.

Second. I set the fifo underflow interrupt to see if the problem was a 
buffer underflow and it's that way, the interrupt occurs so the probles 
is that display run out of data. I could solve this by calling a 
function that resets all de lcd driver, also i kept enable the 
interruptions all the time. This is the modified function (in the driver 
file, drivers/video/atmel_lcdfb.c):

static irqreturn_t atmel_lcdfb_interrupt(int irq, void *dev_id)
{
        struct fb_info *info = dev_id;
        struct atmel_lcdfb_info *sinfo = info->par;
        u32 status;

        status = lcdc_readl(sinfo, ATMEL_LCDC_ISR);

        // this is the reset call
        atmel_lcdfb_set_par(info);

        //lcdc_writel(sinfo, ATMEL_LCDC_IDR, status);
        lcdc_writel(sinfo, ATMEL_LCDC_ICR, status);

        return IRQ_HANDLED;
}

And the function atmel_lcdfb_set_par was modified to keep enable the 
interruptions:

static int atmel_lcdfb_set_par(struct fb_info *info)
{
...

        // Added this line at the botom, the rest remains the same
        lcdc_writel(sinfo, ATMEL_LCDC_IER, 0x00000010);
        return 0;
}

With this modifications when the screens moves, it reset the parameters 
and you see the screen go down and up.
The question is: is there an elegant way to solve this?

Third. I was trying to reconfigure the Matrix from linx but all i got 
was a coredump from the kernel itself. I'm not able to configure it at 
boot time because i'm using u-boot (and i'm not able to flash a new 
compiled version).

Well, that's it. Sorry for the long mail.I'll be waiting an advise from you.

Best 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/