• Status Closed
  • Percent Complete
  • 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 Thomas Martitz - 2008-11-29
Last edited by Rafaël Carré - 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  Rafaël Carré
2008-11-30 16:37
Reason for closing:  Accepted
Additional comments about closing:  


Rafaël Carré commented on 2008-11-29 21:05

wrong patch?

Thomas Martitz commented on 2008-11-29 21:08

Yep, sorry

Rafaël Carré commented on 2008-11-29 21:11

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?

Thomas Martitz commented on 2008-11-29 21:21

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

Rafaël Carré commented on 2008-11-29 21:23

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

Thomas Martitz commented on 2008-11-29 21:28

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.

Rafaël Carré commented on 2008-11-29 21:30

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

Thomas Martitz commented on 2008-11-29 21:34

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.

Rafaël Carré commented on 2008-11-29 21:42

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)

Thomas Martitz commented on 2008-11-29 22:04

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.

Rafaël Carré commented on 2008-11-29 22:14

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

Rafaël Carré commented on 2008-11-29 22:20

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

Rafaël Carré commented on 2008-11-29 22:51

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

Rafaël Carré commented on 2008-11-30 13:36

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

Rafaël Carré commented on 2008-11-30 14:00

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.

Jonathan Gordon commented on 2008-11-30 14:01

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;
Rafaël Carré commented on 2008-11-30 14:18

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

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

Thomas Martitz commented on 2008-11-30 16:28

here you go.


Available keyboard shortcuts


Task Details

Task Editing