Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
daytona955:
I think CLK_DIV probably does the right thing (although with out any description...), in that it gives a divisor that means the actual generated frequency does not exceed the target.
But when used with hardware that avoids divide-by-zero by treating n as 1/(n+1), the output from CLK_DIV needs adjusting. See for example
--- Code: ---CGU_PERI |= ((CLK_DIV(AS3525_PLLA_FREQ, AS3525_PCLK_FREQ) - 1) << 2)
| 1; /* clk_in = PLLA */
--- End code ---
in system-as3525.c.
A quick grep shows it is used without adjustment in setting the DBOP, I2C2 and SD ident clocks. But I've only checked that the DBOP case is actually wrong (so far).
Edit:
Maybe the incorrect setting of CGU_DBOP is why funman gets this issue in FS10048:
Also I find it weird that UI becomes much slower when we divide pclk by 2 : the DBOP frequency should not change that much since it's lower than pclk anyway... do you have an idea why?
Now I have a build where DBOP clock == PCLK, and a fix to the programming of CGU_DBOP (adjust divisor by -1).
I have done a few builds with different PCLK values. I tested UI responsiveness by an ad-hoc test: how well the rotation of the spacerocks ship tracks the scrollwheel.
With the fix to CGU_DBOP I now get decreasingly poor responsiveness with PCLK frequencies of less than 41.333...Mhz.
Before fixing CGU_DBOP, changing PCLK (& therefore DBOP clk) had all sorts of strange effects, including white screen, scrambled screen, non responsive UI.
funman:
Thanks for hunting that bug!
Indeed I think this is the source of the LCD problems we saw.
The OF uses dynamic clocking for pclk, fclk, and all peripherals, and every setting is checked at each change, but I think we can avoid that with preprocessor checks like:
--- Code: ---#define DBOP_DIV (CLK_DIV(....))
#if DBOP_DIV > 8
# error "dbop clkdiv too high"
#endif
CGU_DBOP |= (DBOP_DIV - 1) << x
--- End code ---
Also the pclk should be set to its exact value (62M) not the maximal value, to calculate correct clock dividers..
EDIT : another bug I just reminded of
For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.
We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.
I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).
An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!
wpyh:
--- Quote from: funman on May 12, 2009, 04:35:25 AM ---EDIT : another bug I just reminded of
For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.
We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.
I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).
An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!
--- End quote ---
Oops... I just upgraded my Fuze 8GB with the latest SVN. It's still working fine even though I have crossed the 4GB boundary though.
I thought we already switch banks when accessing the internal storage? Otherwise, how can it boot from >4GB?
I hope the fix can get in soon.
saratoga:
I think you're confusing the bank switching problem (which is fixed) with a newly identified problem: writing across the bank boundaries (which is not). Rockbox can actually boot without write support at all (see the D2 port for instance).
FlynDice:
funman: Isn't i2c input from PCLK?
line 56 clock-target.h
#if (CLK_DIV(AS3525_PLLA_FREQ, AS3525_I2C_FREQ)) >= (1<<16) /* 2*8 bits */
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version