This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9588 - fix lcd display in fuze bootloader
Attached to Project:
Rockbox
Opened by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 22:03 GMT+2
Last edited by Rafaël Carré (funman) - Sunday, 30 November 2008, 17:37 GMT+2
Opened by Thomas Martitz (kugel.) - Saturday, 29 November 2008, 22:03 GMT+2
Last edited by Rafaël Carré (funman) - Sunday, 30 November 2008, 17:37 GMT+2
|
DetailsThis 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. 
fuze-bl-fix.diff
(0.6 KiB)
firmware/target/arm/as3525/ata_sd_as3525.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) |
This task depends upon
Closed by Rafaël Carré (funman)
Sunday, 30 November 2008, 17:37 GMT+2
Reason for closing: Accepted
Additional comments about closing: r19276
Sunday, 30 November 2008, 17:37 GMT+2
Reason for closing: Accepted
Additional comments about closing: r19276
but you use a much higher dbop clock.
Can you detail the dbop clock frequency with your patch and in r19234?
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).
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)
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.
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
0x4330 gives a 384MHz frequency (like supposed) but is invalid according to the datasheet
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
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 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.
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;
kugel, now we put all the power into your hands ;-)