Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
saratoga:
--- Quote from: FlynDice on May 07, 2009, 05:48:13 PM ---Ah yes found it now.
Does this note on the next page under 6.2.3 have any bearing on this lower frequency?
(1) This setting must not be used for AS3525 core supply because the lower voltage limit is out of core supply specification limits.
EDIT: I suppose this could apply for the above 200Mhz clocking and if we're below that the note on the previous page would apply. Otherwise why would there be a setting for lower?
--- End quote ---
The voltage needed depends on the clock speed and the the process used to make the chip. Low voltage runs of chips are possible either by optimizing for power consumption in the fab or by limiting clock speed. Thus theres typically many more settings for voltage available then each individual chip is rated for. If we were willing to accept low clocks for all components, we could probably use lower voltages then the chip is designed for too.
daytona955:
Is there a good reason for AS3525_DBOP_FREQ to be 8MHz (clock_target.h)?
The AS3525 data sheet says <= 65MHz (para 7.3.12.7 on P92).
I've changed it to 62MHz (i.e. PCLK) on a build in an e260v2, and it seems to work well. Responsiveness of the scroll wheel is much improved - to the point where spacerocks becomes playable :)
On a slightly different clocking issue, the ARM922 tech ref (para 5.4) says that for asynch mode, FCLK must have a higher frequency than BCLK. But without boost, Rockbox seems to run FCLK at 31MHz & BCLK (aka HCLK in the AS3525) at 62MHz. How does Rockbox get away with that?
Sorry if there are obvious answers to these - I'm a bit new to Rockbox.
FlynDice:
--- Quote from: daytona955 on May 08, 2009, 06:37:15 PM ---On a slightly different clocking issue, the ARM922 tech ref (para 5.4) says that for asynch mode, FCLK must have a higher frequency than BCLK. But without boost, Rockbox seems to run FCLK at 31MHz & BCLK (aka HCLK in the AS3525) at 62MHz. How does Rockbox get away with that?
--- End quote ---
funman realized the same thing a few days ago and said he had found some success with the caching and mmu problems by increasing the frequencies. See: FS#10048 mmu-dcache
I managed to get synchronous up and running with this patch:FS#10191 synchronous clocking
There is a problem with the i2c (ascodec) clocking though. Read the message traffic on those two FS's and it should give you a good idea of where things are. I haven't seen any comments from funman in a couple of days so I don't know if he's had any success in sorting out the clocking issues. I have not found anything new to add in the past couple of days.
EDIT: I finally tried some tests on SVN vs synchronous clocking. The synchronous clocking setup turns out faster from what I can tell;
sync SVN
test_codec 132.59 vs 142.5 (mp3)
test_fps 42.2 fps vs 30.6 fps
daytona955:
Regarding DBOP clocking, is this code
CGU_DBOP = (1<<3) | CLK_DIV(AS3525_PCLK_FREQ, AS3525_DBOP_FREQ);
in ams3525_dbop_init() correct?
For example, with PCLK=62M, and a desired DBOP clock of 8M, CLK_DIV gives 8 (truncated from 8.74999...). (I think 62 & 8 are effectively the current SVN values.)
62M/8 gives 7.75M, which is less than 8M (and so is safe if 8MHz was an absolute limit).
But the AS3526 data sheet says that DBOP_PREDIV_SEL is only 3 bits, so we cannot set it to 8.
Also, the actual division ratio is 1/(DBOP_PREDIV_SEL+1).
So for this example, the actual division ratio becomes 1/((0x8 & 0x7)+1), i.e. 1.
I think the code needs 1 subtracted from the divisor to have the correct effect.
Edit:
Actually, the PCLK value in SVN (clock-target.h) is
#define AS3525_PCLK_FREQ 65000000
The actual PCLK will be 62MHz, but the DBOP clock would calculated on 65MHz. This would give give a divisor of 9, giving a real value of 2 when programmed to the hardware.
However, subtracting 1 would not fix the problem in this case...
kugel.:
--- Quote from: daytona955 on May 11, 2009, 10:46:24 AM ---Regarding DBOP clocking, is this code
CGU_DBOP = (1<<3) | CLK_DIV(AS3525_PCLK_FREQ, AS3525_DBOP_FREQ);
in ams3525_dbop_init() correct?
--- End quote ---
Initially, it ran at PCLK speed (see http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/sansa-fuze/lcd-fuze.c?r1=19276&r2=19330). During the work for r19330, we played with the clocks and found ~20MHz (PCLK / 3) quite usable. I'd say 8MHz is not intended.
Edit: Yes, CLK_DIV seems to give wrong results. And to be honest, if it really was 8MHz, I think the the LCD would be next to infunctional. So, currently it's at PCLK / (1+1)=32.5 MHz. I think we could change it to be = PCLK and clock down when the backlight is off to save power.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version