Rockbox

Tasklist

FS#9588 - fix lcd display in fuze bootloader

Attached to Project: Rockbox
Opened by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 21:03 GMT
Last edited by Rafaël Carré (funman) - Sunday, 30 November 2008, 16:37 GMT
Task Type Bugs
Category Battery/Charging
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This patch fixes the SVN bootloader for Fuze by reverting r19234 partly. Instead, it manually selects 24MHz as plck (minimum).

Also highers the dbop clock, since lcd was too slow with the changed pclk.
This task depends upon

Closed by  Rafaël Carré (funman)
Sunday, 30 November 2008, 16:37 GMT
Reason for closing:  Accepted
Additional comments about closing:  r19276
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 21:05 GMT
wrong patch?
Comment by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 21:08 GMT
Yep, sorry
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 21:11 GMT
it seems that the pclk doesn't change from svn since we use the clk_main without divider (24MHz crystal)

but you use a much higher dbop clock.

Can you detail the dbop clock frequency with your patch and in r19234?
Comment by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 21:21 GMT
The dbop clock is: f(clk_dbop) = f(PCLKDBOP) * div

Assuming that PCLKDBOP == pclk:

r19234: clk_dbop = 64 * 1/(3+1) = 16
with my patch: 24* 1/(0+1) = 24
I tried div=(1+1) (=> clk_dbop 12) and up, but e.g. lcd_update_rect gets noticeably slower (as in you see how the updates line by line).
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 21:23 GMT
Now in SVN we use a 24MHz pclk, so which dividers for dbop clock did you use without modifying CGU_PERI ?
Comment by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 21:28 GMT
I tried 0,1 and 2. All are slower without CGU_PERI. Also, without GCU_PERI entering the main build is very problematic, as in you basically don't get to the main menu reliably.
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 21:30 GMT
I don't understand this sentence, can you rephrase it?
Comment by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 21:34 GMT
I tried various DBOP clock divider (div=1/1+[0,1,2]) without modifying CGU_PERI. all resulted in unacceptable slowness. Plus: I didn't get into the main menu most of the times, e.g. it looped at the (main builds) bootlogo, with doing a slow lcd_update sometimes.
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 21:42 GMT
That means 24MHz, 12MHz, and 8MHz then.

Last thing you could do : try with r19234 , and change the DBOP clock divider to 1+(0->7) to see if you can reproduce this slowness.
Give the DBOP frequencies when you reach such results.

Also try to lower pclk in CGU_PERI until you can reproduce the slowness (and mix with DBOP clock divider of course)
Comment by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 22:04 GMT
Ok: Using the setting as of r19233 (i.e. CGU_PERI |= (5<<2)|0x1; /* pclk = PLLA / 6 = 64 MHz */)

Using dbop divider 1/(3+1) (results in 16MHz DBOP) as in current svn works, without noticeable slowness of the lcd.
Using dbop divider 1/(4+1) and lower (results in ~12MHZ (<10MHz with 1/(5+1) DBOP) leads to white screen at boot (just like the current svn bootloader).


That leads to the conclusion: Everthing under 16MHz breaks the lcd, or at least makes in unacceptable slow.
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 22:14 GMT
thanks for taking the time

it seems I was wrong in my calculation of the PLL frequencies (and that in r19233 and before we weren't using a 64MHz pclk)

I'm checking my code again and will report when I see more clear
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 22:20 GMT
can you try again the tests with a CGU_PLLA setting set to 0x2630 (instead of 0x4330) ?

0x4330 gives a 384MHz frequency (like supposed) but is invalid according to the datasheet
Comment by Rafaël Carré (funman) - Saturday, 29 November 2008, 22:51 GMT
this setting prevents my Clip to boot

I also noticed that set_cpu_frequency() is not called (#ifndef BOOTLOADER block inside #ifdef BOOTLOADER)

I am not sure why using a different fclk prevents the clip to boot.. to investigate
Comment by Rafaël Carré (funman) - Sunday, 30 November 2008, 13:36 GMT
Please try attached patch and correct again the fuze driver against this one (now you'll get a correct frequency for pclk)
If it needs an higher clock than what is used now in svn, it should be conditional on SANSA_FUZE and commented.

Please try it against m200v4 (domonoky?) , e200v2 (jdgordon?) as well (Clip is working fine).
Comment by Rafaël Carré (funman) - Sunday, 30 November 2008, 14:00 GMT
You told me on IRC it breaks e200v2 and m200v4 display, please update this patch with your diff and post it.

You should tweak the DBOP clock divider, and especially the delays used in the drivers, until it works for all frequencies (MAX , DEFAULT, NORMAL)

When we got something working on all models (in both bootloader and main binary), we'll commit it.
Comment by Jonathan Gordon (jdgordon) - Sunday, 30 November 2008, 14:01 GMT
that patch with the following works fine for the e200v2

Index: firmware/target/arm/as3525/sansa-e200v2/lcd-e200v2.c
===================================================================
--- firmware/target/arm/as3525/sansa-e200v2/lcd-e200v2.c (revision 19263)
+++ firmware/target/arm/as3525/sansa-e200v2/lcd-e200v2.c (working copy)
@@ -94,7 +94,7 @@
/* DBOP initialisation, do what OF does */
static void ams3525_dbop_init(void)
{
- CGU_DBOP = (1<<3) | (4-1);
+ CGU_DBOP = (1<<3) | (3-1);

DBOP_TIMPOL_01 = 0xe167e167;
DBOP_TIMPOL_23 = 0xe167006e;

Comment by Rafaël Carré (funman) - Sunday, 30 November 2008, 14:18 GMT
Patches m200v4 e200v2 and moves set_cpu_frequency() at the right location.

kugel, now we put all the power into your hands ;-)
Comment by Thomas Martitz (kugel.) - Sunday, 30 November 2008, 16:28 GMT
here you go.

Loading...