Rockbox.org home
Downloads
Release release
Dev builds dev builds
Extras extras
themes themes
Documentation
Manual manual
Wiki wiki
Device Status device status
Support
Forums forums
Mailing lists mailing lists
IRC IRC
Development
Bugs bugs
Patches patches
Dev Guide dev guide
Search



Donate

Rockbox Technical Forums


Login with username, password and session length
Home Help Search Staff List Login Register
News:

Rockbox Ports are now being developed for various digital audio players!

+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  New Ports
| | |-+  SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
« previous next »
  • Print
Pages: 1 ... 55 56 [57] 58 59 ... 129

Author Topic: SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2  (Read 1336608 times)

Offline daytona955

  • Member
  • *
  • Posts: 9
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #840 on: May 11, 2009, 03:52:22 PM »
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: [Select]
CGU_PERI |= ((CLK_DIV(AS3525_PLLA_FREQ, AS3525_PCLK_FREQ) - 1) << 2)
                | 1; /* clk_in = PLLA */

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.
« Last Edit: May 12, 2009, 04:05:23 AM by daytona955 »
Logged

Offline funman

  • Developer
  • Member
  • *
  • Posts: 645
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #841 on: May 12, 2009, 04:35:25 AM »
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: [Select]
#define DBOP_DIV (CLK_DIV(....))
#if DBOP_DIV > 8
#    error "dbop clkdiv too high"
#endif
CGU_DBOP |= (DBOP_DIV - 1) << x

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!
« Last Edit: May 12, 2009, 09:44:43 AM by funman »
Logged
a wise man said: "a wise man said"

Offline wpyh

  • Member
  • *
  • Posts: 10
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #842 on: May 13, 2009, 09:21:02 PM »
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!

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

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 8966
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #843 on: May 13, 2009, 10:48:44 PM »
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).
Logged

Offline FlynDice

  • Developer
  • Member
  • *
  • Posts: 166
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #844 on: May 14, 2009, 12:51:21 AM »
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 */
Logged
e280v2    fuzev1 2gb   clip+4gb   8GB Transcend cl6 uSD    access to fuzev2 4GB       clip+2gb R.I.P.

Offline bertrik

  • Developer
  • Member
  • *
  • Posts: 171
    • Homepage Bertrik Sikken
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #845 on: May 14, 2009, 02:21:09 AM »
After closer inspection of the OF, it seems the high part of the i2c divider is set with only 2 bits, meaning the total divider cannot be higher than 0x3FF. This should still be big enough to divide any clock down to safe i2c speeds (< 400 kHz).

The OF uses interrupts to handle i2c traffic instead of busy-waiting. This seemed very complicated to me to implement in the intial phase of the port, maybe we should reconsider that. On the other hand an i2c transfer takes only 30 bits or so (75 us at 400 kHz), so maybe it's not worth a thread switch.

Instead of polling the i2c status/busy-bit we could could perhaps poll the i2c interrupt bits. These have not been documented yet though.
Logged
Meizu M6SP, Samsung YP-S3, iPod nano 1g, Sansa c200, Sansa e200, Sansa Clip, Sansa Clip+, Sansa Clip Zip
 

Offline daytona955

  • Member
  • *
  • Posts: 9
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #846 on: May 14, 2009, 05:39:50 AM »
Is it likely that the divisor is of the form 1/(n+1)? Since 1/0 is unlikely to have meaning...
So maybe the code should subtract 1 from prescaler before applying it?
At the division ratios needed, an error of +1 on the divisor is not going to have a big impact though.
Logged

Offline funman

  • Developer
  • Member
  • *
  • Posts: 645
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #847 on: May 14, 2009, 05:52:43 AM »
Oops sorry for the mistake, I corrected the problem, and also set the clock divider to 10 bits.

bertrik do you think the interrupt bits would be set before the status bits?

Since the as3525 is old now, perhaps AMS would be kind enough to give us the docs for the i2c module.. (they seem to ignore us concerning the AS3531 datasheet needed for Clipv2/Fuzev2 however)

daytona955 : it seems that the divisor is of the form 1/(n+5) ... bertrik can you confirm that ?
Logged
a wise man said: "a wise man said"

Offline stray

  • Member
  • *
  • Posts: 3
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #848 on: May 14, 2009, 04:55:23 PM »
Quote from: funman on May 12, 2009, 04:35:25 AM

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!
Does this bug only affect the internal memory?
So is using a 2GB Fuze with an 8GB microSDHC safe?

/edit: That was fast. Thx :D
 (didn't want to create another useless post)
« Last Edit: May 14, 2009, 05:31:45 PM by stray »
Logged

Offline Hillshum

  • Member
  • *
  • Posts: 108
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #849 on: May 14, 2009, 05:10:14 PM »
Yes and yes.
Logged

Offline jago

  • Member
  • *
  • Posts: 7
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #850 on: May 15, 2009, 06:49:17 AM »
Hello!

Nice work until now. Thanks  :).
I own a sansa e260 (4Gb) and I have big problems with revisions higher than r20922.
With r20923 started the trouble. My sansa freezes every few minutes or I get error messages like this: *panic* flush_fat_sector() - could not write sector xxxx (error -101)
There must be something problematical with this commit, at least for my sansa.
I am back on r20922 now and all is fine.
Logged

Offline funman

  • Developer
  • Member
  • *
  • Posts: 645
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #851 on: May 15, 2009, 08:31:36 AM »
Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?

I suppose that the problem is the change from 90MHz to 66MHz , perhaps we need to adjust it a bit.

We used 248/((248/90)+1) = 82.666MHz and now 248/((248/66)+1) = 62MHz IDE clock

When using PLLA at 384MHz, the OF uses 384/((384/66)+1) = 64MHz clock (perhaps not always since there is more than one PLLA setting in the OF)
Logged
a wise man said: "a wise man said"

Offline FlynDice

  • Developer
  • Member
  • *
  • Posts: 166
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #852 on: May 16, 2009, 01:17:57 AM »
Need some help if anyone has had this happen.  I can't access my internal memory through usb and the OF anymore.  I can access the microsd card just fine though and I can copy from it to the internal memory ok using rockbox.  Tried a different cable no luck. Different computer, no luck Copied a new copy of a rockbox bootloader to the internal card and it went through the firmware upgrade process just fine but same results with usb.  Anyone got any ideas for me?

EDIT: Nevermind, I took a chance and reformatted with the OF and it restored my connectivity with the internal disk, Whew ;D

I'm attaching a patch that puts some clock debug info on the debug view hardware page.  I believe the sd numbers are out of whack but the rest work I think.  The assumption is that PLLA is at 248MHz and I've tried to pull the actual divider values out to see what the clock values are ending up as for the various peripherals. Your mileage may vary of course...
* debugclocks.txt (4.21 kB - downloaded 210 times.)
« Last Edit: May 16, 2009, 01:43:20 AM by FlynDice »
Logged
e280v2    fuzev1 2gb   clip+4gb   8GB Transcend cl6 uSD    access to fuzev2 4GB       clip+2gb R.I.P.

Offline stray

  • Member
  • *
  • Posts: 3
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #853 on: May 16, 2009, 01:56:50 AM »
Quote from: funman on May 15, 2009, 08:31:36 AM
Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?
This fixed my Fuze. Before i had to try several times to get the database to build, got some *panic* errors etc.
Logged

Offline jago

  • Member
  • *
  • Posts: 7
Re: SanDisk Sansa e200 v2, c200 v2, m200 (v2), clip and Fuze
« Reply #854 on: May 16, 2009, 05:18:21 AM »
Quote
change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000

I have just tried.
Seems to solve the problem.
Logged

  • Print
Pages: 1 ... 55 56 [57] 58 59 ... 129
« previous next »
+  Rockbox Technical Forums
|-+  Rockbox Development
| |-+  New Ports
| | |-+  SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
 

  • SMF 2.0.17 | SMF © 2019, Simple Machines
  • Rockbox Privacy Policy
  • XHTML
  • RSS
  • WAP2

Page created in 0.208 seconds with 21 queries.