Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Battery/Charging
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kugel. - 2008-11-29
Last edited by funman - 2008-11-30

FS#9588 - fix lcd display in fuze bootloader

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.

Closed by  funman
2008-11-30 16:37
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

r19276

wrong patch?

Yep, sorry

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?

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

Now in SVN we use a 24MHz pclk, so which dividers for dbop clock did you use without modifying CGU_PERI ?

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.

I don’t understand this sentence, can you rephrase it?

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.

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)

Ok: Using the setting as of r19233 (i.e. CGU_PERI |= (5«2)|0×1; /* 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.

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

can you try again the tests with a CGU_PLLA setting set to 0×2630 (instead of 0×4330) ?

0×4330 gives a 384MHz frequency (like supposed) but is invalid according to the datasheet

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

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

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.

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;

Patches m200v4 e200v2 and moves set_cpu_frequency() at the right location.

kugel, now we put all the power into your hands ;-)

here you go.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing